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
