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

[Martin Pitt]

Hi,

Loïc Minier [2007-07-29  1:52 +0200]:
> > - 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?

I agree. Very few of the packages actually get updated in stables, so
keeping a trunk and then branching off that when the need actually
arises makes much more sense.

Note that this requires a certain discipline with keeping ties
between bzr revisions and uploaded versions, though. Nowadays you
should probably just tag the current revision with the package version
when you do an upload.

Personally I still use the old non-tag approach which works very well:
Development happens while keeping the changelog release target as
"UNRELEASED", and an upload consists of changing that to "gutsy" and
committing that change with -m 'release as 1.2.3-4ubuntu5 to gutsy'.
Then it is easy to determine the revision number from bzr log.

Oh, and just for counting: one branch per package makes much more
sense, especially if we ever get to maintaining the full source in
revision control.

Maybe you guys should start with one or two packages, see how it goes,
improve the tools, and then make the call (1) whether to keep bzr
branches at all (depending on whether it eases your work) and (2) how
to improve the process.

Martin

-- 
Martin Pitt        http://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org