Re: Backports to 1.1.1 and what is allowed

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 disrupt

Re: Backports to 1.1.1 and what is allowed

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 co

Re: Backports to 1.1.1 and what is allowed

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 ri

Re: Backports to 1.1.1 and what is allowed

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 performa

Re: Backports to 1.1.1 and what is allowed

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

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

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 issu

Re: Backports to 1.1.1 and what is allowed

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

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 ther

Re: Backports to 1.1.1 and what is allowed

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

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 asse

Re: Naming conventions

On Fri, 19 Jun 2020 09:15:22 +0200, Tomas Mraz wrote: > The problem is that there is not really fully consistent convention > followed currently (even in 1.1.1, not counting the API additions in > 3.0). > > For example if we would like to follow the convention _fully_ we would > have to rename the

Re: Naming conventions

On Fri, 2020-06-19 at 01:48 +1000, Tim Hudson wrote: > We have a convention that we mostly follow. Adding new stuff with > variations in the convention offers no benefit without also adjusting > the rest of the API. Inconsistencies really do not assist any > developer. > > Where APIs have been add