[Xorg] X.org CVS branches need to change

[Egbert Eich]

Keith Packard writes:
 > There's a difference between new development and ongoing maintenance of a 
 > partially separate product which happens to share the same tree.  CYGWIN 
 > is a special case as almost all development is either in files which 
 > aren't built on non-Windows systems or consists of changes which *should* 
 > have no effect on non-Windows systems.  As such, most of it should occur 
 > right on HEAD so that we find changes which accidentally break non-Windows 
 > builds quickly.

Yes, lets keep this as an inital rule and see how things work out.
 > 
 > I'd like to see branches used for short periods of development where 
 > changes which are expected to break builds across many platforms are being 
 > made.  Especially in the monolithic tree, I don't expect to see 
 > significant changes being made in functionality or structure.

'short period' depends on how long it takes for a project to get
into a releaseable shape. On DRI projects live on a branch for
a very long time. Please remember that the HEAD branch will be
the base from which release branches will be cut.

 > 
 > > We should always have a branch from which we cut the release.
 > > Together with scheduling features for release this will give us
 > > a finer control over things and allow people to continue working
 > > on whatever the CURRENT branch will be without interfereing with 
 > > the release.
 > 
 > Yes, releases should be done from a branch so that we can do minor patches
 > to those releases.  Again, I think I must have written something confusing
 > about this.  Replace "CURRENT" with "HEAD" and the above statement is just
 > what I want.  However, we aren't even doing the CURRENT->RELEASE-1
 > mechanism at this point as much development is going into RELEASE-1 instead
 > of CURRENT.

No, only the release fixing is going into the RELEASE-1 branch.
Apart from the TM issue pretty much of it has been done already.

 > 
 > > At release time some tinderboxes should be set up to build the
 > > release branch and beta testers schould be directed to this branch.
 > 
 > Yup.  Ideally, the tinderboxes would be building those branches each time 
 > they change from now until we no longer support them (many years from 
 > now).

Right.
 > 
 > > > 2) If XORG-RELEASE-1 is going to be merged back to XORG-CURRENT, then 
 > > > what was the point of branching so soon?
 > >
 > > So you give the RELEASE branch more time for testing.
 > > You never get sufficient testing when you constantly bring
 > > in stuff from active development.
 > 
 > Yes, it's important to branch for a release, but I think in this case the 
 > branch was made prematurely.  "active" development on the tree right now 
 > should be entirely focused on fixing things that are needed both in the 
 > release and in future development.  

Not really. It was consistent with the original goal and to allow people 
to continue working on the CURRENT branch.

 > 
 > I know that we're technically in "feature freeze" right now, which would
 > normally be the time a branch occurred, but we've got a lot of changes
 > needed which don't affect the feature set but which are needed for both a
 > release and future development.

Exactly, however people are continuing their work in the other branch
and some of this may involve things that we don't want to release right
now.

 > 
 > I would hope that this release could be considered a bit special and that 
 > we  treat HEAD carefully until we've finished the bulk of the work needed 
 > to make the tree usable for both a release and future development.

Right.
 > 
 > > Different projects have different models. We should be similar to
 > > what others do but if we are convinced that doing something different
 > > has advantages we should not be the slaves of the crowd.
 > 
 > Right -- the BSD model was not a good fit for us, and I don't think the 
 > DRI model is exactly right either.  We're neither a distribution 
 > maintainer (like BSD) nor a project which regularly goes through major 
 > incompatible code changes (like DRI).  Nor do I think the XFree86 model is 

We do worry about overall stability and security issues.

 > ideal where all development goes right into HEAD; allowing branches for 
 > people to play in is a good way to provide for shared development of
 > new stuff, but letting most "regular" development happen on HEAD should 
 > reduce the amount of bookkeeping work needed by projects like CYGWIN.
 > 

One thing we have never talked about is code review.
I'd feel a little nervous if everybody is allowed
to work directly in the trunk adding unreviewed code.
If this will not produce security concnerns it may 
introduce inconsistency as people may not have the 
experience on how things are handled and what functions 
exist.
We may not always be able to catch invalid or problematic
workarounds, duplication of code etc immediately. I've seen
a lot of such code even being committed to XFree86 (despite
of the strictly limited commit access) and I have severly
suffered from this as it forced often forced me into long
and tedious debugging sessions.
Even unclean but otherwise correctly working code will fire
back at us at some time.

Egbert.