On 13/08/10 12:35, Amit Kucheria wrote:
patchwork[1][2][3] can already monitor mailing lists for patches and is used by several projects (Linux kernel, various sub-system maintainers, etc.) to make sure that patches posted to the mailing list are not dropped. (cc'ed Jeremy, author of patchwork)
This is not necessary. Launchpad merge proposals already handle this.
We could use it to monitor the output from the launchpad branch subscriptions, but can it cope with the idea that the patches are targeted at both upstream, *and* the next rebase, *but* only if the patch went into a later baseline upstream?
We're not tracking whether a patch has been reviewed or rejected here. We tracking where it exists, and does not exist.
What would be very useful is patchwork on steroids that can track pre-configured upstream git trees and figure out which patches already landed in those trees (with tag info). This could be done by searching based on author, commit one-line description and detailed description and perhaps even the contents of the commit itself. This info that then be automatically updated in the patch tracker.
That would be nice, assuming it worked, but I don't think we want to put much effort into implementing it, and I certainly don't want to wait until it is implemented to have any solution at all.
Andrew