This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [maint] The GDB maintenance process
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: Daniel Jacobowitz <drow at mvista dot com>, Jim Blandy <jimb at redhat dot com>, gdb at sources dot redhat dot com, Richard dot Earnshaw at arm dot com
- Date: Thu, 20 Feb 2003 18:32:11 +0000
- Subject: Re: [maint] The GDB maintenance process
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> 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.