Re: Reordering etc/NEWS

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

Eli Zaretskii <eliz@gnu.org> writes:
> 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.

Those who are blocked from checking in new changes on trunk do not
always then volunteer for release stabilization/maintenance work.

I don't, for example, except in the packages that I maintain -- and
that's work I would do anyway, regardless of whether I'm checking in
new trunk code as well.  (Don't most package maintainers behave this
way, maintaining the things for which they've accepted responsibility
regardless of what other work they're doing?)

Zero-sum assumptions don't hold here.

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

Well, I think this is overestimating both the amount and the style of
control one can really have with a group of volunteers...

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

The largest I know of off the top of my head is Subversion, which is
smaller than Emacs but also has very disjoint areas of expertise.
(I'm not sure the dimensions of comparison you're proposing here are
valid anyway, though; even if they were, my earlier point about how
volunteers actually allocate their time still holds.)

I think it may be moot now.  Richard seems to have declared trunk
open again.

-Karl