bzr loves Ubuntu @ UDS

[Michael Hudson]

Vincent Ladeuil wrote:
> 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).

Yikes.  We'll need to do some work to be ready for that.

[...]

> 4) Daily builds
> 
> mini-grumpy/package of the day seems to be called daily builds here so
> I'll stick with that from now on.
> 
> It has been clearly said that the idea here is to:
> 
> - get upstream tip,
> - add ubuntu packaging without *any* patch
> - make it work

This sounds tricky, as it presupposes being able to get the ubuntu
packaging without patches, something I don't think we're doing yet?

My imagination for the first cut at daily builds was:

 - take the trunk branch, say lp:bzr
 - take the debian directory from lp:ubuntu/bzr and stick that in the tree

But this will still have the patches.

If I've missed something, I'd love to know what :-)

> This clearly means the packaging information should be kept separate
> from the patches themselves as best as possible (there are known cases
> where that's not possible, hence the 'make it work' vague definition :)
> 
> But in turn, that mean we may want to keep the packaging in a proper
> thread and have a final thread where we merge both the patches and the
> packaging thread.
> 
> That doesn't mean that building stable branches (the one released in
> Ubuntu) is not interesting, but that will come later.
> 
> Keeping all these threads properly used and ensure the commits always
> happen in the right one is certainly the most important challenge
> here. We don't strictly need that, at the cost of lots of merges that
> may be uninteresting to the user. So we can start without that but then
> we'll probably need ways to filter out the history in various ways when
> presenting various parts of the history to the user (upstream history,
> packaging history, both, etc)

[...]

Cheers,
mwh