Qt Contributors Summit 2019 - Branch Policy: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(Add session notes from branching policy discussion)
 
mNo edit summary
Line 6: Line 6:
* if no conflicts, they are staged automatically (but only once); if conflict, result is a new code review that original author needs to amend
* 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, and continue to merge 5.15 into dev until 5.15 has reached feature freeze.
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 ===
=== Exceptions ===

Revision as of 08:49, 21 November 2019

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