On 3/6/20 8:18 AM, Francois Gouget wrote:
On Thu, 5 Mar 2020, Marvin wrote: [...]
=== debiant (build log) ===
error: patch failed: dlls/d3d11/device.c:941 error: patch failed: dlls/d3d11/state.c:1079 error: patch failed: dlls/wined3d/device.c:3600 error: patch failed: include/wine/wined3d.h:2037 Task: Patch failed to apply
The TestBot mixed up this 5-parts wined3d patch series with the other 5-parts patch series for qcap / qedit.
One was a v2 and not the other so taking into account the version would have avoided the issue in this case (the patch for this should go in next monday).
But this could just as well have happened with unversioned patch series: [PATCH 1/5] wined3d: ... vs. [PATCH 1/5] qcap/capturegraph: ...
The subject parsing code extracts a property I have been calling the 'domain' (for lack of a better term) which is a word that's sometimes added in the square brackets. It's usually used to indicate the Git repository the patch should go in: [vkd3d 1/2], [tools], etc.
But it could also be used to avoid collisions between patch series: where the TestBot identifies patch series based on the (Sender, Version, PartCount) tuple, it could add the domain to the mix: (Sender, Domain, Version, PartCount).
This would allow sending two patch series with the same number of parts without causing a collision:
[wined3d 1/5] wined3d: ... + [qcap 1/5] qcap/capturegraph: ...or [wined3d 1/5] wined3d: ... + [PATCH 1/5] qcap/capturegraph: ... or [PATCH 1/5] wined3d: ... + [PATCH qcap 1/5] qcap/capturegraph: ...
PATCH can be thrown in to help identify patches, or omitted. It makes no difference to the TestBot.
Not using a domain would work just as well in the absence of a collision. And if two patch series risk colliding, adding a domain would help avoid the collision. The only drawback is one has to anticipate and remember to specify the domain before sending the emails.
Would taking the domain make sense? Would it be worth it?
Wait, so why isn't checking In-Reply-To enough here?