[Development] On Pick-to: and QUIP-16

[Marc Mutz]

On 17.03.25 08:58, Volker Hilsheimer wrote:
>> On 14 Mar 2025, at 17:49, Marc Mutz via Development <development at qt-project.org> wrote:
>>
>> Hi,
>>
>> TL;DR: do _not_ approve patches that do not "pick-to:" according to
>> QUIP-16 or explain in the commit message why they deviate.
>>
>> Long version:
>>
>> Just a reminder that QUIP-16¹ gives detailed instructions how far
>> certain sets of changes should be picked, so all maintainers / all
>> approvers should check that the kind of change they are reviewing and
>> the Pick-to:s supplied by the patch author matches QUIP-16. If not, the
>> commit message should contain an explanation for why the Pick-to's
>> deviate from QUIP-16, esp. when picking back less than QUIP-16 asks.
>>
>> Otherwise, do _not_ approve.
>>
>> Branch categorization as per QUIP-16:
>> - Stable: 6.8
>> - Strict: 6.5
>> - Very Strict: 5.15
>> (we do not plan more releases from 6.2 at this point, for the purposes
>> of QUIP-16, it's Very Strict)
>>
>> So UB fixes should go to 6.5, as should be big-O improvements. If an UB
>> or big-O fix is a security issue, it get picked to _all_ branches.
>>
>> References:
>> ¹ https://contribute.qt-project.org/quips/16
>>
>> Also pertinent:
>> - https://wiki.qt.io/Things_To_Look_Out_For_In_Reviews#Commit_Message
>>    Items 1, 3, and 4
>> - https://wiki.qt.io/Commit_Policy
>>    Items 7, 8, and 9.
>> - discussion extending QUIP-16 to allow more refactorings:
>>    https://codereview.qt-project.org/c/meta/quips/+/608523
>>
>> Thanks,
>> Marc
> 
> Marc,
> 
> QUIP-16 documents what kinds of changes are permitted in each branch. There is no requirement that those changes must get picked back. That decision is absolutely within the authority of the author of the change, the reviewers, and ultimately the maintainer of the respective submodule.
> 
> And it’s also perfectly fine to originally aim for a certain branch, but - upon noticing the amount of work or changes requires to resolve conflicts - abandon the cherry-picking from that branch on.

In C++, if you have implementation divergence, the std needs to be 
fixed. In Qt, we have pick-to divergence.

We need a baseline to review against. Either the baseline is QUIP-16, or 
the baseline is not to pick at all.

I don't know how this goes in other modules, but in qtbase, I have been 
bitten so many times in the last weeks by missing cherry-picks that the 
issue needs some discussion. I don't want to step on any particular 
person's toe here, because the issue is systemic, so I wont, but I could 
point out several issues in the last weeks where author + reviewer just 
didn't work.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at qt.io> (he/his)
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B