Re: Reordering etc/NEWS

[Karl Fogel <kfogel@red-bean.com>]

storm@cua.dk (Kim F. Storm) writes:
> The problem with your principles is not only the (forever delayed)
> release as such, but just as much the implied "feature freeze" which
> is really blocking a lot of new development on the project.
>
> The current feature freeze has now lasted for more than 3 years,
> during which Emacs _development_ has practically been at a
> stand-still, so it is no wonder your team of _loyal_ developers is
> getting frustrated and starts to question your principles, and
> may start looking for other (more productive) projects to work on.

What Kim said.

I don't get excited about making improvements to Emacs these days,
because I know I won't be able to check them in.  So I make fewer of
them.

Again, I don't see any reason, in Emacs or any project, why there
should be no place to check in bleeding-edge development changes.
There is no technical reason why a release (or N simultaneous
releases, for that matter) should impede new development work.  The
current state of affairs means that we are using our version control
system poorly, or that we're making incorrect assumptions about the
fungibility of volunteer developers' time (e.g., the false assumption
that if someone is unable to work on new code, they'll just take that
time and devote it to release work instead, which is obviously not
true).

This isn't meant as badgering, or as a personal attack.  But I see a
number of developers wishing we could have the same non-obstructive
release process as other software projects... yet so far I've only
seen two people (RMS and, sort of, Stefan Monnier) defend our current
system, and the defenses have not really addressed the issues raised
above.  Maybe I've missed a few posts, but it seems pretty clear that
a majority of developers would like to work in a different way.

One possible response to this is: Emacs is not a democracy! :-)

Okay, fine, but even in a dictatorship our release system can still be
broken.  I think it is, and I've described why above, concretely.  The
project doesn't have to be a democracy, but it does need to function.

Why are we blocking new changes?  Why not (say) have an open trunk,
and use a release branch to isolate the release from churn, like other
projects do?

-Karl