Working out a policy around reverts for LTS branches

Comienza revisando el manejo propuesto de las regresiones en las ramas LTS, Current y master, incluido el comportamiento de revert y cherry-pick. Se considera completado cuando el Release Working Group acuerde una política que explique dónde deben aterrizar los reverts y cómo se realiza el seguimiento de las regresiones temporales.

With the v12.16.0 release, a number of regressions has been introduced, some (most?) of which also applied to v13.x and master.

One approach that has been taken to address this is to revert the problematic commits on v12.x-staging only.

I would like to handle this situation differently in the future, and work out a policy around that. I think the most important downside to the aforementioned approach is that the reverts only land on v12.x-staging, bringing LTS out of sync with the rest of our branches, while fixes are being worked on in master:

• It makes working on fixes harder from a purely technical perspective. Once they land on master, they would typically have to be backported to LTS manually, together with a revert of the revert(s) that were applied to LTS only.
• It makes it harder to have an overview of which regressions exist on which release lines. While we do apply labels to PRs to keep track of their backporting state, it doesn’t let us know which bugs have been temporarily solved through reverts that should be taken care of sooner rather than later. This is especially bad when the original change that was reverted was a bug fix; there is no way of tracking that a bug has been intentionally re-introduced as a “temporary” measure on LTS only.
• It does not motivate working on fixes. If a change is reverted on master, I generally believe that the authors are more inclined to work on a fixed version of their changes compared to when the changes are “just” excluded from LTS.
• It presents stability of master and Current releases as less important. Yes, it should be the priority to keep LTS as stable as possible, but I think we should do our best to avoid bugs in Current as well.

My suggestion for handling these types of situations would be:

• For bugs that only occur in LTS, a revert PR against the staging branch is opened and applied. I don’t think we need any special fast-tracking rules, as we’ve been handling the staging branches that way anyway. I do think that an explicit revert PR is good for documentation purposes, even if it’s landed immediately after opening.
• For bugs that occur on master, a revert PR is opened against master, and then cherry-picked back to the release lines where it applies. If pushing out releases in a timely manner is a concern here that isn’t covered by our regular fast-tracking rules, then I’m open to making changes to our policy for that.

/cc @MylesBorins