Using feature branches to manage packaging with bzr (was: Future of REVU and Debian Mentors)

[Michael Olson]

Reinhard Tartler <siretart at ubuntu.com>
writes:

> "Emmet Hikory" <emmet.hikory at gmail.com>
> writes:
>
>>     The reason I prefer a patch system is that it organises the
>> patches by purpose, rather than historically.  With a VCS, it is very
>> difficult to extract the specific set of changes required to
>> implement a specific feature, especially when those changes may span
>> several files, and have been updated several times during this
>> history of the package to match upstream changes (often in
>> combination with other updates).  Purpose-oriented patches are easier
>> to review for adoption upstream, and easier to understand as an
>> example to implement a similar feature in another package.
>
> This is adressed by the concept called 'feature branches', a concept
> that Manoj Srivastava uses for his packages. A feature branch only
> contains the changes that you would normally put in a dpatch. It can
> be easily extracted and exported to a patch file. Furthermore, you can
> track and merge changes with other developers.
>
> Together with the bzr-rebase plugin, I think the implementation of
> feature branches with debian packages becomes more and more feasible
> in bazaar.

I'm intrigued by this idea.  Unless I'm mistaken, the main issues with
using bzr for this is that bzr needs a separate working tree for each
feature branch.  This causes the following problems.

 1. If working with a Launchpad-hosted repository, each branch has to be
    registered with Launchpad before work can be done on it.

 2. There are often a lot of individual patches in debian/patches --
    making a feature branch for each patch seems slightly wasteful of
    disk space.  This is not a huge concern since debian/ directories
    are almost always small, but it would feel wasteful nonetheless,
    compared to having just one working directory, like git offers.

 3. How would the working directories of these branches be organized on
    the disk?  Since bzr seems to support nested archives, perhaps best
    would be to stick each of them in
    debian/patches/<name-of-feature-branch>.

 4. A new contributor to the project would have to check out not just
    the branch that has the debian/ directory, but also every single
    feature branch, which could be a hassle.

This is still an improvement on using a simple upstream branch and
debian branch with a unified and linear change history, but isn't really
feasible unless bzr can keep track of multiple branches in one working
directory and easily switch between them.  (I'm assuming that once bzr
can handle this, Launchpad will be able to handle this also, and perhaps
display useful information on which feature branches a project contains,
with only one "bzr clone" needed in order to get everything.)

-- 
       Michael Olson -- FSF Associate Member #652     |
 http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net  |  /` |\ | | |
            Sysadmin -- Hobbies: Lisp, GP2X, HCoop    | |_] | \| |_|
Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20070806/53baf245/attachment.pgp