CVS access policy, branching/tagging, code review, etc.
Mike A. Harris
Tue, 2 Mar 2004 01:27:39 -0500 (EST)
This topic has been asked a lot recently by people in IRC and
elsewhere, but nobody is quite sure yet what exactly the official
answers are, or who in particular decides. Since this is
intended to be an open community project, I figured the best
place to post my query was probably here for open discussion,
rather than to any specific individual(s).
We need to put together guidelines for how:
- Does one gain CVS write access to the repository, who needs to
be contacted, what steps need to happen before access is
granted (if any), who decides, etc.
- what the official do's and dont's are in the tree
- what happens if someone commits something non-trivial without
proper code review, which others believe should not have been
committed, or which horribly breaks the tree, etc.
- A specific guideline for the naming of CVS tags, branches, etc.
- What type of checkins are permitted into particular branches
- What happens if someone consistently violates the accepted
written or defacto policies and shows disregard for the
established guidelines repeatedly.
As well as some simple guidlines on how:
- to properly tag the tree with a particular tag
- to branch properly
- to import external code into the repository such as
Mesa/Xft/Xrender/etc. (ie: tag/import/tag/cleanup, or whatever)
And for code review:
- What types of fixes/checkins are considered ok to do without
review (and on which branches, and during what phases of
- What types of changes ALWAYS require review either via bugzilla
filing or email list posting and having one or more people
"ACK" (acknowledge) the fix is acceptable for the tree, or
"NACK" it indicating it is unacceptable, and providing a reason
- What types of changes are good ideas, or worth exploration in
the future, but are not acceptable changes for the current
goals of releasing a stable release as soon as possible, such
as Phase2/Phase3 type of work, source code beautification,
I've been putting together a document for some of this, with
plans on posting it when it's more complete, however I think now
is a good time to harvest some thoughts from the other
participants as well. I can then use this feedback in my first
draft, and when it's ready, I can post it to the list.
Constructive comments and feedback are appreciated.
Mike A. Harris