Patch mgmt workflow proposal

[martin f krafft]

also sprach Thomas Koch <thomas at koch.ro> [2011.07.30.1229 +0200]:
> Martin F. Krafft (madduck) was so kind to remind me posting this here. We're 
> right now at debconf discussing different patch mgmt workflows. Thanks to 
> contributions from Joachim Breitner and Guido Günther I've written down an 
> appealing (IMHO) patch mgmt workflow:
> 
> http://wiki.debian.org/ThomasKoch/GitPackagingWorkflow

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

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

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

  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;

  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.

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).

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.

Finally, I would like to highlight that this is very much like the
TopGit workflow used in mdadm, with the exception that features are
not merged into the build branch, but instead the branch heads are
kept around. It is my hope that I can simplify TopGit a bit to make
this an equally viable approach, which would be more natural and
closer to normal Git usage, at least to me.

Cheers,

-- 
 .''`.   martin f. krafft <madduck at d.o>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
may the bluebird of happiness twiddle your bits.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1124 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: <http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20110801/badf4e6a/attachment.pgp>