I would have liked to have been told about this when I raised the
branching problem on 15 March. There was no opposition to my plan when I
described it in detail back then, or when I actually implemented it on 3
April (with Didier's approvals both times).
On 3 April I made lp:compiz/0.9.9 identical, absolutely identical, to
lp:compiz/raring. So you had no reason to continue using
lp:compiz/raring other than personal preference for naming. The numbered
approach was well established in Compiz and Unity last year.
If you do want to maintain "stable" in lp:compiz/raring, then please
remove the 0.9.9 series and branch, to avoid confusion. Having two
"stable" branches for 0.9.9.* is asking for confusion.
I guess new problems with stability are a natural consequence of Compiz
being unstaffed now. It won't be maintained quite as effectively as it
used to be. But I highly recommend you aim to use 0.9.10 in R+1. If
there are stability problems then they can be fixed soon enough. The
diff to the stable branch is not that large, so surely bisection of any
bugs should be easy (?).
On 19/04/13 11:25, Stephen M. Webb wrote:
On 04/18/2013 09:13 PM, Sam Spilsbury wrote:
For S, will we be able to set a date in stone when we will be able to
branch every PS project? That will mean that every project can
organize their release cycle around that.
Starting with R, the release cycle was continuous. Not 6 months, not monthly,
continuous. You propose a merge, it gets
reviewed, it goes through a battery of tests, then it goes into Ubuntu, and
people install it on their system. Releases
happen almost every day. Branching early for release just means having two
identical development heads. The branch time
needs to be as short as possible, preferably at or around final freeze,
otherwise there is a tragic waste of resources
as every fix gets committed twice.
For the continuous release cycle to work, we need stability. The 0.9.10 branch
of Compiz has been very dynamic. The
reason why we branched earlier was because of the ongoing volatility of Compiz
development. The 0.9.9 release is stable
enough that we can use it every day, and until the decision is made to move to
0.9.10, we will continue to use it
unchanged in the daily Ubuntu release. This is a topic for discussion between
stakeholders at a vUDS, not something I
am prepared to jump in to overnight at the start of a new cycle without
thorough testing of the entire integrated Unity
stack in a production environment. When the appropriate decision has been
made, we can switch Ubuntu from 0.9.9 to 0.9.10.
We can not continue to use the 0.9.9 branch for Raring if we're using it for
R+1. Traditionally, packaging was done by
doing an "upstream release" and creating a source deb from the resulting
tarball, which was then dput to the archives.
The source deb was usually created using a VCS archive elsewhere, maybe using
bzr on Launchpad. Now, because we have
the miracle of automerges and PPA autolanding, we just use a regular upstream
project branch. It's the same thing, but
more visible, and with a distro-specific series to target bugs to because with
autolanding upstream has effectively
become Ubuntu. That's why I created a new lp:compiz/raring branch. It's not
the same as the previous lp:compiz/raring
branch, which is gone. It is effectively a packaging branch.
I use the same series and branch nomenclature for (almost) all the projects
involved in desktop Unity, because conveying
clarity of purpose is important to me in a free and open project, and to be
more effective than the hodgepodge used
previously across the various projects in the stack. The only exception was Unity
itself, because "Unity 7" seems to
have considerable traction in the media.
So, we're going to have 3 project branches for Compiz for a while: (1) the 0.9.10 (aka
"trunk") branch for most ongoing
development work, (2) the 0.9.9 stable branch for R+1 and the regular
continuous Ubuntu release until such a time as the
decision is made to switch to the newer version, and (3) a raring branch for
SRUing critical bugfixes into Ubuntu 13.04
similar to the packaging branches that have always existed.
--
Mailing list: https://launchpad.net/~unity-dev
Post to : [email protected]
Unsubscribe : https://launchpad.net/~unity-dev
More help : https://help.launchpad.net/ListHelp
