Hi,
On Mon, Oct 12, 2015 at 01:54:24PM -0700, Brian Norris wrote:
> Occasionally, I'll run across patches from the linux-mtd mailing list
> that never show up on the ozlabs.org Patchwork instance. I don't
> really have much visibility into this problem, so I wanted to reach
> out here.
>
> For one example: the patch shows up at the mailing list [1], but not
> here on Patchwork [2]. The patchwork parser helper [3] seems to parse
> the email OK locally, and it recognizes it as a patch.
>
> The problem is actually the same for the entire series of which [1] is
> a part. I think I've ran across a few others of these over time, but I
> usually just ignore it and continue on. After all, patchwork only
> augments my workflow -- it's not central.
>
> Any tips?
I do also see this happening on fdo.org. Two theories right now:
- mailman fails us. I have seen occurences where the patch shows up in
the mailman archive but isn't received by some people (some of them
can be patchwork). This would need to be debugged more seriously
looking at what mailman does.
- mails are received by postfix (or sendmail, ...) and piped over to
patchwork's parsemail.sh through /etc/aliases. It's not entirely
clear reading the documentation and I haven't gone through postfix
source code, but it's apparent that there's no serialization: there
can be several mail parsing processes running at the same, racing
for db accesses. It may or may not a problem with the patches only
patchwork, but my series work does make that issue obvious. I have a
patch in testing that takes a file lock to ensure the mail insertion
is atomic, it may well solve other issues (hand waves, I haven't
really authored parsemail.py looking for such races).
HTH,
--
Damien
_______________________________________________
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
