From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: 21.2.90 pretest, 21.3, 21.4... Date: Tue, 05 Nov 2002 08:56:59 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: <20021105084024.0CD8.LEKTU@terra.es> References: <20021104170119.BAB6.LEKTU@terra.es> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1036483896 18359 80.91.224.249 (5 Nov 2002 08:11:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 5 Nov 2002 08:11:36 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 188yoA-0004lb-00 for ; Tue, 05 Nov 2002 09:11:34 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 188yw5-00052u-00 for ; Tue, 05 Nov 2002 09:19:45 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 188ynX-0001au-00; Tue, 05 Nov 2002 03:10:55 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 188yaF-0005nr-00 for emacs-devel@gnu.org; Tue, 05 Nov 2002 02:57:11 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 188yaC-0005nY-00 for emacs-devel@gnu.org; Tue, 05 Nov 2002 02:57:10 -0500 Original-Received: from [62.22.27.141] (helo=mail.peoplecall.com) by monty-python.gnu.org with esmtp (Exim 4.10) id 188yaB-0005hX-00 for emacs-devel@gnu.org; Tue, 05 Nov 2002 02:57:07 -0500 Original-Received: from [62.22.27.143] (jbarranquero.ofi.peoplecall.com [62.22.27.143]) by mail.peoplecall.com (8.11.6/8.11.6) with ESMTP id gA57uw017429; Tue, 5 Nov 2002 08:56:58 +0100 Original-To: Eli Zaretskii In-Reply-To: X-Mailer: Becky! ver. 2.05.06 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:9130 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9130 On Tue, 5 Nov 2002 07:58:56 +0200 (IST), Eli Zaretskii wrote: > As someone who was involved in pretest releases up until 21.2.90, I can > assure you that the schedule for the releases was not determined by the > desire to put ``more punch'', but simply by the availability of free time > to make the pretests and solve bugs reported by the pretesters. In the case of the 21.2 and 21.3-to-be releases that's pretty clear, as they carry no punch (meaning "features") and to all practical effects apport just stability. (And no, I'm not understressing the immense value of stability). Also, please don't think I don't value the effort you and others put in each release. I do. > As long as we keep the scheme whereby bug-fix releases precede the > next development release, the time until the next release from HEAD > is largely determined by the amount of bugs we deem severe enough to > fix, and the available resources to fix them. The only way to speed that > up is to have more people working on the release branch. Well, yes. I think the most serious problem right now is the man-power shortage; I'm not sure how many people is actively contributing, even in small ways as I do, but we are few (or that's my highly subjective perception). Still, we're pretesting 21.3 since... when? March or April, at least? There's really so big a list of problems with the pretests that we're taking six months for a bug-fix release? > Personally, I think it'd be a sad day when the quality of the released > Emacs versions will be anywhere near GCC's. Since GCC 3.0, I don't > think there was a released version without a couple of major bugs. With > all its limitations, I'd vote for what we have now in Emacs any time. Copying some of the procedures does not necessarily mean copying the errors. Still, I believe that preplanning tentative schedules, even if we miss then, should help a little. That, and of course convincing people to focus their attention in the release branch and not the development one while the release branch is in pretest time... :) /L/e/k/t/u