bzr loves Ubuntu @ UDS

[Michael Hudson]

Jelmer Vernooij wrote:
> On Thu, 2009-11-19 at 11:12 +1100, Robert Collins wrote: 
>> On Wed, 2009-11-18 at 17:36 -0600, Jelmer Vernooij wrote:
>>> Hi Vincent,
>>>
>>> Thanks for writing this up.
>>>
>>> On Wed, 2009-11-18 at 16:49 -0600, 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 ?
>>>>
>>> +1, it seems a lot easier to get the history right in the first place
>>> than to fix it up later on.
> 
>> The reasoning we have is:
>>  - we know that ~ 25% of imports fail at the moment (maybe 50% on first
>> attempt, and then we whittle it down).
>>  - We don't want to block users on imports. Better to have a productive
>> user now with a history rewrite down the track (because we know how to
>> do history rewrites), than an unproductive user until their particular
>> import works.
>>
>> 'imports' is a piece of string problem: its never ending and continually
>> lengthening. Thats why its #2: we can deliver daily builds where we have
>> the imports, and make that work well, and then every import we add
>> increases the value of the daily builds. If we do it the other way
>> around, no-one gets daily builds until 'all the imports are working'.
> I'm not suggesting getting *all* of the imports working before doing
> anything else. But getting the import for a particular project for which
> you're going to do daily builds working properly before doing something
> else with it seems like a better idea than fixing the branch up later.
> 
> I don't think the failure rates are as bad as 25%-50%.

What you think is irrelevant <wink>: we have data, and 28% of git
imports in LP are currently marked "failing".  Not really sure what the
majority cause is, I don't think it's submodules.  Being able to find
out what the cause is would certainly be a valuable project.

> For bzr-git the
> only real issue I'm aware of at this point are submodules (this is e.g.
> problematic for kvm/qemu); 

Memory usage for large git imports is a real issue.  Maybe we need to
commission a big ass machine for initial imports and use that, but it
hasn't happened yet.

> for bzr-svn the two main issues seem to be
> libsvn http bugs and odd history involving bzr-svn roundtripping. I
> don't know what the failure rates are like for cscvs?

I'm pretty hopeful that bringing in bzr-svn will improve our subversion
success rate considerably.

Cheers,
mwh