Re: when emacs 22.1 release will ready?

[Chong Yidong <cyd@stupidchicken.com>]

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.