emacs-devel
[Top][All Lists]
Advanced

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

Re: when emacs 22.1 release will ready?


From: Lennart Borgman (gmail)
Subject: Re: when emacs 22.1 release will ready?
Date: Mon, 30 Apr 2007 11:33:45 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666

Kim F. Storm wrote:
"Alex Ott" <address@hidden> writes:

Is any time boundaries for releasing of emacs 22.1?

No.

Will some
pre-release message released some time before release

Indeed, there have been many "real soon now" pre-release messages at
regular intervals for the last +3 years.


Compare this to Linus' announcement for the just released 2.6.21 kernel:

+ So it's been over two and a half months, and while it's certainly not the
+ longest release cycle ever, it still dragged out a bit longer than I'd
+ have hoped for and it should have. As usual, I'd like to thank Adrian (and
+ the people who jumped on the entries Adrian had) for keeping everybody on
+ their toes with the regression list - there's a few entries there still,
+ but it got to the point where we didn't even know if they were real
+ regressions, and delaying things further just wasn't going to help.

With a similar release procedure for Emacs, Emacs 22.1 had been
released in 2004, and 23.4 would be ready for release next month.

What do they do to keep control over the quality? I guess they are using a lot of unit testing for the kernel, or?

Is that something that could be done for Emacs? I would propose that this should be done, in a proper manner. The way I would like to see it done is to add unit tests when relevant. There are a few points to watch out for:

- Any change.
- Any bug reports.
- Any code that is hard to understand.

A problem is of course that Emacs is screen oriented and that it is much harder to have an automatic testing framework for that. I do not know how people do that now, but semi-automatic result testing should be possible in cases for fully automatic testing is not possible.

Of course, this is work and it takes time. But if the impression that changes create regression is valid then I think something like the above is a possible way to get out of it and get shorter release cycles.




reply via email to

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