[maint] The GDB maintenance process

[Andrew Cagney]

>>  > Right now, we use stricter policies to prevent problems which cause
>>  > breakage.  I think these policies are stifling us.  Loosening them (and
>>  > maybe adding a formal patch reversion policy) would let more people fix
>>  > problems more easily, as they arise, without slowing development.
>>  > 
>> 
>> I really think that having the bug database track patches is a very
>> big improvement. We should try to push its use a bit more before
>> giving up on the current rules. 
> 
> 
> I don't like it, but that's just my general anti-GNATS rancor.  Maybe
> Bugzilla will be better.

The idea of tracking things as bugs or GNATS?

Tracking this stuff in a public database is, I think, clearly better 
than the status quo (my mailbox).  It's already been mentioned that 
there is possibly a lack of response with some maintainers.  At least 
with me putting unreviewed patches in the database, we can figure out 
what patches there are, and if there is a problem.  (my todo list 
includes checking that all the key developers are on the bug tracking 
list, I suspect that some are not.)

Anyway, have a look in the database, you'll notice all sorts of 
interesting things.

For instance search for tdep & h8300.  There is an obvious backlog and 
someone (a global maintainer like yourself or I) needs to step up and 
work through them with the contributors.  That task, while no where near 
as glamerous as a new feature, is absolutly needed and maintainers do 
need to be willing to chip in (in fact I think that task and 
documentation should be given a higher profile when handing out 
`credit').  Hopefuly these patches will even yield a new developer.

Andrew