Re: Backports to 1.1.1 and what is allowed

2020-06-22 Thread 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.


Re: Backports to 1.1.1 and what is allowed

2020-06-22 Thread Salz, Rich
  *   I suggest everyone takes a read through
 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

2020-06-22 Thread Matt Caswell

On 20/06/2020 01:11, Tim Hudson wrote:
> I suggest everyone takes a read through 
> 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.


Re: Backports to 1.1.1 and what is allowed

2020-06-22 Thread Tomas Mraz
On Sun, 2020-06-21 at 14:34 -0700, Benjamin Kaduk wrote:
> Hi Tim,
> On Sat, Jun 20, 2020 at 10:11:04AM +1000, Tim Hudson wrote:
> > I suggest everyone takes a read through
> > 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"?

In my opinion the 1.1.1 should not enter such strongly restricted phase
earlier than after the 3.0 is released.

Ideally, if we had releases based on some predictable cadence and not
rather feature based ones, we should have 3 active branches - master
for development of new features, one branch with bug fixes and even
non-invasive performance fixes, and one branch for LTS where only
security fixes with above than low severity and severe bug fixes would
be applied.

Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your