OMC Vote: Change some words by accepting PR#12089
topic: Change some words by accepting PR#12089 Proposed by Mark Cox Public: yes opened: 2020-06-25
Re: Backports to 1.1.1 and what is allowed
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
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
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
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
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
-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-
