Re: emacs 21.2

["Eli Zaretskii" <eliz@is.elta.co.il>]

> From: "Marshall, Simon" <simon.marshall@misys.com>
> 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