Motivation
We would like to move towards a world where there is a clear attempt to try and start becoming more predictable with release cycles and what the usage of a release is going to be . As part of this ,releases need regression fixes. However, if the community is making releases, there is likely to be an expectation from users that such releases have reasonable practices in terms of backporting fixes to the release branches and other aspects of development. Backporting patches to previous release branches always have a risk and thus in addition to having a review we need someone to think whether the benefits outweigh the risk of additional breakage that our testing would not cover.
Current Development Processes and it’s effects
In the current processes, there isn’t clear separation between bug fixes and new features and many a time a pull request will merge both a bug fix and a feature request together in the same pull request. This is our defacto working practice. Further when the pull request is merged, the history within the pull request is entirely lost from the tree as the pull request is squashed when it is merged and further there is no requirement on the original developer to retain the branch from which the pull request is created. This makes it difficult to track what the change is a finite time after the change was merged in.
Next Steps
In terms of next steps, I propose the following steps that we can take.
A1. Change our contribution documentation to cover that pull requests need to be small, self-contained and not mix bug fixes and new features.
A1.1 Make this part of our Pull Request Template.
A2. Tag Bug fixes as [Bugfix] or [RegressionFix] in the Pull Request.
A2.1 Identify which Release it was a regression in when an issue is found.
A2.2 Agree that the fix is small enough to be backported to the release branch.
A2.3 If you are proposing this as a backport, propose this with a tag using [Backport-fix-<branchtobackportto>
A2.4 The contributor backports and a reviewer after evaluating the risk of the backport approves it explicitly.
A2.5 Document this in the Issue Template in github.