On 2023-12-04 04:05, Dimitri John Ledkov wrote:
Hi,

On Fri, 20 Oct 2023 at 15:35, Adrien Nader <adr...@notk.org> wrote:

On Fri, Oct 20, 2023, Adrien Nader wrote:
Hi,

A few weeks ago, openssl maintainers announced moving to a time-based
release (April and October):

https://www.openssl.org/blog/blog/2023/09/29/OpenSSL-Update-ICMC23/

Key takeaway 3 : Time Based Release Policy
We’re transitioning to time-based releases. This shift ensures
predictability, allowing our users and developers to plan better and
benefit from timely updates. The releases will be scheduled every
April and October.

Based on this and the openssl 3.0 release date, I'd expect a new LTS
version to be released (almost) in time for 26.04 but not for 24.04.

*IF* an openssl LTS release is out in April 26.04, we might want to
track the corresponding openssl git branch during the 26.04 release in
order to be able to ship it. This is more than two years away however
and a lot can happen until then. I don't have a crystal ball
unfortunately. In any case, we'll know if the planned and the actual
release cadence and calendar match.

Dimitri asked me for some more details so I dug a bit more. It's
actually better explained in a better blog post from late August:

https://www.openssl.org/blog/blog/2023/08/27/steps-forward

We’re also shifting how we release the OpenSSL library. We’ve adopted
a time-based release policy, with releases every April and October.
After our 3.2 release in October, our 3.3 release in April next year
will be our first time-based release, marking our initial venture into
this approach.

And the release policy has been updated too:

https://www.openssl.org/policies/general/release-policy.html

Planning: Continuous process, provides input to the Release Definition phase.
Release Definition: Defines release backlog, lasts up to 4 weeks.
Development: Execution of the release backlog, spans from 20 to 24 weeks.
Release: Addressing issues discovered by the community in pre-releases. Up to 6 
weeks.
Support: A support phase.

If they follow their plan, we'd therefore have pre-release versions
several weeks before Ubuntu releases. Of course, feature freeze
concerns apply if the pre-release isn't out in time.

That's all I've seen so far (OK, I didn't dig that much). We'll see very
soon how that turns out in practice for the 3.2 release.

With every other major piece of our dependencies, we have committed to
picking up regular time based releases which fit our schedule.
This includes things like GNOME, KDE, OpenStack, GCC.
I think we should commit to picking up the latest OpenSSL for every
Ubuntu release going forward.
3.2 has been released, albeit in late November, and we should show
good will and encourage OpenSSL to stick to their new time based
releases.

Can we please start the upgrade of OpenSSL to 3.2?

And then if OpenSSL 3.3 is released in early April, pick that up as
well for 24.04. If the new cadence for 3.3 means May, pick it up for
the 24.10 instead.


Please don't ship the next LTS release with a non-LTS version of OpenSSL. Maintaining security updates to OpenSSL is difficult enough as it is. It would be even more difficult to do so with a throw-away version that no other distro is going to maintain long-term. The only way this works is if we use the same version as others so we can collaborate on updates.

Marc.


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Reply via email to