Re: [Gdbheads] proposed change to GDB maintainership rules

[Andrew Cagney]

Rather than hypothisize as to what could be, I prefer to look at the
evidence and determine what is.

I think we should start with some positive highlights of the last year 
(RMS, perhaphs skip to the second part):

The last year started with one of GDB's most significant maintainer
re-orgs: many of the [less active] developers stepped back, finally 
allowing more active core developers (and others) to take responsibility 
of those parts of GDB.  A notable and positive example of this is 
breakpoints, that area had previously been a regular source of problems 
when it came to patch review.   This change also resulted in me spending 
[wasting] significantly less time chasing non-responsive reviewers.   (I 
need to follow up an [of-list] proposal to formalize the "ping after a 
week" part of submitting a change.)

2003 also saw me try a new approach to assignments (this is handled off 
list).  In the past new contributors were being asked if they had an 
assignment very very late in the patch review process, often after it 
had been "approved" :-(  This year, instead of waiting for, or pinging 
GDB's assigment's clerk (lack of response there has been a problem), 
I've endevored to contact contributors up front.  To quote one 
respondant "did you read my mind?", I think this has significantly 
smoothed the new-contributor process.  (althoug there's also been the 
occasional botched job, sorry).

Finally, and most importantly, I think during 2003 it became apparent 
that GDB's community (as identified by those participating in GDB's 
development processes - reviewing and contributing patches, engaging in 
disucssion, testing, ...) was, for the first time, being dominated by 
non-"Cygnus" players.  Assuming this state of play continues, we should 
finally be able to slay the "Cygnus controls and dominates GDB" dragon.

With this in mind this year saw:

- the rewrite of the frame code which facilitiated ...

- the implementation of generic CFI support

- and the long overdue overhaul of many architectures

- the addition of objective c

- the startings of the long overdue breakpoint rewrite

- a real effort to address long standing namespace, C++ and even Java 
and thread problems


Unfortunatly, last year also saw negatives:

- the old perenial - patch review problems

Here, as already noted by DavidC and JoelB, the persistent repeat 
offender, "symbol table", is again before the judge:

Over the years I've seen people been effectively paid full time
to fix this,  I've seen people pound their chest and promise
to do better,  I've seen people talk of grand rewrites,  I've even had 
to defend GDB from complaints that symtab patches were intentionally 
being ignored.

Only in the last year have I seen people actually tackling the problems. 
 David Carlton and Elena Zannoni now, at least, working through things.

In passing, I should also mention threads.  As I've noted in another 
post, both MichaelS and MarkK have indicated that they no longer feel 
comfortable reviewing or maintaining code in this area so I guess they 
are planning on droping that from their responsabilities.

- the other GDB perenial - stagnation

More for the record.  I'm always seeing pressure to slow GDB's 
development, principably because it makes the maintenance of 
uncontributed code harder.  Last year saw an increased level of pressure 
intended to slow GDB's development, I'm guessing in responce to an 
increase in GDB's rate of development.

- the other other perenial - old dormant / inactive developers

There is still no clearly documented process for addressing this. 
Adding more developers to an area appears to be approach used by GCC? 
It's only a short term solution.

Andrew