|
From: | Michael Snyder |
Subject: | Re: [Gdbheads] proposed change to GDB maintainership rules |
Date: | Fri, 30 Jan 2004 11:46:57 -0800 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 |
Ian Lance Taylor wrote:
David Carlton <address@hidden> writes:I don't work on breakpoints, so I hadn't noticed this particular example; the main benefit that I saw of this pruning is that the testsuite had no local maintainers, which all of a sudden meant that any global maintainer could approve testsuite patches, which meant that a _lot_ of testsuite patches went in.I would have to agree that any global maintainer ought to be able to approve patches to any part of the code. That is how both gcc and the binutils work, and I think it has proven to be effective in practice.
This is how I always understood gdb to be working too. I was stunned when Andrew announced one day that it wasn't. When we transitioned from the former mostly-cygnus maintainance to the current arrangement, we somewhat arbitrarily divvied up some of the components of gdb and assigned them to individual maintainers -- but my understanding of that was that it was intended to make sure that there was somebody whose job it was to review a patch *if no one else did first* -- not that the designated person was the *only* maintainer entitled to review a patch. The former would help patches get reviewed. The later would inhibit them from being reviewed. I do not understand how we ended up with the later, but that's what we seem to have now, and the upshot is that patches sometimes don't get reviewed.
Mind you, both projects have additional rules, like patches may not cause testsuite regressions, and, if they do cause regressions which are not fixed, any other global maintainer can revert them freely.
We've never spelled out the later, but the former is well understood.
[Prev in Thread] | Current Thread | [Next in Thread] |