Re: [maint] The GDB maintenance process

[Elena Zannoni <ezannoni@redhat.com>]

Jim Blandy writes:
 > Andrew Cagney <ac131313@redhat.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
 change."