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 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 need to do it sooner rather than later!
> >
> > This seems a job for the OMC, as it falls under:
> >
> >> makes all decisions regarding management and strategic direction of the
> project; including:
> >> - business requirements;
> >> - feature requirements;
> >> - platform requirements;
> >> - roadmap requirements and priority;
> >> - end-of-life decisions;
> >> - release timing and requirement decisions;
> >
> > My contribution to the discussion is to ask if the OMC has plans for
> > addressing this in the very short term.
>
> I think its unlikely we are going to get to a policy in the short term.
> It seems to me we are still some way away from a consensus here.
>
> > If working on a policy is going to be a medium-term effort, maybe it
> > would be opportune to call an OTC vote specific to #11968 under the
> > current release requirements defined by the OMC (or lack thereof).
>
> 11968 is already merged and, AFAIK, no one has proposed reverting it. If
> such a PR was raised then a vote might be a way forward for it.
>
> 11188 is the more pressing problem because that is currently unmerged
> and stuck. That has an OTC hold on it (placed there by me), so an OTC
> vote seems appropriate. If a vote is held it should be to decide whether
> backporting it is consistent with our current understanding of the
> policy such as it is. It is for the OMC to decide whether a different
> policy should be introduced at some point in the future.
>
> Matt
>
>
> >
> > We already saw a few comments in favor of evaluating backporting
> > #11968 as an exception, in light of the supporting arguments, even if
> > it was in conflict with the current policy understanding or the
> > upcoming policy formulation.
> > So if we could swiftly agree on this being an OTC or OMC vote, I would
> > urge to have a dedicated discussion/vote specific to #11968, while
> > more detailed policies and definitions are in the process of being
> > formulated.
> >
> > - What is the consensus on splitting the 2 discussions?
> > - If splitting the discussions, is deciding on #11968 an OTC or OMC
> matter?
> >
> >
> >
> > Cheers,
> >
> > Nicola
> >
>


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 the longer support timeframe),
> but also highlights a need to do it sooner rather than later!
> 
> This seems a job for the OMC, as it falls under:
> 
>> makes all decisions regarding management and strategic direction of the 
>> project; including:
>> - business requirements;
>> - feature requirements;
>> - platform requirements;
>> - roadmap requirements and priority;
>> - end-of-life decisions;
>> - release timing and requirement decisions;
> 
> My contribution to the discussion is to ask if the OMC has plans for
> addressing this in the very short term.

I think its unlikely we are going to get to a policy in the short term.
It seems to me we are still some way away from a consensus here.

> If working on a policy is going to be a medium-term effort, maybe it
> would be opportune to call an OTC vote specific to #11968 under the
> current release requirements defined by the OMC (or lack thereof).

11968 is already merged and, AFAIK, no one has proposed reverting it. If
such a PR was raised then a vote might be a way forward for it.

11188 is the more pressing problem because that is currently unmerged
and stuck. That has an OTC hold on it (placed there by me), so an OTC
vote seems appropriate. If a vote is held it should be to decide whether
backporting it is consistent with our current understanding of the
policy such as it is. It is for the OMC to decide whether a different
policy should be introduced at some point in the future.

Matt


> 
> We already saw a few comments in favor of evaluating backporting
> #11968 as an exception, in light of the supporting arguments, even if
> it was in conflict with the current policy understanding or the
> upcoming policy formulation.
> So if we could swiftly agree on this being an OTC or OMC vote, I would
> urge to have a dedicated discussion/vote specific to #11968, while
> more detailed policies and definitions are in the process of being
> formulated.
> 
> - What is the consensus on splitting the 2 discussions?
> - If splitting the discussions, is deciding on #11968 an OTC or OMC matter?
> 
> 
> 
> Cheers,
> 
> Nicola
> 


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 changes?

In my opinion that would open a can of worms. Such branch would
inevitably mean there will be request for the 1.1.2 release and I do
not think it would be a good idea to have it. It would seriously
stretch the team resources IMHO.

It would be much better to have the rules not tightened for 1.1.1 right
now (i.e. still allow for example the performance improvements and
support for newer hardware) and tighten them only after the 3.0 release
is final.

Still, I do not think allowing any truly new features other than the
performance and HW support on 1.1.1 is worth it.

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




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 need to do it sooner rather than later!

This seems a job for the OMC, as it falls under:

> makes all decisions regarding management and strategic direction of the 
> project; including:
> - business requirements;
> - feature requirements;
> - platform requirements;
> - roadmap requirements and priority;
> - end-of-life decisions;
> - release timing and requirement decisions;

My contribution to the discussion is to ask if the OMC has plans for
addressing this in the very short term.
If working on a policy is going to be a medium-term effort, maybe it
would be opportune to call an OTC vote specific to #11968 under the
current release requirements defined by the OMC (or lack thereof).

We already saw a few comments in favor of evaluating backporting
#11968 as an exception, in light of the supporting arguments, even if
it was in conflict with the current policy understanding or the
upcoming policy formulation.
So if we could swiftly agree on this being an OTC or OMC vote, I would
urge to have a dedicated discussion/vote specific to #11968, while
more detailed policies and definitions are in the process of being
formulated.

- What is the consensus on splitting the 2 discussions?
- If splitting the discussions, is deciding on #11968 an OTC or OMC matter?



Cheers,

Nicola


OpenSSL version 3.0.0-alpha4 published

2020-06-25 Thread OpenSSL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 3.0 alpha 4 released
   

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   OpenSSL 3.0 is currently in alpha.

   OpenSSL 3.0 alpha 4 has now been made available.

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well
   as known issues are available on the OpenSSL Wiki, here:

https://wiki.openssl.org/index.php/OpenSSL_3.0

   The alpha release is available for download via HTTPS and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-3.0.0-alpha4.tar.gz
  Size: 13884897
  SHA1 checksum:  056194ea4ec57234ce3cb16b944d99c4d2a8b650
  SHA256 checksum:  
d930b650e0899f5baca8b80c50e7401620c129fef6c50198400999776a39bd37

   The checksums were calculated using the following commands:

openssl sha1 openssl-3.0.0-alpha4.tar.gz
openssl sha256 openssl-3.0.0-alpha4.tar.gz

   Please download and check this alpha release as soon as possible.
   To report a bug, open an issue on GitHub:

https://github.com/openssl/openssl/issues

   Please check the release notes and mailing lists to avoid duplicate
   reports of known issues. (Of course, the source is also available
   on GitHub.)

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl70rYcACgkQ2cTSbQ5g
RJFWeAf/ZOGaHZbcAUy9Xm/R8x56qPJWD+3D8qGOgjNgKc/5r3kXII3I7NH7lc1j
zFSt/FA9NhqU7dIh/8/SlyZaBbFW/XZBRiczDqRSqAkAfsxhlj5tOq8xZoXuTqlN
it3DICC96jgh2xGo3LJUPgY1o0evsPLX98L/BtRZcZMcZed0ImZEEmJra3vEDr7H
C+Hu4/+gNDlAISDENSDygAE8vDB5hBDmk0YCySPKZpDbWPdV2/WF8oBlgRpNBjY+
zbk/V32xZkhf/x/nhRGNs44CJI8ymsDtp6UyV2e7ZW6LZNMGX7l0M8ZuJvLTFJJM
ZqQo7Xhn1EFdIRwTd+B2CvY2k73Pzw==
=khAk
-END PGP SIGNATURE-