This is the mail archive of the gdb@sources.redhat.com 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


I agree with what Daniel has said here.  I'm concerned that some
people have misunderstood his points, so I'll put it differently.

I think GDB could get better use of the contributors it has now by
adjusting the rules for patch approval.

- Slow patch review is a real problem on GDB --- even acknowledging
  the legitimate reasons for some delays that Elena has mentioned.

- It's true that "... some maintainers should try to review patches in
  their areas of responsibility more often", but merely saying so
  doesn't have any effect.  Folks have been saying that ever since
  Cygnus loosened its grip on GDB and the process opened to the
  public.  That statement seems to express a hope that the maintainers
  will somehow "wake up" and everything will get better.  It's been
  years, now, and we need to stop waiting for this to happen.  Let's
  work with the people we've got, rather than hoping they'll transform
  themselves somehow.

- If we accept that the maintainers' behavior is stable, then the next
  alternative is to adjust the organization that they operate under.
  Is there some way to re-organize the people we have, accepting their
  job committments and personal limitations (I have myself in mind
  here as much as anyone else, so don't be affronted), so that things
  progress better?  Is the current organization optimal?

Set that line of thinking aside, and consider another problem:

As far as I can tell, the Global Maintainers don't really have the
privileges that one would expect.  A Global Maintainer ought to be
someone who can make or approve a change anywhere in GDB.  This means,
in addition to having good technical judgement, that we trust them to
ask others as appropriate, and that we consider them good people to
debate with when a disagreement does come up.

This is different from the current definition --- as far as I can
tell, Global Maintainers aren't really that much different from anyone
else.  I've seen them criticized for approving changes, not because of
any specific problem with the changes, but because it was seen as
outside their purview.

I would personally be happy to see the current list of Global
Maintainers, of which I am a member, emptied out, and have people
re-establish their reputations to be added to the list, if it would
make folks more comfortable about straightening out the definition
this way.

So, to bring the two threads together: I think GDB could get better
use of the contributors it has now by relaxing the rules about who is
allowed to approve a patch.  With the redefinition of Global
Maintainer we're suggesting, more people would have the right to
review and approve a patch, so there are more chances someone will.

When I was maintaining Guile, I ended up replacing my dictatorship
with a group of four maintainers --- Mikael Djurfeldt, Maciej
Stachowiak, and Marius Vollmer.  Any one of those guys I trusted as
much as I trust myself.  There was no risk in making them my peers,
since I was just as likely to make a poor decision as they were (if
not more so), and if they didn't like something, it would certainly
benefit from a re-examination.  Surely we have people in the GDB
community in addition to Andrew who have earned that level of trust.


Just to add another idea to the mix:

I was talking to a friend of mine about the way GDB is run, and he was
amazed that we give individual people complete power, and complete
responsibility, for sections of code.  Everyone is going to be wrong
sometimes, he said, and it's easy to protect against, without being
too bureaucratic.

In the Apache system, which is used now in a lot of projects, they
have a pretty big group of global maintainers.  Any non-obvious core
change needs to be described on the list, and get three "+1" votes
from other global maintainers.  But if anyone posts a "-1", the change
is vetoed: it gets discussed for a longer period, and then put up for
a straight vote.

The nice thing here is that *nobody* has absolute power --- come on,
even the most talented among us is going to do something questionable
every so often, and would benefit from some more discussion --- but
it's still easy enough to get buy-in for most changes that it's
efficient.

But whether or not you like that idea, GDB has been operating under
basically the same system, and suffering the same problems, long
enough to confidently conclude that we, at least, are always going to
operate the way we do now under the system we have now.  This
delegated dictatiorship (with all due respect to our hard-working and
conscientious dictator) is more of an inherited legacy from ancient
days than a well-tuned process.  I think it's time to try to bring in
good ideas from other projects, like GCC and Apache.


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