unity-dev team mailing list archive

[Sam Spilsbury <smspillaz@xxxxxxxxx>]

On Thu, Apr 18, 2013 at 8:25 PM, Stephen M. Webb
<stephen.webb@xxxxxxxxxxxxx> 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.

If the compiz development process isn't working well with the daily
release process, then I think we need to figure out how to make the
appropriate change upstream, rather than introducing process
downstream.

I'd like to gather a list of reasons why there is a perception that
upstream lp:compiz is "volatile" at the moment, and then work together
on fixing that.

If it helps, I'm actually just about to start setting up an acceptance
testing framework for some of the plugins with the highest bug surface
area, namely move, resize, grid and decor. That will ensure that at
least for 0.9.10, we can have a greater amount of automated testing so
that we can encourage people to submit more tests.

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

If we want to continue with this model at the moment, I think that's
fine. The only thing I'd ask is that we need to have some kind of
strategy for moving to two branches, just 0.9.9 (R) and 0.9.10 (S).
Creates more simplicity for everyone.

Best Regards,

Sam

>
> --
> Stephen M. Webb  <stephen.webb@xxxxxxxxxxxxx>
>
> --
> Mailing list: https://launchpad.net/~unity-dev
> Post to     : unity-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~unity-dev
> More help   : https://help.launchpad.net/ListHelp



--
Sam Spilsbury