bzr loves Ubuntu @ UDS

[Jelmer Vernooij]

On Thu, 2009-11-19 at 14:55 +1300, Michael Hudson wrote: 
> 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.
Well, there aren't any other open bug reports in bzr-git's bugtracker,
I'd love to hear about other problems. :-) 

> > 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.
Are there any imports that fail because of this, or do they just get slow?

Cheers,

Jelmer