bzr 1.3 in ppa; plugins still need updates

[Martin Pool]

On Mon, Mar 31, 2008 at 4:56 AM, James Westby <jw+debian at jameswestby.net> wrote:
> On Sun, 2008-03-30 at 18:23 +0100, Russel Winder wrote:
>  > Jelmer,
>  >
>  > On Sun, 2008-03-30 at 15:44 +0200, Jelmer Vernooij wrote:
>  >
>  > > The link is not as strict as that. As far as I know bzrtools should work
>  > > fine with older and newer versions of bzr. bzr-svn usually works fine
>  > > with one or two versions of bzr.
>  >
>  > Given the hassles, might it be better to just stick to a version lock
>  > step so as to avoid them?
>  >
>  > > The Debian dependencies on bzrtools and bzr-svn are very strict (tied
>  > > to a particular bzr release) since bzrtools and bzr are always released
>  > > in the same week anyway and to avoid potential issues with bzr breaking
>  > > the API for bzr-svn.
>  >
>  > If http://ppa.launchpad.net/bzr/ubuntu is to be the official location of
>  > deb files for the current released Bazaar, it really needs to be that
>  > there is consistency and completness, and installability -- which is
>  > currently not the case.  If PPA isn't up to the job that Bazaar bleeding
>  > edge users need in order to be able to install a consistent version of
>  > Bazaar then either it needs to be abandoned in favour of a repository
>  > that can do the job, or it needs changing so that it can do the job.

I agree that the Bazaar archive needs to be up to date and reliable,
and thank you for pointing out that it is not good enough yet.

PPAs recently gained a feature allowing us to copy packages from one
PPA to another.  One option would be to make use of this to get them
all built in one archive, then copy them across when everything is
working.  But this adds another step, and if we just get everything
uploaded at the right time it should not be necessary.

We could at least use that to bring across Qbzr packages.

>  Could we try and come up with a strategy from this thread to make
>  sure that users get the best experience?

Yes, we can.  At least it got more replies than my one :)

One other thing we should do: I'll send a patch to the developer guide
describing how we do PPA packaging.  That should make it easier to do
it reproducibly, easier for other people to pitch in, and perhaps find
inefficiencies in how I have been doing it to date.

>  Having the plugins have tight dependencies on the bzr version and
>  then not updating them in lockstep is irritating for users, may
>  stop people from helping to test recent versions, and probably
>  drives some people away if our installation instructions don't
>  work for them.
>
>  Martin, you said the packaging branches were now on launchpad,
>  is that the case? I can only find the bzr ones. Having them
>  there is an important step, as then it does allow anyone to
>  upload to the PPA and push their work back.

Actually I think I only made branches for bzr, and did just an uupdate
for bzrtools and bzrgtk.  I will put up branches there soon.

I have to confess I am not yet using bzr-buildpackage for them, as I
wanted to get them going with the minimum number of moving parts and
following the main PPA instructions closely.  So if you can suggest
what we should be doing better I would be very happy to adjust.

>  I can work on something that automates the easy bit of grabbing
>  the new tarball and updating debian/changelog, building the source
>  package and uploading each to the PPA, then it would just be a case
>  of fixing any build failures.

That would be particularly nice as we have to make 5 uploads for each
supported distro version.

Which reminds me that Edgy will be out of support in April, at which
time it is probably reasonable for us to stop building packages for
it.  (There will be no more security updates so it is really time
people upgraded.)

You'll also need to adjust the dependencies obviously.  It should not
be rocket science, I've just wanted to make sure I had the right
procedure manually before automating it.

If we have this then we could also use it to make nightly packages,
which some people have expressed interest in.  (I wouldn't want to
recommend them too strongly because we do sometimes break
compatibility between bzr.dev and the previous release and then
restore it before releasing, as with #207558, but for users who
understand this it they could help us find such bugs...)

>  Alternatively there are many people in #bzr with the skills to do
>  this, so when it is time to upload perhaps we could share the work
>  out and do it that way.

I think what I should do is, after each source release, either state
that I'll do the packaging myself or find some specific other person
who will take it over.

>  Martin, as you are currently responsible for the PPA, what would
>  be your desired way of dealing with this? If you tell us that then
>  we can make it happen.

-- 
Martin <http://launchpad.net/~mbp/>