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

[Egbert Eich]

Keith Packard writes:
 > 
 > Around 14 o'clock on Mar 2, Egbert Eich wrote:
 > 
 > > For releases there should be a release branch. This should be off
 > > limit for everyone except the people who are involved in the release
 > > process.
 > 
 > Hmm.  I'd rather see the release done on HEAD; otherwise, there's work to 
 > be done to make HEAD current after the release, which seems error prone.

I don't expect this to be the case. If the release branch will only
receive bug fixes there should not be much that's going on there.
It may be slightly more difficult in the Xorg case as we have decided
to delete a bunch of stuff *after* the branch was cut. This should
normally not happen at release time.
The release branch would get merged into the trunk after the release.
It would stay around and can be used for bug fix releases. Bug fix
releases are what is required for vendors who by definition are 
only able to ship bug fixes not new features for a certain release
of their products.

 > 
 > That presumes that most commits during a release process will be focused 
 > on the release, which seems sensible for me, but may not be right for 
 > everyone.

Right. Not everyone is involved in a release. And it allows to cut
a release branch early to give it some soak time.

 > 
 > Perhaps a 'shared' branch could be formed for people who want to ignore 
 > the release and just keep working?
 > 

Then you have the merge issue again. I'd expect that would involve
a lot more trouble than merging bugfixes back.

Do we agree that we are discussing this on the wrong list?

This list has an audience that is primarily interested in
release issues. We should move this discussion to the Xorg@fd.o
list.

Egbert.