Re: Status

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   Date: Fri, 11 Feb 2000 14:08:53 -0800
   From: Stan Shebs <shebs@apple.com>

   Jim Kingdon wrote:

   > But I guess the GCC system makes sense to me.  If something is enough
   > of an issue to be a "technical controversy" in the sense of something
   > people would escalate to the chief technical maintainer/team, you kind
   > of want to get people on board as much as possible.  Because if you
   > proceed without _some_ level of consensus (not among the whole world,
   > but at least among a small group of people most involved), then it
   > creates various kinds of pain.
   > 
   > I mean, there is almost always a way out (e.g. make it an option or
   > something, if there really a demand for both solutions).

   The hard part comes when somebody has to make a single choice.  For
   instance, Linus has often had to make arbitrary decisions, in some
   cases without necessarily being the big PCMCIA-PS/2-bridge :-) expert.
   But in general people agree that his involvement has been better for
   Linux' continued evolution than not.  Could a committee have done as
   well?  Hard to say.

Personally I think it is important that decisions are made in a
relatively short time.  It would be very frustrating if a change is
rejected when a committee member who has only responded after several
weeks says "no".

   > One thing I don't want to be single-string is the process of making
   > checkins which are believed to be relatively uncontroversial.  Right
   > now there is a big problem when the person listed in MAINTAINERS for a
   > particular file gets busy or is on vacation or whatever.  Or to put it
   > another way, being a maintainer should grant you the right to overrule
   > other people but it shouldn't grant you the right to stop things in
   > their tracks.  Or something like that.

   Absolutely.  I hope that every maintainer has sent in their login info
   and ssh keys and all, there should be no obstacle to them making
   their own commits now, right?

The glibc project has a single maintainer.  This works great because
he usually responds within a day.  And when he is away to a place
without net access he tells us "send your bug-fixing patches to this
other guy having write access, other things will have to wait until
I'm back".  However, the nature of the glibc project has as a
consequence that patches are usually small, and thus easy to review.

One of the problems with GDB development right now is that the time
between submitting a patch, and integration of the patch is too long.
In the past there was the problems that external developers had to
wait untill the next snapshot.  But also the amount of time available
to some of the maintainers is apparently very limited.

As a response contributors do not choose to feed improvements in small
incremental patches, but in large chunks, which take more time to
review.  The maintainer cannot find the time to review the patch in
the next few days and adds it to his backlog and tells the contributor
that he'll look into it eventually.  The contributor doesn't want to
ping the maintainer too soon, a workaround is added to the GDB in his
favourite distribution and he isn't confronted with the problem
anymore.  The contributor gets busy with other things and doesn't
contribute to GDB anymore.

To achieve this we need more people that can say whether a patch can
go in for some area's (most notably the ports for non-embedded systems
and the processors that aren't that much on embedded systems).

Mark