Qt Contributors Summit 2019 - Branch Policy: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
mNo edit summary
m (slight grammar fixup)
Line 1: Line 1:
== Discussed and Agreed Proposal ==
== 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 move to a workflow where we make all changes in dev, and then cherry-pick relevant changes from dev down into more stable 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)
* 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
* cherry-picks inherit the review/approval of the original change
Line 13: Line 13:
* In exceptional cases, and to unblock a release, changes might go first into a release branch and cherry-picked forward into dev
* 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
** another exception is fixes in stable branches that are not relevant for dev


== Concerns ==
== Concerns ==

Revision as of 11:54, 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 more stable 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