This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [maint] The GDB maintenance process
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: Elena Zannoni <ezannoni at redhat dot com>,Andrew Cagney <ac131313 at redhat dot com>,gdb at sources dot redhat dot com
- Date: Wed, 19 Feb 2003 08:24:22 -0500
- Subject: Re: [maint] The GDB maintenance process
On Tuesday, February 18, 2003, at 08:49 PM, Daniel Jacobowitz wrote:
Thanks to everyone who responded; I'll try to address everything.
I want to share a piece of perspective on why I raise this issue now.
I'm finding the GDB development process to be too slow to be workable -
patches take a month or more routinely, and I don't have the time to
juggle them for that long. I'm facing that I may need to back down my
level of involvement as a consequence of how awkward the development
model is for getting any forward progress.
A few days ago, I actually ran statistics on how long it takes for a
patch to get first review in gcc vs gdb over the past year, and for
gcc, it's 2.some odd days. Believe it or not, for gdb, it was well
over two weeks.
That's not good.
Outliers are the norm in gdb, there was no middle ground.
Either something takes 1 day to get a review, or it takes months.
The only reason the average is actually only a little over two weeks is
because of a string of 0 day turnarounds that occasionally happen.
Maybe that means that I just don't have the time and the patience to be
a useful contributor to GDB. Me, I think that it means that we need to
make the process less painful for contributors.
FWIW, I agree, but i hold no hope it will happen.
I'm not a cynic, i'm just experienced.
I'd be a cynic if it wasn't based on experience, of course.
I have seen sometimes very quick turnarounds on patches during
holidays, and maybe some of such patches should have been thought
through more carefully. If you don't give time to the appropriate
maintainers to chime in, the entropy can become way too high, with
patches, and reverted patches going around.
I guess I just don't see this to be as much of a problem as others do.
For one thing, with the higher entropy level, more development actually
happens.
Bingo.
I don't think we should stall development (and in the extreme, even if
it means we can't make quality releases any day of the year) because
mistakes occasionally happen in patches, or because not every
maintainer in existence has said something about a patch. That's a
recipe for no progress. The old "adding more developers to a late
project makes it later because of communication overhead" problem.
Another thing to think about: because of the layout of the above,
there is
frequently no one who has the _right_ to approve a patch. They
require
buy-in from a number of additional maintainers. In addition our
volunteers
are often too busy to find time to respond to patches. This impacts
patches
from other maintainers (frequently, but generally a small impact)
and from
outside contributors (happens less frequently, but larger impact -
most of
these never get approved at all, from what I've seen).
Wait, lots of external contributor's patches never make it in because
of the copyright assignment problems.
Bull.
This counts for *maybe* 10% of patches that don't make it in, if that.
Also I see external people
dropping patches, not because the are not reviewed, but because they
*are reviewed*. I.e. a patch is submitted, I ask for some changes, and
the person never comes back with a new patch.
Or maybe it's because frequently the review took >1 month, and they
just don't want to spend that much more time waiting again after making
changes, or they moved on to other projects.
Have you noticed GDB *very rarely* keeps minor contributors coming back?
OTOH, most opensource projects (including gcc) i am a part of
frequently have the same minor contributors, again and again.
Maybe we need community exit interviews to back this point up.
Are we talking about the same thing? I don't think I understand you.
First of all, the idea of a small, fully funded elite taking control of
the project doesn't make any sense to me. Either their changes are
worthwhile - the existing maintainers will cooperate with them - or
they overstep their boundaries - they are asked to cease. We don't
hand out maintainership to all comers.
Well, they gave it to me (and Stan Shebs :P) at one point, so ...
:)
That's not accurate. First of all, the comments relate to all three of
the phases in the GCC development process, although the effect is
mostly damped down in the third phase by the release manager's hand.
Even in stage 3, other maintainers are free to exercise their
judgement.
Also, the GCC tree spends most of its time in a more useful state than
the above really portrays.
Yup.
Andrew's just plain wrong on this one.
All patches are bootstrapped and reg-tested on at least one platform,
and those that are larger or could affect multiple platforms are
bootstrapped and regtested on multiple platforms.
Any needed stabilization is generally because of latent bugs in
*other*, less tested platforms, that improvements expose.
*Not* problems in the patches themselves.
For GDB, on the other hand, interesting development can and does get
approved/committed at any time. GDB snaps are of such quality that we
can confidently refer someone to current sources for fixes (except
when I have a bad day like today :-). Further, instead of using
official releases (and as you yourself have done) arbitrary snaps can
even make their way into a distro.
[Red Hat does this too, by the way.] Having done it, I've resolved to
avoid it in the future. Costs outweighed benefits.
I agree that it should be avoided, too.
It's just painful and not necessary here.
Our users don't clamor for a release on a certain date, nor have we
ever had a need to make one.
The only advantage this adds is to companies using gdb sources and
wanting to do merges to an internal tree.