Re: [maint] The GDB maintenance process

[Daniel Berlin <dberlin@dberlin.org>]

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.