This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [maint] The GDB maintenance process


> 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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]