emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reordering etc/NEWS


From: Eli Zaretskii
Subject: Re: Reordering etc/NEWS
Date: Fri, 11 May 2007 21:26:08 +0300

> Cc: address@hidden
> From: Karl Fogel <address@hidden>
> Date: Fri, 11 May 2007 10:49:17 -0700
> 
> > 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.

Who is ``blocked from checking in new changes on trunk''?  Once
someone is approved for write access to CVS, that person can commit
changes anywhere.

> 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?)

I don't see how this is relevant.

> Zero-sum assumptions don't hold here.

Sorry, I don't understand what you mean 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...

It has nothing to do with control.  What we need (IMO) is to have, for
each expertise area, a person to whom we could turn for a definitive
opinion when a change is suggested.

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

Without comparing, we have no real measures to judge this.

And time allocation by volunteers is not relevant to what I meant.  No
matter what someone chooses to work on this week, his expertise is
available to us when we want to ask his opinion about a change.

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

I thought you were raising a more general issue of how to maintain
Emacs.  If this was only about opening the trunk, then I don't see any
significant problem here, as the trunk is open 99.99% of the time.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]