This is the mail archive of the
mailing list for the GDB project.
Re: [maint] The GDB maintenance process
Jim Blandy writes:
> Andrew Cagney <ac131313 at redhat dot com> writes:
> > > - 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.
> > For the record your name is top of the list of that `some maintainers'.
> I think the explicit hierarchy we have now, outlined in MAINTAINERS,
> is a real problem in this sense. It's a big, public, political deal
> to rearrange that hierarchy. There are other systems where the
> processes of promoting promising contributors and clearing dead wood
> happen smoothly and automatically, without confrontation. People
> contribute as they are able, and leaders emerge and recede in a
> natural way, not by fiat. The Apache system, for example, encourages
> newcomers to acquire expertise in different areas, and allows less
> responsive people to simply fall to the wayside as irrelevant.
> These systems are in widespread use, and I think some are even
> well-documented, like: http://httpd.apache.org/dev/guidelines.html
"Membership as a Committer is by invitation only and must be approved
by consensus of the active Apache PMC members. A Committer is
considered inactive by their own declaration or by not contributing
in any form to the project for over six months. An inactive member
can become active again by reversing whichever condition made them
inactive (i.e., by reversing their earlier declaration or by once
again contributing toward the project's work). Membership can be
revoked by a unanimous vote of all the active PMC members (except the
member in question if they are a PMC member)."
How is being a member of the 'Committers' by "invitation only" not
going to be another political deal?
How is the 6 months inactivity period going to help? None of the
current gdb maintainers perticipating in this discussion has ever
disappeared for that long, really. If some person has disappeared
from radar, like relocated, changed e-mail, etc, the person has been
removed from the list. I can think of one such case.
I don't like this one:
"Ideas must be review-then-commit; patches can be
commit-then-review. With a commit-then-review process, we trust that
the developer doing the commit has a high degree of confidence in the