NB: re-sending with an e-mail adderss that isn't moderated; moderator: feel free to reject duplicate mails in the moderation queue
On Mon, Dec 04, 2023, 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. The issue is that we do not know when will be the next openssl LTS. We can safely bet there will be one before 26.04 and update to the most recent version for 24.10 (since by 26.04, the current LTS won't be supported anymore). However we can't really bet there will be one by 24.04 and even if there were, there probably wouldn't be a new one in time by 26.04. What you are asking for is equivalent to not using openssl LTS releases for Ubuntu LTS releases. There are many more non-LTS releases so we're more likely to end up with a non-LTS version. Openssl time-based releases are very very recent. This was announced late August and only one version was released under this model so far. It wasn't even on time. The delay was fairly small, especially for a first version using this model (and a change mid-cycle). I think they need a bit more time. Will they be late again? Will they continue this scheme? What else? I don't expect openssl upstream can answer these; they don't have enough hindsight yet. We talked about creating a new "openssl" package that is whatever the most recent version is (in universe, and probably with no ESM-guarantee attached somehow). This might need a bit of fiddling with packaging though and in any case, I've had absolutely no time to do that so far. Would such a package fit the needs you see? Otherwise, really, I think your question is equivalent to not using openssl LTS releases which would be a big departure from the current position. -- Adrien -- 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
