So we've started doing hotfix releases (v14.2.6 & v14.2.7), yay! Unfortunately, this process is involving some kind of rebase which is wrecking the release commit history. Exhibit A: https://github.com/ceph/ceph/pull/32602 I'm in the process of fixing my backports but for those looking after I'm done, my backport PR now has 156 commits including merges where only 2 should exist. This must not continue. Asking backporters to rebase every backport PR whenever we do a hotfix is a non-starter, IMHO. There's been discussions about using some various branching strategies to make this work better but that would complicate the existing release process and/or muck up upgrade tests. (In particular, it's been suggested that the release branch _only_ point to a tagged release.) Without entering into a drawn out discussion on how we could fix the release process, I'm going to suggest the following git workflow to avoid rebases within the current limitation of the release branch always pointing to the cutting edge state: (1) Hotfix need identified: save current branch state: git checkout $release git branch $release-save git push upstream $release-save # push branch save to GitHub for disaster recovery (2) In GitHub, restrict branch push rights on $release. (3) Hard reset to last tagged release: git reset --hard vX.Y.Z git push --force upstream HEAD:$release (4) Do hotfix merges. (5) Tag/test release. (6) Merge the saved branch onto the release branch: git merge $release-save git push upstream $release # no --force should be necessary! No history is lost. The commit history reflects the reality of what happened. No backport rebasing. -- Patrick Donnelly, Ph.D. He / Him / His Senior Software Engineer Red Hat Sunnyvale, CA GPG: 19F28A586F808C2402351B93C3301A3E258DD79D _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
