Qt Contributors Summit 2019 - Branch Policy

Discussed and Agreed Proposal

• We move to a workflow where we make all changes in dev, and then cherry-pick relevant changes from dev down into stabler branches
• We are automating the cherry-picking with a bot that interprets a commit footer. That makes the cherry-picking part of the review and approval (approver has to confirm that patch is applicable for a stable branch)
• cherry-picks inherit the review/approval of the original change
• if no conflicts, they are staged automatically (but only once); if conflict, result is a new code review that original author needs to amend

We start with Qt 5.15/14/12 (ie 5.15 is “dev” in the Qt 5 series), and continue to merge 5.15 into dev until 5.15 has reached feature freeze.

Exceptions

• Changes file updates are done in the relevant release branch; the files are then carried forward to dev, and cherry-picked down from there as usual
• In exceptional cases, and to unblock a release, changes might go first into a release branch and cherry-picked forward into dev
  • another exception is fixes in stable branches that are not relevant for dev

Concerns

• people are not used to having to work on dev; even with now defaulting clones to dev
• it might generate more work for maintainers
• another commit footer that introduces clutter
• without merging, it might become more difficult to find out where a patch landed
• merge conflicts need to be resolved potentially repeatedly (for each cherry-pick), vs a merge where resolutions are recorded; we assume this to be a rare situation
• load on CI might increase (more frequent, smaller changes, rather than occasional merge change)

Actions

Documentation

• document the new flow
• communicate it clearly to the mailing-list
• update the wiki, relevant guidelines, QUIPs

Tooling

• automation triggered by commit message footer
• needs to respect the order when cherry-picking
• change log script needs to update the correct change file