Re: Reordering etc/NEWS

[Eli Zaretskii]

> Cc: address@hidden (Kim F. Storm),  address@hidden,  address@hidden
> From: Karl Fogel <address@hidden>
> Date: Thu, 10 May 2007 08:53:08 -0700
> 
> Basically, I proposed always having an open trunk (or some place
> where new changes can be checked in).  We'd use branches:
> 
>    a) To isolate release lines from trunk churn.
>    b) To isolate trunk from large, unstable batches of new code until
>       that code is ready.

Remember my message a day or two ago where I explained that Emacs
development needs experts in many different areas to be part of the
core team (those who can approve or reject patches)?  You agreed with
that, I think.

If we don't have enough experts, how can we make sure the release
branch remains stable?  Someone needs to review patches suggested for
that branch and make sure they are safe.  A single volunteer is not
very good in splitting her attention between two potentially very
different code bases, so many areas will need two people.  And on top
of that, volunteers generally like new development much more than
maintenance-like activity one finds on release branches.

That's the problem in always having an open trunk in Emacs: you need
roughly twice as many experts to handle a stable release branch and
the trunk at the same time.  Right now, we don't even have a single
full team, let alone two.

The MAINTAINERS file was born out of the last similar discussion we
had; it was supposed to become a starting point for bringing people on
board who would volunteer to become our experts for specific areas.
You can take a look at it: since its introduction in November 2001, it
got exactly 4 non-trivial changes, and an alarming amount of core
files and packages still have no responsible expert associated with
them.  Given this situation, it's IMO a miracle we are able to release
a stable version at all.

If you ask me, I won't even consider going to the scheme you suggest
until the list of files in MAINTAINERS for which there's no
responsible individual is significantly reduced.

> I've seen it work very well on other projects.

Please name the largest project where it works very well, and let's
compare its size and the number of disjoint areas of expertise it
requires to those of Emacs.