RE: [maint] The GDB maintenance process

[Zaretskii Eli <ezaretski@elta.co.il>]

This message was scanned for viruses and other malicious code by PrivaWall.


This mail was sent from ELTA SYS LTD.


> From: Jim Blandy [mailto:jimb@redhat.com] 
> Sent: Wednesday, February 19, 2003 4:18 AM
> 
> - 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.

GDB maintenance is not the only place that needs to deal with that
problem.  We don't have to reinvent the wheel, or feel that we face an
insoluble problem, and neither do we need to make drastic changes in the
current commit paradigms.

More to the point, if we think that some maintainers don't respond fast
enough, we could bring more maintainers on board.  The primary
candidates for becoming new maintainers are those people who push
significant patches in the areas where the current maintainers are slow.
In other words, let those who are unhappy with the current situation put
their money where their mouth is and help with the burden.

We could also ask a maintainer to step down if he/she cannot keep up
with his/her duties in a timely manner, or we could grant the head
maintainer (or a group of veteran maintainers) powers to declare that
someone has effectively stepped down due to lack of responsiveness.

These are all minor modifications to the existing model.  If someone
thinks that they will never be effective enough, let them explain why.

I'm not against changing the model to something like commit-then-review,
mind you.  But please don't underestimate the implications of this on
the social dynamics within our team: reverting changes, while
technically easy, tends to leave bad after-taste and hurts
relationships; the arguments about whether to revert a patch tend to be
ugly.  We should ask ourselves if we are willing to pay that price.


This message is processed by the PrivaWall Email Security Server.