Solving patch series collisions with domains?

Zebediah Figura z.figura12 at gmail.com
Fri Mar 6 09:38:10 CST 2020


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?



More information about the wine-devel mailing list