Development Process and Backporting patches to release branches

Development
#1

This came up in the context of https://github.com/apache/incubator-tvm/issues/4824 where there was a pretty fundamental bug that affected the 0.6 release. Zhao, (@FrozenGene ) suggested that we have regular point releases on the release branch but I think there are a few items the community needs to consider before this can happen.

  1. Be reasonably clear about the criteria for backports. There is not always a clear answer but correctness issues are likely to need backports but then you don’t want a too risky backport so that we are not chasing bug tails by introducing a new bug to fix an old one. Thus there needs to be a risk vs reward evaluation by either a group of release managers or the reviewer community in an objective manner. For example the fix for the issue referred to above and the related fix to fixup the tests are appropriate in my opinion, however large fixes that require refactoring changes really should not be. We use all tools in our toolbox to ensure that the release remains stable and only improves in quality over time.

  2. Reviewers need to help that contributors improve descriptions in the pull request and ask the question which release branches a particular issue affects. Further if pull requests combine bug fixes with new features especially regression fixes, such pull requests need to be split up as our current policy is to squash commits and then it’s not obvious what came from where if we want someone to do a bit of archeology. Ensure test coverage that catches a failure.

  3. Improve the template of the Pull Request and Issues reminding users / developers submitting bugs or bug fixes that they be kind to their fellow community by taking the time to examine where and when the bug was introduced. Bugs occur, they are a fact of life and it’s also a fact of life that they need to be managed and it needs co-operation among developers.

  4. Make it easier to query open bugs in terms of Known to Work and Known to Fail fields.

  5. Finally we need to decide how long we would keep a branch going - what’s the branch management lifecycle ?

Discuss !

Ramana

AutoTVM log format
#2

I agree to must of your points. wrt to branch management, I think it makes sense to start with backporting to the last release.

Feel free to share ideas about how to act on your other items

#3

I would start with incorporating these points in the “Development Process” bits in the TVM documentation. Will put up a pull request since no one has commented on this in about 2 months.

Ramana

2 Likes
#4

That sounds good. @ramana-arm it would be great if you send an RFC with a particular proposal(since some of the original items are posed as discussions), some of them can go to the reviewer guide.

#5

Some of the thoughts (wrt to your items)

  • A1 backport correctness bugfixes (in the developer guide)
  • A2 split out the PR that needs involves regression fix (and tag them as [BUGFIX]). Add another tag [BACKPORT-version] for backporting to a previous version.
  • A5 for now, keep supporting the last stable release.