Details
-
User Story
-
Resolution: Done
-
P2: Important
-
None
-
None
-
None
Description
As per the discussion of Branch Policy at the Qt Contributors Summit 2019, we want to move away from the current flow (new features in dev; certain bug fixes in stable branches; merge-master forward-merges changes from stable to dev; some cherry-picking for LTS branches), towards a flow where all changes go into dev, and are then cherry-picked into relevant stable branches.
The flow we would like to end up with should be supported by automation:
- contributors puts all "fresh" changes up for code-review, normally against dev
- Exceptions are release-specific changes: changes-files or rare hot-fixes, which go directly into the respective release branch
- commit footer may include a tag indicating which branch(es) the change should be picked into after successful integration
- Tag name suggestions: Pick-to:, Pick-into:, Backport-to:
- Tag value: comma-separated list of branch names; most stable branch (in-between branches are inferred by tool)
- exceptional changes made in release branches MUST include such a commit footer
- Reviewers/approvers confirm that change is suitable for specified target branches
- once approved, staging and integration into dev as usual
- once integrated, gerrit triggers a tool that reads the tag in the commit footer, and generates a cherry-pick commit (with -x) into each branch listed
- the tool ensures that commits are cherry-picked in the same order in which they appear in the original target branch
- for each cherry-pick, generate a code review with the same owners, reviewers, and approvals as original commit
- if there is no conflict, stage the cherry-picked change automatically (integrate into target branch if successful)
- in case of conflict, or in case of CI failure: alert owners and reviewers
At this point, the change is either successfully cherry-picked into all branches, or requires manual follow-up (conflict resolution or back-porting of the change) by the owner of the change for some or all branches. The usual process applies, ie amending the change, getting new reviews and approvals, and staging; or abandoning those changes where the backporting effort turns out to be too significant. The owner of the change can freely decide how they resolve issues (each problematic branch separately, or fix once and cherry-pick further from there).
Attachments
Issue Links
- depends on
-
QTQAINFRA-3558 Add staging events from the qt-workflow-plugin to the gerrit event stream
- Closed
-
QTQAINFRA-3621 Add CI bot events to the gerrit event stream
- Closed
- relates to
-
QTQAINFRA-3739 Cherry-pick bot: Update error messages posted to gerrit to include a friendly summary
- Closed
- resulted in
-
QTQAINFRA-3663 Warn when pushing non-cherry-pick change to branches other than dev
- Closed
- mentioned in
-
Page Loading...