Re: Proposed release process/plans - don't branch too soon

[Havoc Pennington <hp redhat com>]

Michael Meeks <michael ximian com> writes:
> > Luis pointed out that there is some controversy over when this "2.0
> > branch" begins, what I'd written down is that it begins with 2.0.0,
> > and what other people thought is that it begins with 2.0.1.
> 
> 	Problem is we already branched for 2.0.0 :-)
>

When I say "2.0 branch" I mean the one that sticks around for a long
time, i.e. I believe that is HEAD currently, not the 2.0.0 branch.
The 2.0.0 branch isn't really hurting anything. 

> 	I think that momentum can come back; but as it is a large number of
> engineers have to work on stable to fix bugs - this is the brunt of our
> effort at the moment - and having to commit to 2 or 3 branches instead
> of simply HEAD will make things extremely painful.

I believe the right thing is to just avoid the per-micro-point-release
branch after 2.0.0 is out. That is, 2.0.2 would just be a tag on the
long-term 2.0 branch, not another subbranch.

The changes to the 2.0 branch should be _small_ _small_ _small_ - if
we are putting large patches on there, well, we are screwing up.
After 2.0.1 we want to drop this branch and move on except for
_critical_ bugfixes. Because that means we can actually get 2.2 out
with its bugfixes and enhancements within the 6 months, and it means
that 2.0.x will actually be stable - where stable means
predictable/unchanging in addition to relatively unbuggy.

Anyhow, once we release 2.0, anything that would break the freeze for
the 2.0.1 or 2.0.2 micro releases should not be going on the stable
branch _ever_ anyway; said changes should only be committed to
2.1.x. So I don't think we need to branch a 2.0.2 as a subbranch from
the long-term 2.0 branch.

Because vendors are shipping stuff in the middle of the 2.2 cycle, I
know there will be pressure to churn up 2.0.x stable with vendor
fixes; but this is a mistake, IMO the bulk of vendor fixes need to be
going in to 2.1.x, NOT the stable branch, especially post-2.0.1. In
some ways this makes it easier for vendors anyway, since they can
selectively backport fixes only in areas where they really care about
them, and feel confident when pulling down new 2.0.x tarballs that
they aren't getting something risky.

Havoc

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers