> 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. Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
