patchwork: loses Acks if they arrive before the patchmail

[Don Zickus]

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