Merging patches

[martin f krafft]

also sprach Jeremy Kerr <jk at ozlabs.org> [2010.02.10.1713 +1300]:
> Nothing. Patchwork will *always* create a new patch (rather than
> appending to an existing one) when it finds a patch in a mail.
> Otherwise, the maintainer will miss patches that are hidden within
> other patches.

This makes sense, of course. ;)

> > Is it possible to merge patches instead? I don't think bundles are
> > what I want, I just want to merge two patches that do the same
> > thing, not two related patches.
> 
> I'd like to add 'relationships' between patches, but this is not
> a trivial thing to do. A follow-up patch may be:
> 
>  * A replacement for the original patch
>  * An addition to the original patch
>  * In the same series as the original patch
>  * Completely unrelated to the original patch
> 
> So detecting this relation automatically is kinda difficult, based
> only on the threading info.

Indeed. I've had three ideas about this:

1. patch mails include some sort of patchwork control information
   that is parsed and used to determine the above, e.g.
   patchwork:supersede or patchwork:append. This requires users to
   know and act ahead of time, which makes it not a reliable
   solution. Thus:

2. have a control@ e-mail address in the same spirit as the Debian
   bug tracking system: http://www.debian.org/Bugs/server-control,
   allowing anyone to manipulate patches by mail.

3. Let people bounce patches to patchwork+rejected@, and thus
   patchwork uses the information in the $EXTENSION variable (the
   MTA has to be configured to pass this on) to automatically mark
   patches that way.

Thoughts?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"imagine if every thursday your shoes exploded if you
 tied them the usual way. this happens to us all the time
 with computers, and nobody thinks of complaining."
                                                        -- jeff raskin
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: <http://lists.ozlabs.org/pipermail/patchwork/attachments/20100211/11c2754a/attachment-0001.pgp>