Tflite frontend needs to use zero point of input tensor while lowering qnn.conv2d for padding

[u99127]

The Tflite frontend ignores the zero point for input tensors when creating a separate pad operation while lowering quantized convolutions.

This is fixed by PR #4807 and the tests broken by that are fixed #4816

This also affects the 0.6 branch since the support for this landed before the 0.6 release was cut and the fix might need to be backported to the 0.6 branch.

[FrozenGene]

Nice suggestion! We won't do similar things before. For some critical patches, we should port it back to our previous releases (like 0.6 mentioned here). I come up with two suggestions:

1. make one new release named as 0.6 SP1 / SP2 / SP3 /..., SP means service pack, the inspiration comes from Microsoft's release concept. Like Visual Studio SP1 / SP2 / SP3.

2. make one new release named as 0.6.1 / 0.6.2 / 0.6.3 / .... .1 / . 2 / .3 is the patch version. This inspiration comes from LLVM's release concept. Like LLVM 3.7.0 / 3.7.1 / 3.7.2 /.

cc @tqchen @zhiics @yzhliu @icemelon9

[tqchen]

Let us mark the related PRs with [NEED-BACKPORT] tag, and then we can backport to the related branches

[u99127]

@tqchen , @FrozenGene

[NEED-BACKPORT-0.6] ? since there's no way of reporting what issues affect what versions in github issues ?

This is probably worth a discuss post, however I'll say my piece here in response to the comment about point releases.

Releasing from a release branch is the next step in my opinion. The first set of steps towards this are to:

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 this fix and the related fix to fixup the tests is appropriate, however large fixes that require refactoring changes will not be at which point you need a different fix.

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.

3. Optionally add this to the template of the Pull Request reminding developers submitting bug fixes that they could help the project by considering whether a pull request requires a backport or not.

4. We need an update to the contributor's guide

5. How do we help the reporter report the version that the issue was reported in ? Currently it's free form text but if that were a drop down list that would be great and thus keeping that information there.

6. Finally decide how long we would keep a branch going - what's the branch management lifecycle ?

My 2 cents.
regards
Ramana

[tqchen]

@u99127 perhaps we can open a discuss thread on the forum. I agree with most of your points :)

[u99127]

Done https://discuss.tvm.ai/t/development-process-and-backporting-patches-to-release-branches/5612