gdb-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gdbheads] proposed change to GDB maintainership rules


From: David Carlton
Subject: Re: [Gdbheads] proposed change to GDB maintainership rules
Date: Thu, 29 Jan 2004 09:58:15 -0800
User-agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Reasonable Discussion, linux)

On Thu, 29 Jan 2004 11:14:39 -0500, Andrew Cagney <address@hidden> said:

> I think we should start with some positive highlights of the last
> year

Don't get me wrong - I agree that a lot of good things have happened
in the last year.

> The last year started with one of GDB's most significant maintainer
> re-orgs: many of the [less active] developers stepped back, finally
> allowing more active core developers (and others) to take
> responsibility of those parts of GDB.  A notable and positive
> example of this is breakpoints, that area had previously been a
> regular source of problems when it came to patch review.

I don't work on breakpoints, so I hadn't noticed this particular
example; the main benefit that I saw of this pruning is that the
testsuite had no local maintainers, which all of a sudden meant that
any global maintainer could approve testsuite patches, which meant
that a _lot_ of testsuite patches went in.

Which seems to me like a good argument for our proposed change - the
key reason for improvement in this area wasn't that we stopped letting
Fernando approve testsuite patches, it was that we started allowing
global maintainers to approve testsuite patches.  And even the current
situation isn't as good as can be - I don't think anybody could
seriously claim that Michael Chastain shouldn't be able to approve
testsuite patches, but if we were to name him testsuite maintainer,
then all of a sudden global maintainers wouldn't be able to approve
testsuite patches.  And I don't see how that would help anything.

> Unfortunatly, last year also saw negatives:

> - the old perenial - patch review problems

> Here, as already noted by DavidC and JoelB, the persistent repeat
> offender, "symbol table", is again before the judge:

> Over the years I've seen people been effectively paid full time
> to fix this,  I've seen people pound their chest and promise
> to do better,  I've seen people talk of grand rewrites,  I've even had
> to defend GDB from complaints that symtab patches were intentionally
> being ignored.

> Only in the last year have I seen people actually tackling the
> problems. David Carlton and Elena Zannoni now, at least, working
> through things.

Here's my take on the symbol table situation since I've been working
on GDB.  First, let me make it clear that I have absolutely no problem
with either Elena Zannoni or Jim Blandy - they clearly know a huge
amount about the code in question, their comments are always well
thought out, and I almost always agree with their suggestions.

But they're only two people, they're both busy people.  And they're
not the only people actively working on the symbol table today, or the
most active workers.  I've cleaned up lookup_symbol_aux, started
cleaning up the naming aspects, and added lots of support for
C++-specific symtab stuff.  Daniel Jacobowitz added the location
expression stuff, added the demangled name hash table, is working on
cleanups that will help with the eventual goal of inter-cu references,
and probably other stuff that I've forgotten.  Mark Kettenis added
dwarf2-frame.c.  I'm sure there are other examples that I've
forgotten.

Meanwhile, on three occasions, I've had to wait more than two months
for approval for my patches.  I've emailed the maintainers privately
warning that patches were coming (and that I was changing jobs, so I
wasn't sure how long I would be able to wait; fortunately, my new job
has allowed me to continue to work on GDB occasionally).  I've sent
ping messages.  I've filed patch PR's.  _Nothing has helped_.  (Well,
other than the threat of the 6.1 release - that has made a difference
recently.)

And its incredibly frustrating to have to wait for approval from the
anointed ones while both Daniel and I are eager to get these patches
in, and while Daniel and I have been doing more symtab cleanups than
the symtab maintainers themselves have.  And then when the patches
actually get approved, I have to spend days reminding myself what I
was doing two months ago when I generated the patches in question, or
what I was doing a year ago when I first wrote the code in question,
so I can figure out what the next patch is that I should generate.

So it makes me really angry to hear you basically blame patch
submitters for not pinging the maintainers enough, and talking about
reducing the number of maintainers as a solution.  Believe me, I've
pinged - it's not good enough.  And why on earth would reducing the
number of symtab maintainers help, why is it a better idea than
opening up the process so that people who have shown that they know
the code can approve patches?

David Carlton
address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]