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 -- ubuntu-desktop mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
