launchpad-dev team mailing list archive

[Tim Penhey <tim@xxxxxxxxxx>]

On Fri, 25 Sep 2009 14:53:59 Michael Hudson wrote:
> Jonathan Lange wrote:
> > On Thu, Sep 24, 2009 at 10:02 AM, Martin Pool <mbp@xxxxxxxxxxxxx> wrote:
> >> (Launchpad bounced my mail during the upgrade today)
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: Martin Pool <mbp@xxxxxxxxxxxxx>
> >> Date: 2009/9/24
> >> Subject: which version of bzr for launchpad?
> >> To: Launchpad Community Development Team
> >> <launchpad-dev@xxxxxxxxxxxxxxxxxxx>, Robert Collins
> >> <robertc@xxxxxxxxxxxxxxxxx>, John Arbash Meinel
> >> <john@xxxxxxxxxxxxxxxxx>, Ian Clatworthy
> >> <ian.clatworthy@xxxxxxxxxxxxx>, Vincent Ladeuil
> >> <v.ladeuil+lp@xxxxxxx>, Andrew Bennetts
> >> <andrew.bennetts@xxxxxxxxxxxxx>
> >>
> >>
> >> I had a talk to jml and thumper about this recently, and thought I
> >> would send a note here for the larger audience.
> >>
> >> Bazaar now maintains two branches, a stable/bugfix-only 2.0 branch,
> >> and an ongoing development branch 2.1dev.  (See
> >> <http://doc.bazaar-vcs.org/developers/cycle.html>).  As much as we
> >> can, we will make no changes to 2.0 that will break api compatibility,
> >> or any other kind.  They will be able to interoperate on both the
> >> network and formats.   The development branch may introduce new data
> >> formats, though we don't immediately anticipate doing this.  It likely
> >> will add new smartserver verbs, but it will have a fallback for older
> >> servers.  2.1 will still be tested and get the same degree of care we
> >> always have, but we'll be a bit more free to remove deprecated or
> >> non-user-affecting compatibility code.  So the only difference is the
> >> rate of change, not the degree of quality.
> >>
> >> The question then arises which version Launchpad should run for
> >> codehosting, and the answer is that it will run the development
> >> branch, 2.1b1 etc.  People using old clients should be fine, and
> >> people using new features or formats introduced in the development
> >> branch will be able to use them against Launchpad.  As we change APIs,
> >> Launchpad may need to update their own code, but they do this anyhow
> >> as part of their monthly integrations and it is not onerous.
> >
> > The subject of your email is phrased as a question, but the content is
> > an answer, and I think it's a good one.
> >
> >> Launchpad will at some point in the future add an edge codehost, which
> >> will run Launchpad's own tip, then be merged to the lpnet (ie stable)
> >> servers in monthly releases.  edge will run only slightly ahead with
> >> the bzr version, for example being on 2.1b2 when lpnet is on 2.1b1.
> >> This gives some opportunity for testing.
> >
> > FWIW, the edge codehosting service is waiting on our IS team to do
> > some network configuration.
> >
> >> The biggest risk seems to be that a change in 2.1.x may introduce
> >> bugs, either to do with operation with old clients or otherwise.  The
> >> best way to address this is (aside from general quality development)
> >> to test each release as it's integrated on the staging and edge
> >> codehost.  At least this way we will find any such issues earlier in
> >> bzr's cycle rather than at the 2.1rc1 point.
> >>
> >> It may be interesting in the future to allow the client to specify the
> >> remote bzr commandname as eg 'bzr-2.0' and then we could have several
> >> available servers on the Launchpad side; this would require including
> >> multiple bzr trees in the deployment.
> >
> > This would indeed be interesting. It would require a lot of work.
> 
> A wrinkle might come with plugin compatiblity.  We currently use bzr-git
> and soon will use bzr-svn and hopefully bzr-hg.  /Perhaps/ we should
> look at using the stable bzr for code imports -- I don't think this
> would actually be particularly hard, technically speaking (you'd just
> need to specify a different buildout.cfg for the launchpad trees on the
> import slaves, and make sure that the rest of launchpad at least imports
> with the stable branch of bzr).
> 
> Cheers,
> mwh

Well thought.  I think we may well want to do this.

Tim