Team packages maintained in bzr, one branch for the team or one for each debian directory?

[Loïc Minier]

On Sat, Jul 28, 2007, Sebastien Bacher wrote:
> We are looking at maintaining the ubuntu-desktop packages in bzr. The
> idea is to store the debian directories there and to use
> bzr-buildpackage and some other tools making the work easier.

 Huzzah!  \o/

> * One branch by package:

 I think that's the sane way of doing things.  I would take the same
 choice with e.g. git, and I think this is natural.  It maps very well
 with upstream having one SVN repo per package too, and I think we have
 been wrong in using complex layouts in the SVN repositories in alioth.

> - you need to checkout or update ~100 different branches when you work
> on all the packages

 Yeah; I wrote my own script to do this, but then realized there's
 already a multi-pull command in bzrtools.  But I agree with other
 posters that this needs to be fixed, it shouldn't be a blocker.

 The current implementation is very simple (for branch in iter():
 pull()), but there are at least two solutions to help with speed:
 1) (already proposed) rewrite this to reuse a transport when possible
 2) add a connection cache / pool to bzr which would permit reusing a
    transport during a small period of time

> - you need to branch for every package when gutsy+1 opens

 I'm not sure this is strictly required: I could imagine using one
 "ubuntu" branch (and one "debian" branch obviously :) as the main
 "Ubuntu trunk" which would basically map to upstream's trunk, or
 whatever you're currently tracking for $next_release.
   Perhaps it's not strictly needed to have branches for each release
 and the backports can be done manually, directly from the archive as
 right now?  Or perhaps the branches should be created ad hoc, for
 example a new branch "ubuntu-gutsy-backports" would be initiated only
 when a backport is needed?

> Daniel has written a "get-branches" tool to make easy to get or update
> all the branches from a team, it has to connect and do checkout for
> every package though which is quite slow and quite verbose.

 Cool, I did a similar one for hildon; I hope we can share code.

-- 
Loïc Minier