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