Hi Eugeniu,
Replicating the chronology of the issue, do you think it could be related to 1) the patch size or to 2) the moderator's approval event?
+--------------+ |1. Patch sent | +------+-------+ | +------v----------------------------------------+ |2. U-Boot reports awaiting moderator's approval| | (the patch does not show up in patchwork) | +------+----------------------------------------+ | +------v-------------------------------+ |3. Reply A (not rendered by patchwork)| +------+-------------------------------+ | +------v-------------------------------+ |4. Reply B (not rendered by patchwork)| +------+-------------------------------+ | +------v-----------------------------+ |5. Patch approved by moderator | | (the patch shows up in patchwork)| +------+-----------------------------+ | +------v---------------------------+ |6. Reply C (rendered by patchwork)| +------+---------------------------+ | +------v---------------------------+ |7. Reply D (rendered by patchwork)| +----------------------------------+
Ah, that would explain it. If an incoming email is not a patch, then patchwork will assume it is a follow-up to a patch, and try to find the relevant patch (through the References: and In-Reply-To headers). If no suitable patch is found, then patchwork does not save the email.
It sounds like that's what's happening here. Since reply A and reply B are referencing a patch that does not (yet) exist, then the comments are not kept.
The alternative would be to keep *every* submission to the list, in case a relevant patch arrives later...
Cheers,
Jeremy
I guess we could attempt to decode these, though that's arguably a new feature so I'm not sure if we could backport it to 'stable/2.1'. In any case, could you provide an mbox replete with all the headers so I can see if there are any heuristics we can use to identify these emails?
Do you mean https://patchwork.ozlabs.org/patch/1117783/mbox/ ?
Stephen
Thanks again!