Build service thoughts

[Martin Pool]

On 14 September 2011 00:42, Jonathan Riddell <jriddell at ubuntu.com> wrote:
>
> I packaged bzr for openSUSE recently and it was suggested I send some
> notes on how their build service compares to Launchpad.

Thanks for writing that up.  jml and I (at least) have looked at it
before but there's nothing like really using a tool to get an idea of
it.

> One difference that surprised me is packages are built instantly as
> soon as you commit.  This can probably be seen as quite a waste of
> build daemon time since it will be trying to make packages even if
> what you are working on isn't complete but it does remove a step from
> the user (in our case quite a hassle filled step since it requires
> using different tools to upload to the archive until build from branch
> appears).

Right, so part of that could be covered by BFBIA[1] removing the other
step.  I guess if it's really 'instant' then that also implies they
have more hardware headroom than Launchpad does, where there is
typically(?) quite a queue before a package is built.

> Build numbers automatically increment for each build which saves the
> minor hassle of having to do so yourself in the changelog.

That could be nice.  Perhaps we can handle that - perhaps just as
simply as making bzr commit in the branch suggest or generate a
changelog entry, or something.

> One source package is built for many distros and distro versions.
> This would be nice to have in PPAs, again removing a minor hassle from
> packagers of having to build and upload source packages multiple
> times.

Right, this is somewhat harder to individually script around, and I
think one of the bigger annoyances of PPAs today.  From the
implementation point of view you do need different version numbers for
each rebuild, but for the user it seems unreasonable.

We could do either of a couple of kludges:

 * some kind of easy flow around copying the binary between
distroseries, for cases where it's appropriate
 * a purely-automated tool to copy the package, add a changelog entry,
reupload - like a subset of autoppa, but without needing any
configuration aside from the choice of destination series.

I kind of like the latter: it would cope ok in the fairly common
(cite?) case of one source package building adequately well across all
active series.

> Packages are stored with packaging only and source in a tar file.
> This simplifies the problem compared to our UDD process of having full
> source branches in revision control.  Given the hassle full source
> branches seem to make for UDD (still > 500 import failures, quilt on
> top to bzr double revision control, notable new workflows for
> packagers, definitive source RCS is upstream and ours don't generally
> match) doing packaging only branches would seem to me to have been an
> easy win but too late to change now.

right.

> They have OSC, a command line tool for checkout and commit (similar to
> subversion in its revision control functions so much more limited than
> bzr there).  It also allows for easy searching of packages, checkouts
> include personal archives, and it submits merge requests which could
> be done as bzr plugins with support from Launchpad.

I would love to have a single commandline tool, integrated with bzr,
that reaches everything in Launchpad.  Perhaps lptools and/or lbox
will be that thing.

> They have external users, notably the Linux Foundation which means
> MeeGo is closely aligned to SUSE.  Maybe if Launchpad had been easier
> for external users to set up MeeGo would be aligned to Ubuntu?

I suspect (with no special knowledge) there are business
considerations that were more important than anything about the web
site, but making the tools really good can only help in encouraging
people to work with Ubuntu.

m