This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]