**As a developer, you do not need to change how you use the "Pick-to:" footer.** You can stop reading here if you don't care too much about the details. ;)
Over the past few years with the automatic cherry-picking, a common issue has emerged: lost and forgotten cherry-picks. When the cherry-pick bot picks to multiple branches, it's too easy to miss the email about a failed integration or merge conflicts on a target branch. This often results in forgotten picks, and unfortunately, a number of regressions where a pick makes it into an older branch but never integrates to the newer one. To help reduce the amount of noise in everyone's email inbox and gerrit dashboard, we're introducing a change to the cherry-pick bot which will "waterfall" cherry-picks from newest to oldest target branch in sequence, rather than in parallel as it is today. Here's how it works: Say a change on dev exists with a footer "Pick-to: 6.5.2 6.5 6.2". Under the new model, instead of three picks, there would be only one. The change would be picked immediately to 6.5, and a "Pick-to: 6.5.2 6.2" footer will be added to that cherry-pick. In this way, the change will "waterfall" down from the newest to oldest feature branch. A fix for a release branch would not be picked until the change on the feature branch has been merged. The (cherry-picked from xyz...) and <Reviewed-By: > footers will remain intact so the chain of picks can be fully traced. However, this new model can introduce a new problem. For example, if the change for 6.5 takes too long to merge and a new release branch, let's say 6.5.3, is created, then a regression could be introduced if the change on 6.5.2 were accepted and merged. To assist with this, the cherry-pick bot will now actively scan the cherry-pick targets, identifying gaps in the targets and adding those as new pick targets during the cherry-pick process. For instance, if a branching event occurs while the change is in-review, the gap will be filled automatically. Likewise, if a target was simply forgotten in the footer, it will be detected and added. If a patch does not apply or a merged change already exists on the gap branch, then the gap branch will be ignored. Because this change takes away some level of control from the user, a new footer is being introduced. A new footer, proposed as "Hotfix-to: " will behave as the old logic does today, blasting all Pick-to targets in parallel with no gap checking or validation for existing changes. It's recommended to use the "Pick-to:" footer as often as possible and reserve "Hotfix-to:" for security or other critical fixes which can't wait on the waterfall cherry-pick automation. This new process should also lead to fewer merge conflicts, as changes picked from 6.5 -> 6.2 should be more similar than from dev -> 6.2 in some cases. tl;dr Keep using the Pick-to: footer as you normally do. The backend of the process is changing and you won't see all your picks occur in parallel anymore. This change is scheduled to deploy in early September. A more specific date will be given in late August. Bed regards, -Daniel daniel.sm...@qt.io -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
