On Fri, Mar 25, 2011 at 05:01:08PM +0800, Jeremy Kerr wrote: > Hi Peter, > > > I suspect patchwork has got confused because the Ack email arrived > > an hour or so before the patch email (slow mailing list and the > > patch was cc'd to a highly responsive subsystem maintainer :-)). > > Yeah, it'll do that. If patchwork sees an email that doesn't contain a patch, > or that it can't correlate with an existing patch, the email will be ignored. > > Working-around this would require keeping all 'potential' follow-ups, which > we > don't do at the moment. I'm not sure this is a good idea in general...
At RedHat we forked Patchwork internally to track kernel patches. One of the first things we changed was to track _all_ the emails following in. It was better to have emails that weren't patches that we could manually mark as not interesting as opposed to having emails silently dropped because of wonky email servers, broken email headers, etc. The amount of extra emails that are currently dropped are probably very small compared to the amount Patchwork saves. I can't see it being a burden on the server. We also added logic to stitch together conversations like the example given (it is a manual process but can probably be made more automated). This helps us keep the conversations together (more a problem with broken Reply-To fields than delayed server). Personally I believe PatchWork is really tracking a mailing list and filtering for patches. And because people use differnt tools to send emails and patches, I always felt you can never 100% guarantee you can properly filter out patches in an automated fashion. As a result we left the ability to manually handle the 1% of email that falls outside the normal mold. Just adding my two cents here.. Cheers, Don _______________________________________________ Patchwork mailing list [email protected] https://lists.ozlabs.org/listinfo/patchwork
