cvs procedures

[Paul Richards <p....@elsevier.co.uk>]

Here's a start on cvs procedures which I discussed with Ben last week. It's
really late and I need to go to bed but I'll propose the basic idea so that
people can start providing input.

-------

The cvs repository is open to all who are granted cvs commit privs. At the
moment this is basically anyone who asks and is known to me. In the future
we need a commit mailing list with just the commit folks on it who will
then decide future policy on cvs access and grant or exclude people on merit
as determined by that group.

Every two weeks we release a development snapshot which will be named
using the release that is likely to be next and a date stamp. i.e. at the
moment they would be called 1.1-dev-ddmmyy. Following a snapshot
release everyone can freely commit to the tree without any voting or
peer review. Peer review is still highly recommended on a voluntary basis
for complex or possibly contentious changes to speed up the voting procedure
that follows. Since cvs is an immediate thing people can and should keep their
local sources up to date and continually try new code as it goes into the
tree. That way, problems should appear and also get fixed much more quickly
than they do currently.

Every two weeks, a vote will take place to determine whether or not the next
snapshot should in fact be released.  This will be a simple yes/no vote with a
no vote basically vetoing that snaphsot.  A veto must be accompanied by an
explanation of what part of the current tree is unacceptable and why.  If that
veto can be dealt with simply and quickly then hopefully the veto can be
withdrawn after a quick fix up and the snapshot released as normal.  The fix may
either be in the form of further refinement or possibly the removal of the
problematic code.  If possible this will be done using an #ifdef so that a
snapshot can be released while still allowing experimental but possibly buggy
code to remain in the tree.

In some cases, a veto will cause a prolonged discussion as to what the correct
course of action should be. In these cases the tree should be frozen until
the issues can be resolved. These should be rare occasions and the code
freeze should be for only short periods, like a day or two, and not the
prolonged code freezes associated with release cycles.

This two week voting/snapshot cycle should provide the peer review process
that people want in much the same way that the current voting procedure does
but hopefully using cvs will mean that development can proceed much more
quickly between voting rounds and that if problems do arise with code changes
they can be detected and fixed as soon as they go into cvs rather than when
the voting procedure starts.

Eventually, people will want to make a full release. At this time the tree
should be tagged and branched. The development branch will then continue
as normal with the two weekly snaphots while the -release branch will enter
a code freeze. A beta release will be made and widely distributed to beta
testers. The -release branch will then undergo a prolonged code freeze and
bug fix cycle until it is ready for final release. Development will continue
in parallel and should not be held up as it was last time.

This isn't a "formal" set of procedures, it's more a start of the discussion
and roughly how me and Ben see things working and this was written off the
top of my head now so I may have forgotten some of the points Ben had so
he may disagree with some of this :-)