This is the mail archive of the gdb@sourceware.org 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: Maintainer policy for GDB


On Sat, Nov 26, 2005 at 12:03:40AM +0100, Mark Kettenis wrote:
> I've not contributed much to this discussion.  For one thing I've not
> had too much time over the past two weeks to actively participate, and
> the time I had, I spent on writing code and fixing bugs.  I really
> think that at most we need a set of guidelines; not a set of spelt out
> rules.  I let the time I wait for approval depend on several factors:
> when my change is complex, invasive, etc. I'll probably wait months
> before I'll commit the patch without explicit approval.  If the patch
> is borderline obvious, I'll usually ask for objections and commit if I
> don't see any within a few days.  I'll also check whether I see any
> posts from the responsible maintainer on the list.  If he/she is
> usually very active, but not posting to the list for a while, I'll
> just wait until he/she is back again.  I think in general this works
> pretty well, and if for some reason a particular maintainer expresses
> his/her unhappiness with my action I try to change my behaviour.  I
> think that's the way we should interact with each other.

I think that's the most effective way to get things done _at present_.
But at present, not much does get done.

The problem is that it's very touchy-feely.  You have to have a mental
profile of what every maintainer wants.  You have to constantly worry
about stepping on someone's toes.  You have to be willing to wait -
sometimes for a very long time - to fix bugs in "other people's code".

The common parts of GDB, the parts where we do currently have (mostly
busy or inactive) maintainers... and the wide-reaching interfaces that
it hurts to even touch... they're terribly out of date.  I strongly
believe that GDB needs to evolve if it wants to stay relevant.  I'm
trying to create an environment where:

  - The people who are interested in improving GDB can do so.
  - New contributors don't find posting GDB patches to be a futile
    and frustrating (sometimes baffling) experience.  Which they
    currently do.  I've spoken with plenty of contributors who
    felt this way in the last two years.
  - Consequently contributors to GDB are more likely to stay around
    for the long term, help GDB grow, and share the maintenance
    burden.

> Yes we had problems in the recent past with a particular maintainer.
> But I still think the other maintainers (including myself) are partly
> to blame for that situation.  Trust between maintainers was broken,
> but you're not going to restore that trust by formulating some strict
> rules.

The situation I presume you're talking about is not the problem I'm
trying to solve.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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