bzr and Ubuntu: what it means for vcs-pkg (was: Re: Bazaar branches for all Ubuntu source packages available)

[James Westby]

On Sun, 2008-11-30 at 19:23 +0100, Stefano Zacchiroli wrote:
> On Fri, Nov 28, 2008 at 04:10:35PM +0000, James Westby wrote:
> > In my opinion it doesn't prejudice the aims of vcs-pkg at all.
> 
> Agreed. Rather, it accounts for an experiment at which we should look
> with interest.
> 
> In particular, logs are important, for example I'd be curious to know
> how much the typical access path to your sources (presumably "apt-get
> source", but maybe even the website, or whatever else) will change
> with this.

I'm not sure what you mean here, could you clarify?

> More generally, I've a handful of other questions on the
> infrastructure:
> 
> - is the source code of the infrastructure available? (sorry, I'm
>   writing off-line and I can't check by myself)

The logic is in bzr-builddeb. There are some scripts that run that in
a loop after checking what versions of a package haven't been imported
after grabbing that information to launchpad which are not in the 
branch.

  http://code.launchpad.net/bzr-builddeb

> - how tied is the infrastructure to bzr? would it make sense to have
>   different back-ends (well, front-ends for the final users) for the
>   various DVCS?

It's pretty tied to bzr currently, but the ideas don't require bzr.
You could implement different back-ends, but I don't have a desire to,
and I'm not sure it would be a good idea.

>   The question is of course modulo the usual problems of
>   synchronization between different VCS, but note that those problems
>   do not pop up for packages which are _not_ regularly maintained
>   using VCS, but are rather just injected regularly into bzr

Yeah, for things maintained in VCS we plan to suck the packaging 
directly in to bzr and use that, we've just focused on the general
case first.

There are some difficulties though. For instance we want full source
branches, and a lot of SVN packaging is mergeWithUpstream style, so
we will have to put it back together again while still making it useful
for collaboration. We also need to handle the probably hundreds of 
tagging schemes out there to be able to tag the historic releases
appropriately.

(We tag every release with a specific naming scheme so that the tools
can rely on that being there)

> - how specific to Ubuntu is the infrastructure? Would it be possible /
>   easy to set up the very same service for Debian or for any other
>   Debian derivative?

The UDS session I linked to is about this. This cycle I am going to be
working on bringing up an import of Debian to bzr with shared revision
history and all the merges represented as multi-parent commits. The
code is actually there now (it attempts to detect merges from e.g.
"intrepid-security" to "intrepid-updates"), but we felt just bringing
up Ubuntu was enough work for the first step.

These branches will be hosted on launchpad as well, under the "/debian/"
namespace. They will be read-only, but will be there for any Debian
developer to use if they like. I haven't discussed this much with the
launchpad team yet, but it may be possible for a package maintainer to
get write access to the branch if they liked.

One thing that is going to hamper us is that we don't have historic 
packages for Debian. I'm interested to know if the official version
of "snapshot.debian.net" will have all the old packages, which would
be a massive help for us. If not then we may end up with the bzr
branches suggesting that Debian was branched off Ubuntu :-)

If any interested Debian people can make it to UDS in SF next week then
your input in to the above discussion would be appreciated. We have a 
few DDs invited, and plenty of DDs within Ubuntu anyway, so that 
perspective will be represented, but having any specifically interested
in this topic would be great.

Thanks,

James