Experimental Patchwork setup

[Jeremy Kerr]

Hi Ian,

> I can see already that to be useful for gcc today it will need some
> curating.  E.g., http://patchwork.ozlabs.org/patch/54974/ is both 1)
> committed; 2) on a branch.  This one
> http://patchwork.ozlabs.org/patch/54958/ is committed to trunk.

There are a number of ways to keep the patch states up-to-date:

1) You can get the maintainers/committers to manually update the states. 
Simplest solution, but will add work to the folks who are already busy.

2) Use the command-line patchwork client to update patch state when a patch is 
committed. People have done this with a git post-commit hook to update the 
state of the patch in patchwork; I'm not sure if svn has something equivalent.

3) Batch-process the commit logs every once in a while. This can be done by 
anyone who is a patchwork admin for the project.

The second two rely on the patchwork hash of the patch. When a patch comes in, 
patchwork calculates a hash of the diff (minus a few things likely to change, 
like line numbers). The command-line client can reference patches by this 
hash, and so you don't need to keep any patchwork metadata in the changes.

> Are there ways that we can adjust our e-mail messages to make this work
> better?

As a design principle of patchwork, I've tried to avoid having to add 
patchwork metadata to the changes - after all, once the patch has gone in, the 
patchwork stuff is no longer relevant, and I don't want it polluting anyone's 
changelog...

There is one header you can add to emails:

 X-Patchwork-Hint: ignore

- this will tell patchwork to ignore the patch completely. I use this when 
sending a "this is the stuff I'm merging for the next release" email, as all 
of the patches have already been through the list.

Cheers,


Jeremy