Re: Backports to 1.1.1 and what is allowed

2020-06-25 Thread Nicola Tuveri
Sorry yes, I meant to refer to the open PR with the s390 support, I picked the wrong number! On Thu, Jun 25, 2020, 17:54 Matt Caswell wrote: > > > On 25/06/2020 15:33, Nicola Tuveri wrote: > > In light of how the discussion evolved I would say that not only there > > is consensus on supporting

Re: Backports to 1.1.1 and what is allowed

2020-06-25 Thread Matt Caswell
On 25/06/2020 15:33, Nicola Tuveri wrote: > In light of how the discussion evolved I would say that not only there > is consensus on supporting the definition of a detailed policy on > backports and the definitions of what are the requirements for regular > releases vs LTS releases (other than

Re: Backports to 1.1.1 and what is allowed

2020-06-25 Thread Tomas Mraz
On Thu, 2020-06-25 at 14:49 +, Dr. Matthias St. Pierre wrote: > Since already a few backporting requests to 1.1.1 have accumulated > which are controversial > or not allowed for an LTS release, would it make sense to consider > creating a new 1.1.2 STS > branch which could then receive such

RE: Backports to 1.1.1 and what is allowed

2020-06-25 Thread Dr. Matthias St. Pierre
Since already a few backporting requests to 1.1.1 have accumulated which are controversial or not allowed for an LTS release, would it make sense to consider creating a new 1.1.2 STS branch which could then receive such changes? Matthias

Re: Backports to 1.1.1 and what is allowed

2020-06-25 Thread Nicola Tuveri
In light of how the discussion evolved I would say that not only there is consensus on supporting the definition of a detailed policy on backports and the definitions of what are the requirements for regular releases vs LTS releases (other than the longer support timeframe), but also highlights a

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

Re: Backports to 1.1.1 and what is allowed

2020-06-22 Thread Salz, Rich
* I suggest everyone takes a read through

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

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 > > https://en.wikipedia.org/wiki/Long-term_support as to what LTS is > > actually > > meant to be focused on. > > You

Re: Backports to 1.1.1 and what is allowed

2020-06-21 Thread 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

Re: Backports to 1.1.1 and what is allowed

2020-06-19 Thread Tim Hudson
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

Re: Backports to 1.1.1 and what is allowed

2020-06-19 Thread Benjamin Kaduk
On Fri, Jun 19, 2020 at 11:46:15PM +0100, Matt Caswell wrote: > > > On 19/06/2020 23:34, Tim Hudson wrote: > > > > > > On Sat, 20 Jun 2020, 8:14 am Benjamin Kaduk, > > wrote: > > > > On Sat, Jun 20, 2020 at 08:11:16AM +1000, Tim Hudson wrote: > > > The general

Re: Backports to 1.1.1 and what is allowed

2020-06-19 Thread Matt Caswell
On 19/06/2020 22:58, Kurt Roeckx wrote: > On Fri, Jun 19, 2020 at 10:29:24PM +0100, Matt Caswell wrote: >> >> My immediate reaction to that is no - it shouldn't go to 1.1.1. That >> would impact a very high proportion of our user base. > > So is risk an important factor? How do you judge the

Re: Backports to 1.1.1 and what is allowed

2020-06-19 Thread Matt Caswell
On 19/06/2020 23:34, Tim Hudson wrote: > > > On Sat, 20 Jun 2020, 8:14 am Benjamin Kaduk, > wrote: > > On Sat, Jun 20, 2020 at 08:11:16AM +1000, Tim Hudson wrote: > > The general concept is to only fix serious bugs in stable releases. > > Increasing

Re: Backports to 1.1.1 and what is allowed

2020-06-19 Thread Tim Hudson
On Sat, 20 Jun 2020, 8:14 am Benjamin Kaduk, wrote: > On Sat, Jun 20, 2020 at 08:11:16AM +1000, Tim Hudson wrote: > > The general concept is to only fix serious bugs in stable releases. > > Increasing performance is not fixing a bug - it is a feature. > > Is remediating a significant performance

Re: Backports to 1.1.1 and what is allowed

2020-06-19 Thread Benjamin Kaduk
On Sat, Jun 20, 2020 at 08:11:16AM +1000, Tim Hudson wrote: > The general concept is to only fix serious bugs in stable releases. > Increasing performance is not fixing a bug - it is a feature. Is remediating a significant performance regression fixing a bug? -Ben

Re: Backports to 1.1.1 and what is allowed

2020-06-19 Thread Tim Hudson
The general concept is to only fix serious bugs in stable releases. Increasing performance is not fixing a bug - it is a feature. Swapping out one implementation of algorithm for another is a significant change and isn't something that should go into an LTS in my view. It would be less of an

Re: Backports to 1.1.1 and what is allowed

2020-06-19 Thread Kurt Roeckx
On Fri, Jun 19, 2020 at 10:29:24PM +0100, Matt Caswell wrote: > > My immediate reaction to that is no - it shouldn't go to 1.1.1. That > would impact a very high proportion of our user base. So is risk an important factor? How do you judge the risk? By the size of the change? Kurt

Re: Backports to 1.1.1 and what is allowed

2020-06-19 Thread Matt Caswell
On 19/06/2020 21:42, Kurt Roeckx wrote: > I think one other thing that has come up is adding support for a > new target, which can just be some small change to configuration > files. Is that something we want to accept? I think previously we have said that a new target is a new feature and

Re: Backports to 1.1.1 and what is allowed

2020-06-19 Thread Kurt Roeckx
I think one other thing that has come up is adding support for a new target, which can just be some small change to configuration files. Is that something we want to accept? Kurt

Re: Backports to 1.1.1 and what is allowed

2020-06-19 Thread Kurt Roeckx
So we currently also have PR #12201 that adds a new constant time P-384 implementation. Do you think we should backport that to the 1.1.1 branch? If the answer is different than for the assembler, why? Does 1.1.1 being an LTS release have any effect on the answer? For instance, if we add some

Re: Backports to 1.1.1 and what is allowed

2020-06-16 Thread Dr Paul Dale
I’d also support 11968 being merged. I find the recent discussion and the likelihood of all major distros (supporting the S390x) picking up the patches fairly compelling, especially since the same people will be maintaining it. I would need to go and double check the non-S390x specific parts

Re: Backports to 1.1.1 and what is allowed

2020-06-16 Thread Benjamin Kaduk
On Tue, Jun 16, 2020 at 02:03:58PM +0100, Matt Caswell wrote: > PR 11188 proposes to backport a series of s390x patches to the 1.1.1 > branch. IIUC it includes performance improvements as well as support for > new hardware instructions. > > I think we need to have a much clearer and more explicit

Backports to 1.1.1 and what is allowed

2020-06-16 Thread Matt Caswell
PR 11188 proposes to backport a series of s390x patches to the 1.1.1 branch. IIUC it includes performance improvements as well as support for new hardware instructions. I think we need to have a much clearer and more explicit policy about exactly what is allowed to be backported to a stable