[rfc] focus on Ubuntu updates rather than PPA packaging

[Martin Pool]

2010/1/27 Andrew Cowie <andrew at operationaldynamics.com>:
> On Wed, 2010-01-27 at 18:08 +0100, Martin Pool wrote:
>> Our results so far show that beta releases are pretty stable and
>> suitable for everyday use
>
> That may be. Gentoo, for instance, is shipping the current beta.
>
> But,
>
>> ; they are only unstable in the sense that
>> there are a larger volume of changes from month to month, and that
>> they change APIs and may clash with plugins.
>
> In the 1-15-1.18 period we went through hell with bzr-svn & bzr-gtk
> packages not working with the current bzr package, etc.

I know.  So that was one major reason for going to the stable release
idea, which seems to have made plugins pretty good for people on that
branch.

> Whatever you decide to pursue, I'd like to encourage you to create an
> authoritative place to get "the current version Bazaar" both in tarball
> and Debian package form.
>
> The ~bzr PPA seems to have been admirably serving this purpose. It was
> "the place to get the latest release of Bazaar" and I'd reasonably
> expect it to bump from 2.0.x to 2.1.x when 2.1.x is finally released.
>
> Evolving, I'd like to see bzr-git added there.

So the answer I'm suggesting will be: you can get the current version
from Ubuntu or Debian.  This is simpler for the user.  The potential
drawbacks may be:

 * it is too slow to get updates into them
 * (and this is connected) there may be no one-size-fits-all-users, so
a single version shipped in a distro may be too conservative for some
people or too unstable for others

>> Therefore I think it's
>> reasonable for quite a fair number of advanced users to run betas as
>> long as they can tolerate amount of API-related breakage: we want them
>> to report it but they shouldn't be shocked that it happens.
>
> You think?
>
> I'm not so sure.
>
> People who are "advanced" enough to at least communicate back to #bzr or
> this list are *using* Bazaar; they really kinda want it to work. A bug
> here and there that is [likely to be] rapidly addressed is one thing.
> Plugin-failure-due-to-API-change breakage is just not something I would
> expect people to be that interested in. As I noted above, we've been
> there before, and it wasn't fun.

I realize nobody wants breakage, though part of the point of running
betas is to find bugs, including plugin-breakage bugs.  This helps the
developers get better test coverage, and it helps users in that the
bugs are (hopefully) fixed before the stable release.

During unstable series we're going to give ourselves the freedom to
make changes that will require plugin updates.  I don't see any easy
way away from that given the tools in Python.  (If people have
specific suggestions that's great but just saying "don't change APIs"
is not realistic.)

I think we can do some things to reduce plugin breakage during beta
series, though they are almost orthogonal to packaging, and they
include running plugins in Babune and not having paranoid version
checks in plugins.

> People will use that PPA if it works together, as a cluster. Otherwise,
> they'll have no choice but to revert back to whatever their [ok, in this
> case, Ubuntu] distro is shipping. In which case they'll be using
> whatever ecosystem is there - somewhat old version of bzr and doubtless
> hopelessly out of date versions of the supporting plugins.

I think falling back to the distro version is a reasonable step.  At
the moment you sometimes get something very old.  We should fix this
so that the distro includes the latest stable version, or at least the
latest bugfixes for the version they originally shipped.

> Maybe you can get better mileage out of the SRU process, but to date
> they've been unimpressive at publishing to your stable releases, and
> unless you can easily update all the supporting plugin packages at the
> same time, I don't think much will come of it.

I agree it has been too slow; I think we should improve that process
rather than routing around it.  As you have pointed out before, we do
have some Canonical levers (or hammers) we can use.

>> concentrate on helping with the teams doing packaging in Ubuntu and
>> Debian rather than packaging ourselves into PPAs
>>
> That doesn't seem unreasonable, I just don't think it'll get you
> anywhere given how unresponsive downstream has been.
>
> [I mean, shit, it shouldn't have to be your job to beg Canonical
> packagers to package the latest release of a Canonical product. They
> should be just doing it when you announce a release. And meanwhile, the
> GNOME constellation has an "exception". Can you not get one too?]
>
>> or if you want to test our nightlies,
>> do [PPA]"
>
> Only if the nightly PPA reliably results in a usable ecosystem.
> Otherwise it's RPM hell.

It will have bzr == 2.2.something, and a set of plugins that depend on
bzr 2.2.*.  You will not get paranoid dpkg conflicts.  You may
experience bugs when the plugin is actually out of date with the core,
but that really is a bug we need to fix, though possibly also one we
should have caught earlier through automatic testing.

I think the very next thing outside of that would be to do a beta ppa.
 It will have similar dependencies.  It may sometimes hit those bugs,
but presumably only during the actual moment where the most recent
plugin is out of date.

Another piece that would be good is to have the plugins in 2.2
compatible with bzr 2.1 and vice versa as much as possible, so you'd
have the option to roll one of them back to the last packaged version.

Anyhow, if we try this, meta-feedback about the approach will be
useful: not just "it broke today" but ".. but it's less than last
year", which seems to be true with stable branches.
-- 
Martin <http://launchpad.net/~mbp/>