<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi Fuelers,<br><br></div>I would like to address a concern I have with backporting policy. I'm sure all of you know that we should always land patches to master before it reaches stable/X.X branch. What you are not aware of probably is that many people are making cherry picks well in advance of gathering reviews and getting the patch landed in master. Some argue that it "saves time waiting on CI", but in reality it's quite the opposite. Adding a cherry pick before merging master causes the following workflow to take place:<br></div>1 - Propose to master and to stable/7.0<br></div>2 - CI runs on 2 patches<br></div>3 - Reviewer A comments on master patch<br></div>4 - owner adjusts both patches and runs CI<br></div>5 - Reviewer B comments on stable patch<br></div>6 - owner adjusts both patches and runs CI<br></div>(repeat 3-6 in varying degrees until enough patches are gathered)<br></div>7 - rebase stable/7.0 patch again... wait for CI again<br><br></div>This doubles the burden on CI and complicates the overall review process where we are accepting feedback for the initial solution on two (nearly) identical patches. What's worse is it's possible that the two solutions merged won't be identical and introduce potential regressions.<br><br></div>I propose we avoid raising any stable/X.X patches before a patch is _merged_ into master to avoid this scenario. Additionally, if a core sees that this is happening, he or she should mark it -2 and discourage submission of new patchsets.<br><br></div>I welcome your thoughts and feedback.<br></div><br>Best Regards,<br></div>Matthew Mosesohn<br></div>