bzr loves Ubuntu @ UDS

[John Arbash Meinel]

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.

I would assume the ones coming from hg are probably at the top of this
list. Stuff like Mozilla and various Sun apps?

It also isn't something that we would have a trivial fix for.


...

> 6) Use cases not mentioned so far
> 
> An interesting variation of the daily builds has been discussed in the
> 'qa-lucid-fixing-bugs-with-patches', while this is not directly related
> to the packaging stuff, I think it's worth keeping in mind.
> 
> Not all patches may lead to a build, but certainly some will and helping
> the people involved to test their patch and send it upstream is
> certainly not that far from our current objectives.
> 
> changelog merging is an issue often mentioned, it certainly shares some
> aspects with our NEWS conflicts and a specific merge algorithm could
> certainly be found here (bzr core should provide the necessary hooks for
> that at least).
> 

changelog cherrypicking is also something that has come up in the past.
Since you are only taking out some of the changes. (It is what had me
rewrite some of the Merge3 code to detect it was doing a cherrypick and
explicitly not try to merge some of the things that looked like it was
in the non-requested revisions.)

I don't remember all the specifics, but cherrypicking is probably
somewhat common in a patch-hybrid system like this, and it could get
messy fast.

John
=:->