Backports to 1.1.1 and what is allowed

[Matt Caswell]

On 20/06/2020 01:11, 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.
> 
> What you (Ben and Matt) are both describing is not LTS but STS ... these
> are different concepts.
> 
> 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.
> 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. 
> 

I read the page and I don't think it is contrary to anything that I
said. From the characteristics section:

"At the beginning of a long-term support period, the software developers
impose a feature freeze: They make patches to correct software bugs and
vulnerabilities, but do not introduce new features that may cause
regression. The software maintainer either distributes patches
individually, or packages them in maintenance releases, point releases,
or service packs. At the conclusion of the support period, the product
either reaches end-of-life, or receives a reduced level of support for a
period of time (e.g., high-priority security patches only).[2]"

AFAIK this is exactly what we do. We fix bugs and don't add new
features. After 4 years we transition to security fixes only.

Later, in the Rational section, it says this:

"Long-term support addresses this by assuring users and administrators
that the software will be maintained for a specific period of time, and
that updates selected for publication will carry a significantly reduced
risk of regression.[2] The maintainers of LTS software only publish
updates that either have low IT risk or that reduce IT risk (such as
security patches). Patches for LTS software are published with the
understanding that installing them is less risky than not installing them."

This, IMO, is exactly what we do.

In none of this does it say that we shouldn't fix less serious bugs or
performance regressions. It talks about risk - but that does not
preclude those kinds of fixes. In fact as I said in my answer to Kurt
earlier in this thread I do believe that risk is an important factor in
deciding what things get backported. However I don't believe that,
generally speaking, most minor bug fixes represent a significant source
of risk. I also think the same *might* be true of *some* types of
performance regressions.

Matt