Improve hotfix documentation

[juliangiebel]

The wording wasn't consistent with the rest of the doc and the explanation wasn't clear enough

[Errant-4]

So, we actually did have to do a hotfix just now and this update was very useful, but we found this error

s'fine

[PJB3005]

This still needs to explain how the commits should be made. I assume the obvious answer is "use a cherry pick" but I would like to see this written down.

[juliangiebel]

I assume the obvious answer is "use a cherry pick"

The whole reason for this procedure is to not have to cherry pick commits.
This doc needs to be changed to use squash merging on github when merging hotfix PRs into stable as discussed with pjb.

[benev0]

As mentioned in the maintainer meeting...

It looks like cherry-picks are required for both hotfix schemes PR into Stable and cherry pick from Master. Red is the hot fix in the diagram. Both schemes have problems. Git does not store diffs so merge conflicts should not be created by cherry picking from master into stable. For the merge strategy, changes parallel to the hotfix can occur causing conflict when the return pr from stable to master is made requiring cherry-pick or elaborate branching and merging: branch off stable, merge master into stable, resolve conflict, create PR into master.

If a hotfix using cherry pick into stable from master has a conflict, it is a strong indicator that the cherry pick was done incorrectly. All cherry-picks should not depend on other changes in master which are not present on stable. Conflicts can also indicate that hotfixes with file overlap have been merged in a different order than originaly.

If it is the case that merges from master to stable should always fast forward, then PRs into stable break this guarantee by allowing parallel changes. Resolution of such conflicts will require cherry picking or previously mentioned elaborate branching and merging.

If it is not the case that merges from master to stable should always fast forward, then patching main then patching stable with a cherry pick will be inhibited. This is based of the assumption that patch environment should be the sable branch to avoid unnecessary pollution. Developers pull current stable (on fork) make a PR into master this commit is then cherry picked into stable. Since stable is not a guaranteed fast forward merge, conflicts with the cherry pick may occur.

I believe that these are effectively mutually exclusive strategies

obsolete

[Errant-4]

Approved by vote