Patch mgmt workflow proposal

[Ben Finney]

martin f krafft <madduck at debian.org> writes:

> Here's a summary of what Thomas told me about this:

This matches how I happily work on Debian packaging with Bazaar, except
for some minor details.

>   1. you develop your features on branches, but you do not push the
>      branch heads;

Right. The feature branches stay only with the people who are
interested; usually the people actually working on each one.

>   2. the feature branches get merged into an integration/build
>      branch, which is pushed. This way, all contributors get the
>      commits;

Yes. The central repository where team members coordinate their
revisions only has branches of interest to many or all.

>   3. as part of the build process, the feature branches are exported
>      to a debian/patches series, and each patch file includes
>      additional information, such as dependency data, and also the
>      SHA-1 of the feature branch head at the time when the patch
>      was made;

Generalise “SHA-1 of the feature branch head” to “identifier of the
feature branch revision”, and that matches my workflow too.

>   4. at a later stage, when someone wants to edit a patch, they can
>      create a branch off the SHA-1, merge the branch into the build
>      branch and provide the updated patch (with updated SHA-1), or
>      just provide an updated patch file and let the maintainer
>      update the branch with an interdiff.

With Bazaar, the branches have their own distinct existence, and can be
re-created at will by anyone who has the identifier. Is that the same
for Git?

> I see an advantage in this approach because it focuses on
> debian/patches/* rather than using a potentially-confusing set of
> branch heads.
>
> However, it employs a possibly brittle way to keep track of branch
> heads (SHA-1's in text files).

I don't see that brittleness; maybe that's because of the way Bazaar
keeps track of merges explicitly.

> The thing I do not like about it is that the build branch has all
> features merged (hence applied to the worktree), *in addition* to
> tracking the generated patch files in debian/patches/* in the
> repository.

That's a big plus, in my view; but then again Bazaar has the sensible
default of hiding merged revision data until it's requested by the user.

-- 
 \      “The trouble with eating Italian food is that five or six days |
  `\                        later you're hungry again.” —George Miller |
_o__)                                                                  |
Ben Finney
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20110802/5bac3735/attachment.pgp>