From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Eli Zaretskii" Newsgroups: gmane.emacs.devel Subject: Re: emacs 21.2 Date: Fri, 22 Mar 2002 19:45:56 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <9743-Fri22Mar2002194555+0200-eliz@is.elta.co.il> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1016819484 27811 127.0.0.1 (22 Mar 2002 17:51:24 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 22 Mar 2002 17:51:24 +0000 (UTC) Cc: emacs-devel@gnu.org Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16oTCF-0007ES-00 for ; Fri, 22 Mar 2002 18:51:23 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16oTJ1-0000lk-00 for ; Fri, 22 Mar 2002 18:58:23 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16oTC5-0006ag-00; Fri, 22 Mar 2002 12:51:13 -0500 Original-Received: from balder.inter.net.il ([192.114.186.15]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16oTAI-0006Vt-00 for ; Fri, 22 Mar 2002 12:49:22 -0500 Original-Received: from zaretsky (diup-217-145.inter.net.il [213.8.217.145]) by balder.inter.net.il (Mirapoint) with ESMTP id BGQ67327; Fri, 22 Mar 2002 19:49:14 +0200 (IST) Original-To: simon.marshall@misys.com X-Mailer: emacs 21.2.50 (via feedmail 8 I) and Blat ver 1.8.9 In-Reply-To: (simon.marshall@misys.com) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2141 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2141 > From: "Marshall, Simon" > Date: Fri, 22 Mar 2002 15:20:32 -0000 > > I don't know if you meant to direct this comment at the emacs-devel list > only It was meant to anyone who is interested in Emacs development. emacs-devel is certainly a good place to find those people. > If it was directed at pretesters, then, put yourself in my (a pretester) > shoes. I spent a large amount of my own time tracking down problems > with the last pretest & coming up with some fixes & testing others'. Thank you very much for those efforts. They are certainly appreciated. > I did it because I thought it would be worth it: I thought the next > Emacs release would fix those problems. Why would I bother if fixes > wouldn't appear in the next release? It is not always possible to fix everything in the version currently under a pretest. If the bug is minor and the fix can potentially affect other places in Emacs, then there's a judgement call whether to fix it in the upcoming release or the one after that, especially if the pretest is otherwise stable and ready for a release. A pretest should be a converging process--as it proceeds, the codebase should become more and more stable (less bugs, less crashes, etc.), at least on the average. Installing a change that potentially destabilizes the code could mean either unstable release or more pretest releases and a resultant significant delay in the release date. So there's a clear tradeoff here. I'm sure I'm not telling you anything you didn't already know. > > Of course, since there's a judgement call involved, everybody is > > welcome to step forward and argue for the changes they think should > > be included. But if you don't speak up, I can't see how can we take > > your views into account. > > I think it is difficult for pretesters to follow the release policy > (assuming that they know what it is---I didn't/don't) and make these > kinds of judgements. Whatever is not clear can be explained if you ask. The CVS, both the release branch and the development trunk, are there for you to scrutinize. There are special mailing lists where you are notified about commits to the CVS; you can subscribe to one of those lists and monitor the changes, to know whether your patches are installed for the next release or only on the trunk. Failing all that, you can ask explicitly. In other words, the development process is open--you are welcome to monitor the decisions and speak up your views. > I think your release policy itself is wrong---assuming I know what it > is---I think the only reason to release a version that does not fix > serious but not necessarily fatal bugs is when a quick release is needed > because the previous release was broken. Emacs 21.1 is not broken, but it has a number of annoying redisplay bugs, albeit subtle ones, which don't show up except in sufficiently rare situations. The main purpose of 21.2 was to quickly fix those problems, in order to make Emacs 21 as good as Emacs 20.7. Problems which existed in Emacs 20.x, such as the scroll-bar behavior, do not belong to this class of problems. As to the next release, AFAIK we still need to see whether v21.2 is stable enough to make it the last release from the branch or not. If it is, the next release will have all of your changes. > To take your 2nd para above, you say "even if the release under pretest > is a minor bugfix". That wasn't said about Emacs 21.2. It was a general statement. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel