**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.





---
[Visit 
Topic](https://discuss.tvm.ai/t/rfc-improve-pull-requests-with-respect-to-bug-fixes/6529/1)
 to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, [click 
here](https://discuss.tvm.ai/email/unsubscribe/1c2b4f77c8c04e2cc914f53fe0bc1679bc5b419521deca2ebb7e03c65c33c762).

Reply via email to