On 17.03.25 08:58, Volker Hilsheimer wrote:
>> On 14 Mar 2025, at 17:49, Marc Mutz via Development 
>> <development@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.m...@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

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to