| Summary: | patchtest-send-results should reply to specific threads | ||
|---|---|---|---|
| Product: | [Yocto Project Subprojects] Patchwork/Patchtest | Reporter: | Trevor Gamblin <tgamblin> |
| Component: | Patchtest | Assignee: | Trevor Gamblin <tgamblin> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | mhalstead, randy.macleod, richard.purdie, ross.burton |
| Version: | 5.0 | ||
| Target Milestone: | 5.1 M3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
|
Description
Trevor Gamblin
2023-10-30 15:29:03 UTC
Make it the default please! *** Bug 15271 has been marked as a duplicate of this bug. *** Did some investigating into this and found that there are actually two message IDs for patches on the mailing list, as described by the email headers: the "X-Orig-Message-Id" and the "Message ID". The latter seems to be what is needed to reply correctly to a message thread, but the former is what is available in the patch files that patchtest pulls from Patchwork. The Groups.io Help Center page confirms that it replaces the original message ID and renames the old one if a checkbox is selected in the account preferences (for a mailing list?): https://groups.io/helpcenter/membersmanual?single=true under "Seeing copies of your own messages that you email to groups": "For those interested in the technical details: When this checkbox is selected, Groups.io replaces the Message-Id header with a new, system-generated one and renames the original Message-Id header to X-Orig-Message-Id." I'm not sure what the larger implications for the mailing list usability would be if this is indeed an account setting for openembedded-core@lists.openembedded.org. If true and we don't want to change the groups.io settings, some extra function could be written to scan the mailing list for the right patch and get the new message ID, but that could have a lot of test time/validation impacts. We'll have to scan the mailing list and compare message IDs to get the right one to respond against. After review that's incorrect - I was operating under incorrect assumptions about message ID mangling. Submitted a patch to use In-Reply-To with results emails. Fixed in https://git.yoctoproject.org/poky/commit/?id=2bddb6bb97075a2dd8e988867e0ee6e4556d2924 and https://git.yoctoproject.org/poky/commit/?id=b53d1287d24f506a08905fa86a81aca21203e73a The threading is still not happening correctly. See for example https://lore.kernel.org/openembedded-core/0101018d7d1f5ee6-9ed9018f-ac7d-48ee-bbfb-c24420673d13-000000@us-west-2.amazonses.com/T/#u which is not threading as a reply to https://lore.kernel.org/openembedded-core/20240206061701.3947297-1-simone.p.weiss@posteo.com/T/#u. This impacts patchwork, as the patchtest reply doesn't appear at all: https://patchwork.yoctoproject.org/project/oe-core/patch/20240206061701.3947297-1-simone.p.weiss@posteo.com/ Trevor is working on this. Sent a patch to add the 'References' header to patchtest-send-results in oe-core. That should fix this issue. Michael, Trevor is mostly waiting for your input on why the threading isn't working. Steve was right in the bug triage meeting - it seems to be threading properly now. I'll keep an eye on it and reopen this if there are instances where it doesn't. See: https://lists.openembedded.org/g/openembedded-core/topic/patchtest_results_for/104591017?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,104591017,previd%3D1708981536361105116,nextid%3D1708939175624870970&previd=1708981536361105116&nextid=1708939175624870970 That one didn't thread the way it should've. Shorter comment: https://lists.openembedded.org/g/openembedded-core/topic/patchtest_results_for/104591017 I haven't seen patchtest fail to thread responses in a while. It would still be good to improve the subject line in its replies, but that's not a factor in whether it replies to the right email. I'll close this for now, but if we see problems again then it can be reopened. |