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: Jim Blandy
Subject: Re: [Gdbheads] proposed change to GDB maintainership rules
Date: 29 Jan 2004 15:54:40 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Ian Lance Taylor <address@hidden> writes:

> Jim Blandy <address@hidden> writes:
> 
> > Richard Stallman <address@hidden> writes:
> > 
> > >     Having said that, I would say that, if the rules proposed had been in
> > >     place for the last year, then GDB 6.0 would have had better support
> > >     for C++ nested types and namespaces, and that it would also have had
> > >     non-user-visible changes to improve its maintainability
> > > 
> > > Off-hand I would not say this is a terrible problem--especially if
> > > some of them are being installed now.  I suppose the maintainers had
> > > some reason not to want to install that code as it was written.
> > 
> > You're assuming that the maintainers had reviewed the patch, but
> > didn't quite like it.  But simply getting patches reviewed in the
> > first place takes too long.  This is a bottleneck we think our
> > proposal would improve.
> 
> If the problem is ``getting patches reviewed in the first place takes
> too long,'' then the solution is not voting.  The solution is having
> somebody with the authority and the responsibility to review patches
> who makes patch review a high priority.
> 
> How does voting solve that problem?  It seems to me that you are
> essentially trying to use voting to spread out the authority and the
> responsibility.  Why not do that directly?  Why is voting useful here?
> 
> I'm not asking these questions rhetorically.  I'd like to hear your
> answers.

Our proposal has two parts: one is to allow global maintainers to
approve changes in areas with local maintainers, and the other is to
introduce a voting procedure.  I think the former will help improve
patch approval throughput, by broadening the group of people available
to evaluate a given patch.

Voting won't have any direct impact on that.  If it did improve the
quality of discussion, then that would have a nice impact throughout
the project, but that's a secondary effect.  And voting is just the
best approach we could think of; any other measure that effectively
encouraged building consensus over my-say-is-final arguments would
work as well.




reply via email to

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