[Xorg] X.org CVS branches need to change

[Keith Packard]

Around 10 o'clock on Mar 16, Egbert Eich wrote:

> Harold wrote:
>
> > I don't see the point in having a separate CYGWIN branch were we work on 
> > things that, you guessed it, only affect our platform.
>
> However the theory behind all this is that ongoing development takes
> mostly place in branches while minor fixes go directly into the trunk.

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.

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.

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

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

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

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.

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.

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

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20040316/554ec2fe/attachment.pgp>