when emacs 22.1 release will ready?

when emacs 22.1 release will ready?

[Alex Ott]

Hello

Is any time boundaries for releasing of emacs 22.1? Will some
pre-release message released some time before release - i, and some
other peoples need to have this information, to prepare to information
company about this release

-- 
With best wishes,                    Alex Ott, MBA
http://alexott.blogspot.com/
http://alexott-ru.blogspot.com/
http://content-filtering.blogspot.com/
http://xtalk.msk.su/~ott/

Re: when emacs 22.1 release will ready?

[Kim F. Storm]

"Alex Ott" <alexott@gmail.com> 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.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: when emacs 22.1 release will ready?

[Lennart Borgman (gmail)]

Kim F. Storm wrote:
> "Alex Ott" <alexott@gmail.com> 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.

Re: when emacs 22.1 release will ready?

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> What do they do to keep control over the quality? I guess they are 
> using a lot of unit testing for the kernel, or?

The quality of Emacs hasn't changed considerably over the past 3 years. 
What would change it is to do a proper pretest cycle where only 
regressions are fixed with the aim of reaching zero code changes after a 
few pretest releases and releasing at that point.

Re: when emacs 22.1 release will ready?

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> What do they do to keep control over the quality? I guess they are 
>> using a lot of unit testing for the kernel, or?
> 
> The quality of Emacs hasn't changed considerably over the past 3 years. 
> What would change it is to do a proper pretest cycle where only 
> regressions are fixed with the aim of reaching zero code changes after a 
> few pretest releases and releasing at that point.

But how can you be sure that the changes does not cause new regressions 
without some kind of more automatic testing (like unit tests then)?

Re: when emacs 22.1 release will ready?

[Thomas Hühn]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

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

I suppose there are *a lot* more people trying out pre-release kernels
than CVS Emacs or pretest versions.

Another point why this pretest thing over the last weeks might have been
bad:

People don't take "this is our pretest tarball, please check it for
severe errors, this is our chance to find showstoppers before the
release" serious if there are a lot more of "this time it's for real"
pretest tarballs after that with no release in sight. That means that
pretest tarballs reach even less potential testers.

That's more psychology than anything else, but it might count
nevertheless.

Thomas

Re: when emacs 22.1 release will ready?

[Leo]

----- Kim F. Storm (2007-04-30) wrote:-----

> + 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.

Long term release hurts every project. The huge success of the kernel
again shows the only thing to make RMS change is to do something better
than him like what XEmacs did in the past and what Ubuntu did to Debian.

I wonder why would people tolerate his dictatorship in the `free'
software realm.

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: when emacs 22.1 release will ready?

[joakim]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

>> 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.

I wrote some simple unit-test for CEDET
(http://www.emacswiki.org/cgi-bin/wiki/CollectionOfEmacsDevelopmentEnvironmentTools)

Having done so, I think emacs is fairly well suited for unit-tesing.

This is because, unlike many gui applications, things dont move around
very randomly in an emacs buffer. You can set-up a buffer to, for
instance, test font-locking. At a given character position you will
expect to find a certain property, if it works.

You have also the possibility to create macros, which re-create a
certain test environment, fairly conveniently with inbuilt emacs
facilities.

The problem is of course to get developers interested in creating
unit-test.

Another useful method is getting bug-reporters to supply unit tests
for their bugs.

If some unit-testing frameworks, like
http://www.emacswiki.org/cgi-bin/wiki/UnitTesting, where included in
emacs, maybe the bug-reporting template in emacs could suggest writing
a unit test for the bug when reporting it. 


> 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.

-- 
Joakim Verona

Re: when emacs 22.1 release will ready?

[Lennart Borgman (gmail)]

Thomas Hühn wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> What do they do to keep control over the quality? I guess they are
>> using a lot of unit testing for the kernel, or?
> 
> I suppose there are *a lot* more people trying out pre-release kernels
> than CVS Emacs or pretest versions.
> 
> Another point why this pretest thing over the last weeks might have been
> bad:
> 
> People don't take "this is our pretest tarball, please check it for
> severe errors, this is our chance to find showstoppers before the
> release" serious if there are a lot more of "this time it's for real"
> pretest tarballs after that with no release in sight. That means that
> pretest tarballs reach even less potential testers.
> 
> That's more psychology than anything else, but it might count
> nevertheless.


I agree to both your points here. It looks however to me that it is a 
mix of slightly bad circumstances that are adding together. It might be 
tempting to look for a single cause, but it is perhaps more fruitful to 
consider what the addition of a lot of small things may cause.

There is a lack of resources here and that is a crucial thing that 
interacts badly with other weak points. Every developer and tester is 
valuable then.

Normal testing is known to demand a lot of resources. Bad implementation 
of normal testing is by some writers said to demand much more resources 
than trying to go along without any testing framework.

Unit testing promoters says that unit tests instead quickly is freeing 
resources. If that is true for a project like Emacs is of course not 
self evident, but I think it can be.

Re: when emacs 22.1 release will ready?

[Lennart Borgman (gmail)]

Leo wrote:

> Long term release hurts every project. The huge success of the kernel
> again shows the only thing to make RMS change is to do something better
> than him like what XEmacs did in the past and what Ubuntu did to Debian.


Is not one of the things behind the Ubuntu success that it is 
financially backed up by someone with both resources and a kind interest 
in the project?

I do not know very much about Xemacs, but since I think that lack of 
resources is crucial here I think that things would have been much 
better without that split.

Re: when emacs 22.1 release will ready?

[Lennart Borgman (gmail)]

joakim@verona.se wrote:

> Another useful method is getting bug-reporters to supply unit tests
> for their bugs.
> 
> If some unit-testing frameworks, like
> http://www.emacswiki.org/cgi-bin/wiki/UnitTesting, where included in
> emacs, maybe the bug-reporting template in emacs could suggest writing
> a unit test for the bug when reporting it. 

A very good idea in my opinion.

Re: when emacs 22.1 release will ready?

[Leo]

----- Lennart Borgman (gmail) (2007-04-30) wrote:-----

> Leo wrote:
>
>> Long term release hurts every project. The huge success of the kernel
>> again shows the only thing to make RMS change is to do something
>> better than him like what XEmacs did in the past and what Ubuntu did
>> to Debian.
>
>
> Is not one of the things behind the Ubuntu success that it is
> financially backed up by someone with both resources and a kind
> interest in the project?

That's maybe one reason but there are tons of other ditros backed by
companies.

> I do not know very much about Xemacs, but since I think that lack of
> resources is crucial here I think that things would have been much
> better without that split.

NO. The lack of resources is a cause of long release cycle. I feel it is
unfair the developers valid point of view is deliberately ignored by
rms.

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: when emacs 22.1 release will ready?

[Thien-Thi Nguyen]

() Leo <sdl.web@gmail.com>
() Mon, 30 Apr 2007 11:37:39 +0100

   I feel it is unfair the developers valid point of view is
   deliberately ignored by rms.

ignorance at any level is unfair, but ignorance cannot be
completely avoided; no one knows everything.  if one were to
know everyhing, one would (perhaps sadly) know this all the
more.

thi

unit testing [was Re: when emacs 22.1 release will ready?]

[Stephen J. Turnbull]

joakim@verona.se writes:

 > The problem is of course to get developers interested in creating
 > unit-test.

XEmacs has a unit-test framework, comprising about 100,000 individual
tests, which is probably 500 to 1,000 features being tested.  Not
much, but much better than nothing.

You'd have to check with rms / FSF legal dept, but we do have CVS
commit records and ChangeLogs, so authorship should be easy to
establish with high accuracy.  The framework itself probably has at
most 5 authors, of whom two surely have assignments on file.  Tests
themselves are mostly single-author and independent of each other, so
you can take only the well-documented and assigned ones.  FSF legal
would possibly want further documentation, but this might be easier to
get than to write a framework and tests from scratch, and would have
the advantage that (where papers are available) tests written for
XEmacs and SXEmacs would "just work."

Any Lisp coder can write simple tests in a couple of minutes.

Re: when emacs 22.1 release will ready?

[Chong Yidong]

Leo <sdl.web@gmail.com> writes:

> ----- Kim F. Storm (2007-04-30) wrote:-----
>
>> + 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.
>
> Long term release hurts every project. The huge success of the kernel
> again shows the only thing to make RMS change is to do something better
> than him like what XEmacs did in the past and what Ubuntu did to Debian.
>
> I wonder why would people tolerate his dictatorship in the `free'
> software realm.

To be fair, I think RMS' style of maintaining software, with long
release cycles and insistence on fixing all reported bugs, was
probably a good approach back in the 80s, when there was only a
handful of users with access to email to report bugs.

Nowadays, of course, the increase in the number of users with email
and the fact that Emacs CVS is now publicly available means that there
will always be a constant trickle of bug reports giving you something
to fix.  Insisting---as RMS does---on fixing all reported bugs, even
those that are not serious and not regressions, now means that you
will probably never make a release.

There is also a positive feedback loop: RMS' style for maintaining
Emacs drives away valuable contributors who feel their effects will
never be rewarded with a release (and a release is, after all, the
only reward you get from contributing to Emacs).

Sadly, RMS seems determined to "stay the course", instead of adopting
strategies that have been proven to work in other software projects.

Re: when emacs 22.1 release will ready?

[Eli Zaretskii]

> Date: Mon, 30 Apr 2007 11:53:58 +0200
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> Cc: Alex Ott <alexott@gmail.com>, emacs-devel@gnu.org,
> 	"Kim F. Storm" <storm@cua.dk>
> 
> > The quality of Emacs hasn't changed considerably over the past 3 years. 
> > What would change it is to do a proper pretest cycle where only 
> > regressions are fixed with the aim of reaching zero code changes after a 
> > few pretest releases and releasing at that point.
> 
> But how can you be sure that the changes does not cause new regressions 
> without some kind of more automatic testing (like unit tests then)?

Jason said ``zero code changes''.  Zero changes can never cause any
regressions.

Re: when emacs 22.1 release will ready?

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Mon, 30 Apr 2007 11:53:58 +0200
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> Cc: Alex Ott <alexott@gmail.com>, emacs-devel@gnu.org,
>> 	"Kim F. Storm" <storm@cua.dk>
>>
>>> The quality of Emacs hasn't changed considerably over the past 3 years. 
>>> What would change it is to do a proper pretest cycle where only 
>>> regressions are fixed with the aim of reaching zero code changes after a 
>>> few pretest releases and releasing at that point.
>> But how can you be sure that the changes does not cause new regressions 
>> without some kind of more automatic testing (like unit tests then)?
> 
> Jason said ``zero code changes''.  Zero changes can never cause any
> regressions.

That of course depends on how you define it.

Re: when emacs 22.1 release will ready?

[Richard Stallman]

We are waiting to get more info about the development of python.el
to determine what we need to do to it.  Maybe we need to remove it,
but I want to ask for more facts rather than give up precipitously.

Re: when emacs 22.1 release will ready?

[Richard Stallman]

I am all in favor of setting up automated regression tests for Emacs.
For functionality accessible at the Lisp level, this is not very hard.
Even if that covers just half the functionality, it would be substantially
useful.

But this is a sizeable job.  It would require a couple of enthusiastic
people.

Re: when emacs 22.1 release will ready?

[Leo]

----- Kim F. Storm (2007-04-30) wrote:-----

> "Alex Ott" <alexott@gmail.com> 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.

Linus knows well:

"""
Linus Torvalds disagreed with Adrian's view that increasing the length
of the release cycle would improve stability, "regressions _increase_
with longer release cycles. They don't get fewer." He went on to add,
"you are ignoring the reality of development. The reality is that you
have to balance things. If you have a four-month release cycle, where
three and a half months are just 'wait for reports to trickle in from
testers', you simply won't get _anything_ done. People will throw their
hands up in frustration and go somewhere else." He continued: ......
"""

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: when emacs 22.1 release will ready?

[Juanma Barranquero]

On 4/30/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:

> Eli Zaretskii wrote:
> > Jason said ``zero code changes''.  Zero changes can never cause any
> > regressions.
>
> That of course depends on how you define it.

Do you mean there are several meaningful ways to define "zero code changes"?

             Juanma