emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 21.2.90 pretest, 21.3, 21.4...


From: Juanma Barranquero
Subject: Re: 21.2.90 pretest, 21.3, 21.4...
Date: Tue, 05 Nov 2002 08:56:59 +0100

On Tue, 5 Nov 2002 07:58:56 +0200 (IST), Eli Zaretskii <address@hidden> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]