bzr loves Ubuntu @ UDS
Jelmer Vernooij
jelmer at samba.org
Thu Nov 19 04:19:55 GMT 2009
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
More information about the ubuntu-distributed-devel
mailing list