<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 1. If the `/backport` command is used in an **open** pull request, it adds a label `Backport=repo:branch` to the PR. If the PR is later integrated, the PR bot scans for backport labels and begins the backporting process. To cancel the backport, the user can use `/backport disable repo master` to remove the label before the PR is integrated.<br>
<br>
This does not sound desirable. Fixes should undergo some bake time in <br>
the primary repo before they get backported anywhere. With the current <br>
situation it is up to the person doing the backport to go to the commit <br>
in question and know that the commit has been suitable tested/baked.<br>
<br>
David<br>
-----<br>
<br></blockquote><div><br></div><div>I agree with David. Making it easy to downport fresh changes right away is not something we should encourage.</div><div><br></div><div>Yes, there are cases of super-simple fixes that can be backported right away. But those are the exception. Update releases are *maintenance* releases with a much larger customer surface than the head release. If something goes wrong, the impact is large and immediate.<br></div><div><br></div><div>But we only have limited testing resources for update releases. We do our best, but the mainline is still much better tested. We live with that; we assume that backports have been exposed in the mainline repo long enough for issues to surface. Immediate backporting breaks this assumption.<br></div><div><br></div><div>Cheers, Thomas<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><br></div></div>