bzr loves Ubuntu @ UDS

[Vincent Ladeuil]

Many discussions and sessions related to the daily builds and the source
packages have happened here already.

It's a bit hard to report about them without repeating a lot of things
that has been covered during our bzr sprint, so I'll try to focus on the
main differences (at least in my understanding, feel free to correct
me).

1) code imports

First of all, I'll appreciate some rehash of the arguments about why
code imports should be at priority #2 behind mini-grumpy.

There seem to be many problems around branches with different histories
between the upstream, debian and ubuntu branches. The sooner we get the
first ones via code imports the less problems of history rewriting we'll
have to deal with. Is there something wrong with that reasoning ?

It has been mentioned in one of the sessions that there are ~100
packages that are more important than the others but we still don't know
if we import them correctly.

Establishing which of these 100 are not imported today sounds like a
good first step.

Working from there and making the most important ones work first also
sound like a task for which we can allocate resources on demand and be
ready to handle the coming growing demand (5000 new imports are
expected shortly).

2) loom or not loom

I discussed using a loom to represent the packaging stuff on top of the
upstream code and it seems that most people agree that the following
threads will be used:

- packaging
- patch n
- patch n-1
.....
- patch 1
- upstream

Some code will be needed (probably in bzr-builddeb) to create the needed
debian/patches directory from the patch threads when entering the
packaging directory. 

The packaging thread MUST in any case stay above the patches to make it
easier to send patches upstream.

Several looms are possible:

a) Instead of 'packaging' we can have debian and ubuntu on top of it. In
   that case, some mechanism should also be defined to decide which patches
   should be taken into account in each packaging thread.

b) debian and ubuntu branches can be looms and the debian loom can be
   merged into the ubuntu one.

c) pipes can be used on top of looms for the packaging threads

d) looms can be enhanced to provide a way to have the patch threads on
   top of the upstream thread but independent from each other. The
   packaging thread can then merge whatever patches are needed. Care
   should be taken here to provide a very good UI to help the users.

3) package variety

While discussing with Steve Langasek, he showed me the samba package:
- upstream: git, not yet imported,
- debian: svn, not yet imported
- ubuntu: not yet under bzr

We may not want to start with that one ;-) Yet, it's a good example to
keep in mind about what kind of history we want to
handle/preserve/rewrite.

Feedback welcome from packagers about what is the minimal history needed
to be able to update Ubuntu packages cleanly.

By that I mean: we will import upstream as a first priority and that
will certainly remains the "main" history.