u99127 commented on issue #4824: Tflite frontend needs to use zero point of 
input tensor while lowering qnn.conv2d for padding
URL: https://github.com/apache/incubator-tvm/issues/4824#issuecomment-583660260
 
 
   @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

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

Reply via email to