Backports to 1.1.1 and what is allowed

[Benjamin Kaduk]

Hi Tim,

On Sat, Jun 20, 2020 at 10:11:04AM +1000, Tim Hudson wrote:
> I suggest everyone takes a read through
> https://en.wikipedia.org/wiki/Long-term_support as to what LTS is actually
> meant to be focused on.

You may have hit on a key aspect of how we are disconnected, here.

I was under the impression that (as is the case for many OSS projects), the
fact that 1.1.1 is an LTS release means that we enter a separate "LTS mode"
at the "beginning of a long-term support period" (as Wikipedia puts it) but
that there is some period prior to the start of the long-term support
period for which the STS policies apply.

So, are you considering that 1.1.1 is now, and has always been, in LTS mode
because it is marked as an "LTS release"?  Or is there a separate STS
period before it transitions to "LTS mode"?

> What you (Ben and Matt) are both describing is not LTS but STS ... these
> are different concepts.

AFAICT the thread started with just talk of merging to stable release
branches; LTS didn't come up until Kurt's note.  I certainly was not
considering the LTS policy in my earlier comments.

> For LTS the focus is *stability *and *reduced risk of disruption *which
> alters the judgement on what is appropriate to put into a release.
> It then becomes a test of "is this bug fix worth the risk" with the general
> focus on lowest possible risk which stops this sort of thing happening
> unless a critical feature is broken.
> 
> All of the "edge case" examples presented all involve substantial changes
> to implementations and carry an inherent risk of breaking something else -
> and that is the issue.

IMO, if we're in LTS mode, if any of the proposed edge cases came up that
would indicate that we failed at the LTS policy in the first place.

> It would be different if we had a full regression test suite across all the
> platforms and variations on platforms that our users are operating on - but
> we don't.
> 
> We don't compare performance between releases or for any updates in our
> test suite so it isn't part of our scope for release readiness - if this is
> such a critical thing that must be fixed then it is something that we
> should be measuring and checking as a release condition - but we don't -
> because it actually isn't that critical.

It can translate to real monetary impact in some cases (e.g., at scale).
But I can't directly refute your point, it is true.

-Ben