CVS access policy, branching/tagging, code review, etc.

[Keith Packard]

--==_Exmh_-1592244130P
Content-Type: text/plain; charset=us-ascii


Around 1 o'clock on Mar 2, "Mike A. Harris" wrote:

Here are some ideas for discussion...

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

I'd like someone to review a couple of sample patches before granting 
commit access; that way we can check that the general coding conventions 
are being followed; that's hard to check any other way.

> - what the official do's and dont's are in the tree

There will probably be a lot of these, here's some suggestions:

 *	Do new scary work on a branch

 *	But, integrate scary work into HEAD with #ifdefs to avoid divergence

 *	Announce release schedules and limit HEAD changes after feature 
	freeze.  Permit branch changes.

 *	After RC1, limit HEAD changes to fixes for major bugs.

 *	Separate code cleanup from functional changes.  Mark cleanup 
	patches clearly.  For major cleanups, get peer review before 
	committing.

 *	Get Bonsai and Tinderbox working together; require commits that
	break the build to be fixed or get backed out within a short time
	frame (~days, not ~weeks)

 *	Don't commit huge changes and then go on vacation (see above).

 *	Tag and release on a regular basis.

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

 *	Any changes for HEAD which don't have rough concensus should be reviewed
	and voted on.  I don't know who should vote.  I don't know if the
	vote should be a simple majority, or if we should require rough 
	concensus and a czar that accepts or rejects the patch.  If a 
	change is committed to HEAD which generates more heat than light, it
	should be reverted until the issue is resolved.

 *	Any changes to HEAD which break the build should be reverted unless 
	fixed in a timely fashion

 *	Changes to HEAD which generate negative rough concensus should be 
	reverted by the committer and discussed.

 *	Changes to branches are pretty much anything goes, unless they
	conflict with the law or PSU policy (i.e. don't append MP3s 
	to CVS files).

> - A specific guideline for the naming of CVS tags, branches, etc.

always tricky.  For development branches, I'd like to see them tagged with 
userids of the person doing the branch along with a date in ISO standard 
format (yyyy-mm-dd).  An additional tag indicating the scope of the work 
might be nice.  So, perhaps
	
	keithp-2004-03-02-hacking-damage

Using dates without dashes makes them really hard to read for some of us.  
Mixing hyphens and underscores makes them prone to typos.

I don't know whether such branches should also be tagged with the base 
revision number, I'm thinking that that won't be necessary.

For tags along the main branch that indicate release points, let's follow
a pretty simple convention.  I suggest that there are two kinds of tags, 
there are 'module' releases and 'product' releases, and 'products' are a 
collection of 'modules'.  When releasing a 'module',  tag with

	modulename-major.minor.revision

Similarly, when releasing a product, tag with

	productname-major.minor.revision

Tags along a branch should be prefixed by the branch name.  yes, this will 
make them rather long.  I hope that will encourage people to get branches 
merged back to head more often.

> - What type of checkins are permitted into particular branches

I'd like to see most 'mainline' development occur right on HEAD; otherwise 
one spends a lot of time merging stuff back.  Unlike DRI, I don't see a 
huge number of module interface changes which would require careful 
coordination, so I don't want to force people to make branches just to fix 
minor bugs or implement minor new functionality.

However, I see the release process as three phases:

 1)	liquid

	Add code to HEAD as long as it is has rough concensus to be
	"good".

	Speculative code, or 

 2)	slush

	Add code to HEAD as long as it addresses planned release features
	or bug fixes.

 3)	ice

	Add code to HEAD as long as it fixes major bugs.

> - What happens if someone consistently violates the accepted 
>   written or defacto policies and shows disregard for the 
>   established guidelines repeatedly.

Failure to roughly follow the policy should result in probationary access 
to the tree where patches would be reviewed by another committer before 
being applied.  This would last for a while (two weeks?) and for a number 
of patches (3?).  No mechanical enforcement of this should be needed, but 
violation of probation should result in revocation of CVS access.

Note that CVS access is completely separate from freedesktop.org account
access; we haven't established a policy for that and perhaps it is time to
consider doing so.  About the only thing that would cause people to lose
their fd.o accounts is illegal or obviously inappropriate activities
involving the fd.o machine or the PSU network.

> - What types of fixes/checkins are considered ok to do without 
>   review (and on which branches, and during what phases of 
>   development).

On branches, anything goes.  Merging branches back to HEAD should follow 
the review requirements as if the merge was one giant commit.

On HEAD, no review is required for:

 1)	Bug fixes that are "obvious to a skilled practitioner"

 2)	Changes previously agreed upon.  I'd like to see this in the form
	of a mail message laying out the scope of the work, large changes
	should be documented in the wiki and referenced from the message.
	Lack of dispute should be taken as concensus.

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

 1)	Bug fixes which are non-obvious, especially in really stale code.

 2)	ABI/API changes.

 3)	Changes which don't generate rough concensus when they zip by.

> - 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, 
>   lindent, etc.

The monolithic tree should be considered to already be 'ice', and 
receiving only major bug fixes.

Flame away.

-keith



--==_Exmh_-1592244130P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.3.1 11/28/2001

iD8DBQFARMuxQp8BWwlsTdMRAgRuAKCZ6JKj7r/vTsY95975LoTQ86vprQCdHHaq
fDT2xWQSYJ9HFYwSyPc8KRU=
=J0on
-----END PGP SIGNATURE-----

--==_Exmh_-1592244130P--