Re: Backports to 1.1.1 and what is allowed

[Patrick Steuer]

From the view of an application dev ..

1 the reasons to chose OpenSSL over other crypto libraries are its
  rich feature set and wide portability paired with good performance
  across a wide range of platforms plus having a customizable
  backend (engines/providers).

2 the reasons to not move away from OpenSSL trusting in LTS releases
  actually being stable i.e., not causing any disruptions.

(For both 1 and 2, a good security record is a matter of course.)

IMO the current release policy of infrequent "big bang" releases
serves 2 well, but largely neglects 1 (think e.g., about
time-to-market for new processor features).

That doesnt mean that we should take all features into LTS
but i think performance improvements is an area where you
should think about it, at least in individual cases.

Patrick

Re: Backports to 1.1.1 and what is allowed

[Salz, Rich]

  *   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.

For what it’s worth, I think Tim’s comments are spot-on.  An LTS release should 
not change unless there are serious bugs or new security flaws.

It is tempting to add new hardware support, nor improved performance.  “Hey, 
everyone will get this in their long-term offering.”  But you’re thinking the 
wrong way.  Imagine that each new patch to an LTS release requires massive 
effort, such as changing the firmware on a plane. Does the change justify that? 
 Almost always, the answer is no.

Re: 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