← Back to team overview

launchpad-dev team mailing list archive

Re: [RFC] Taking source package branches to the next release

 

On Fri, Aug 07, 2009 at 12:56:41PM +0100, Jonathan Lange wrote:

> James Westby & I just hashed out a brief specification for handling
> source package branches when releasing Ubuntu. That is, making sure
> that all of the branches available in karmic are immediately available
> in karmic+1 as soon as it is opened.

> The spec is here:  https://dev.launchpad.net/BranchingUbuntu

> And we have already made some tweaks to
> https://wiki.ubuntu.com/NewReleaseCycleProcess.

> I'd greatly appreciate your feedback, either here, or on the
> BranchingUbuntu wiki page.

Looks great!  A couple of questions:

  Process

  Prerequisites

    * New distroseries to be created
    * Import script turned off 

Are there provisions for also making sure branches for the release pocket
are no longer writable when we release, to ensure we don't get skew between
the archive (which is supposed to be immutable at that point) and the bzr
branches?

 Algorithm

 2. Swap the .bzr directories for the old branch and new branch using
    filesystem operations.
 3. Manually change the stacked-on URL of the newly-created branch to point
    to the full unique name of the new database branch. 

Is this expected to be cheaper/simpler/$other than moving the branches first
from old-distroseries to new-distroseries and creating the new branches
directly under the old distroseries paths with the stacking set?  (Perhaps
this is intended to reduce the window during which the old branches are
absent?  If so, I would argue that they're not of much use until the new
distroseries is opened anyway.)

Otherwise, looking forward to it :)

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@xxxxxxxxxx                                     vorlon@xxxxxxxxxx



References