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

Daniel Jacobowitz writes:
 > I get the feeling I'm already pretty unpopular for some of my opinions on
 > how GDB maintenane should work.  This isn't going to make it any better, but
 > I feel it should be said.

OK, I'll take the bait. No offense intended. Just read until the end.

 > I believe that our current process has some problems.  Let me try to
 > explain.  First, to make sure we're all on the same page...
 >  What does it mean to be a Global Maintainer, in practice?
 >   - A certain amount of autonomy in the areas of GDB that no one wants to
 >     take specific responsibility for.  There's no specific maintainer for
 >     things like the frame support or the type/value systems.
 >   - A little more freedom in approving patches to other people's areas of
 >     GDB - not a lot, but it's definitely there.
 >     [In practice, this depends on:
 >      o How much risk you're willing to take of annoying people.
 >      o How likely other maintainers are to shout at you about it.]

The above point is not part of the global maintainer description. I
take you want it to be? I don't agree. It just makes it possible for
particularly 'active' individuals to dominate the list and removes
the more egalitarian feel that this community has. You can say that
the linux kernel community is like that, and that gcc is like that,
etc, but we don't have to be. 

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.

 >   - Authority to approve patches covering general debugger issues.
 >  What does it mean to be a maintainer for a specific host/target/subsystem,
 >  in practice?
 >   - The authority to approve patches and apply your own patches to that area
 >     of the debugger.
 > I'd like everyone to notice one thing missing from the above list.  No one
 > has the _responsibility_ for approving patches.  This is a volunteer
 > project, and anyone who's watched it in action for a little while will see
 > that the volunteers are often busy and distracted.  There's no one who
 > can handle or should have to handle the responsibilities of patch approval.

So, you are proposing that we let the vacuum be filled with heroics?
I.e. quantity vs quality.

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

There would be also something to say about championing your patches,
ie, push a bit. For instance this is what David is doing with the
namespaces stuff, he is keeping me posted, and he makes sure I don't
fall asleep at the wheel. 

Just saying, things are not as black and white as they are portraited.

 > Some other GNU projects have a similar setup and don't have this problem. 
 > GCC and binutils are my usual examples.  How do they avoid it?  They have a
 > different definition of global maintainer.  That's what ours used to be
 > called - Blanket Write Privileges.  The system works a little differently:
 >   - Maintainers for specific areas of the compiler can commit/approve
 >     patches to the areas they maintain without buy-in from a blanket
 >     maintainer.

I think you are misunderstanding. Gdb is like that. If one maintains
one area, that's it, period. His/her approval is enough. Even if the
maintainer is not global, the authority is the same *in that specific

 >   - Blanket maintainers can commit/approve patches anywhere without buy-in
 >     from a specific area maintainer.
 > [I hope Richard will forgive me for using him as an example and for putting
 > words in his mouth...] This doesn't replace common sense - you generally
 > won't find Richard Henderson approving patches to the C++ frontend, because:
 >   - He knows he isn't familiar with it
 >   - He knows it has an active set of maintainers at all times
 > Similarly, just because he can check in patches to any target backend, that
 > doesn't mean he won't ask a target maintainer to look over it first.  If
 > someone objects to a patch in their area, he would generally not just check
 > it in anyway.  If they object to it after he checks it in, the two will
 > discuss the problem like reasonable people and come to some agreement.
 > Some noticeable differences between these two models:
 >   - In the GCC model, more people are able/likely to check in patches which
 >     break things.
 >   - But in the GCC model, more people are able/likely to check in patches to
 >     fix it afterwards.
 >   - Because more people have the privilege of approving a given patch,
 >     and fewer people's approvals are needed for any particular patch,
 >     patches (usually) get approved more quickly.
 >   - Development can happen more quickly, and does not get slowed to a
 >     standstill when (say) one of us is pulled off of community GDB work for
 >     an urgent customer project.  This happens all the time - I've never seen
 >     all the GDB maintainers with time for GDB at the same time.

Yes, we have day jobs, that are not 'work on FSF gdb'. If you loosen
the rules, then it becomes possible for a small, fully funded, elite to
take control.  

And how long would you wait before stepping in? That's a hard problem.
1 hour, one day, one working day, one week? 

 > Right now, we use stricter policies to prevent problems which cause
 > breakage.  I think these policies are stifling us.  Loosening them (and
 > maybe adding a formal patch reversion policy) would let more people fix
 > problems more easily, as they arise, without slowing development.

I really think that having the bug database track patches is a very
big improvement. We should try to push its use a bit more before
giving up on the current rules. 

 > If there are people on our Global Maintainer list that we don't think should
 > be trusted with the extra responsibility of the above, then perhaps we need
 > to rethink who belongs in that list.  I'm not pointing any fingers - I don't
 > have anyone in mind, and I've been quite happy working with absolutely all
 > of the current team.  Just putting the idea out.
 > I've discussed this general situation with a (small) sampling of other GDB
 > developers and contributors - enough to know that I'm not alone in my
 > concerns.  These aren't entirely my own words, either.  I'll let other
 > people take credit/blame for them if they want to, and if I've represented
 > their opinions accurately.

Hmm, I am not too happy with this behind the scenes discontent, if
there is something wrong, let's hear it.

Ok, that said, I too am seeing patches that are not reviewed. So there
are wrinkles in the process. But I don't think that the 'let's take
over' approach is an appropriate solution.


 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

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