[maint] The GDB maintenance process

[Richard Earnshaw]

> One thing GCC(4) and GDB are now is encouraging exprementation on 
> branches development to always occure on branches cut from the the 
> relevant repository.  For GDB we've had both success stories but also 
> disasters.  With that in mind, and looking at the GCC / GDB success 
> stories, I'd suggest the following guidelines:
> 
> - branches shall post all commits
> They don't need approval but can be commented on.
> 
> - branches shall to be focused
> The interps branch started out too large with too many changes - look at 
> the size of the final commit compared to that branch at its peak.  Much 
> time was lost because the branch started with too much lint :-(
> 
> - branches shall track mainline.
> This keeps the level of divergence under control.  It also keeps the 
> pressure on developers to push cleanups and other stuff into the mainline.

I think there's a few other ground-rules that ought to apply, particularly 
with respect to the first point:

-Branches should have an owner.
The owner can set further policy for a branch, but may not change the 
ground rules.  In particular, they can set a policy for commits (be it 
adding more reviewers or deciding who can commit).

-All commits to a branch must be covered by an assignment
This saves us from the situation where a branch might become contaminated.

R.