Re: [Gdbheads] proposed change to GDB maintainership rules

[Michael Elizabeth Chastain]

Let's see if I can address Ian's question while being sensitive to the
touchy issues.

I agree with David Carlton's scenario: symbol table work goes unreviewed
for months, and then it gets reviewed and merged after the announcement
of the date for cutting gdb-6_1-branch.

This gets to the issue of: when is a patch just a patch; and when is a
patch actually part of a branch merge that's meant to change the policy
of gcc.

gcc has a process for this: branches and stages.  In gcc terms, we're
evolving a process where branches get merged in stage 3, which is bad!

It might help to adopt a similar process, where we merge branches after
a gdb release, and then we have most of the release cycle to handle the
fallout.  In particular, the people who would have to review these
patches would know that a lot of activity is coming in April 2004, and
then not much activity until (perhaps) December 2004.

For QA: I am testing carlton_dictionary-branch and drow-cplus-branch
now.  I can cover the question "does a branch have test suite
regressions compared to HEAD".

As far as the present proposal goes, to give every global maintainer
authority to approve patches in every area, I am
neutral-towards-positive on that.

Michael C