On Mon, 30 Jan 2023, Emmanuel Bourg wrote: > Le 2023-01-26 19:39, Thorsten Glaser a écrit : > >>> ineluctable truth: we need OpenJDK 8 back into the stable distribution. >> >> Not going to happen, sorry. This has been vetoed by the security >> team and was the condition for keeping it in unstable at all. > > Are you opposed to this idea, or just pessimistic it could be accepted?
Pessimistic. It is currently manageable to upgrade in sid and the jessie and stretch updates in ELTS are trivial. I personally also build it for wheezy and (on user request) buster, bullseye, and on a PPA for trusty/xenial/bionic/focal/jammy, so it works. I can only mildly test it, though. > I think it's important to highlight that the situation has evolved. We > thought openjdk-8 was good enough in unstable only to bootstrap Kotlin > and then move to a more recent JDK, but this isn't going to happen. Any proposal to keep openjdk-8 will want to know for how long this isn’t going to happen, i.e. at what point Kotlin &c. are expected to work with default-jdk. > Also there was an uncertainty on the lifetime of OpenJDK 8, but it's > clear now that it'll be maintained for at least two more Debian > releases. Oh, indeed? I haven’t seen the plan, but if that is so, this may be a good data point. On the other hand, the security team will not be liking having more than one implementation of something to support. Yes, documenting its unsupportedness is one thing, but if it exists… > We have invested an insane amount of time in these Kotlin/Gradle OK, I understand the frustration. > maintaining openjdk-8 in stable would require only a fraction of that. (Not to mention that it is currently I who’s maintaining that, and the ELTS people do the actual work of writing the DSA/DLAs and uploading to -security. But I’m okay with this as long as I’m not expected to upload a new version on basically the same day as its release; I took a bit longer for the 2023Q1 update due to other work-relared things having priority, but I normally do it within the week or so. On the other hand, I’m currently in the position of being able to do most of that on company time, and I’m not sure how much I want to continue this when that will no longer be true.) > The longer we wait, the more likely we are going to paint ourself in a > corner, with a completely broken and unmaintainable Gradle for What’s the status of Gradle then? I thought it required Kotlin, and we have Kotlin now, so isn’t it already using that? > example, or other elements in our tool chain that will no longer work > with OpenJDK 8 and break even more the kotlin build. To be honest, I expected that point to happen within the preceding two years already. I know I could not build Maven projects with < 11 (but targetting 8 from 11 works well now, and some of the bugs were building accidents on the Maven plugin developers’ side). > We still have some time to discuss this before the Bookworm release. Do we? We’re in the first part of the freeze already. > I suggest that we let openjdk-8 transition to testing now before the > beginning of the soft freeze, just to keep our options open. I’d like to have at least one person from the stable release managers “sign off” on that beforehand, also because it is the package maintainer who is going to be blamed. Not necessarily as a for-the-team decision, just so that at least someone is informed; the team can decide later then, if we indeed can keep the options open. > We won't expand the usage of kotlin during that time (no Gradle > upgrade for example) such that the situation remains reversible before > the release. Sounds like a plan. I’d appreciate if you could distill from this thread what has been said and contact the SRM. Once we have at least one nōn-veto response you can close #989736 so it will migrate so we have options open. It was freshly uploaded today anyway, so it’ll take some time. As a caveat, one of the MIPS platforms FTBFS’d with the previous release (they all are currently still in Needs-Build for this one). https://mail.openjdk.org/pipermail/jdk8u-dev/2022-October/015730.html is where I informed upstream about this, but I don’t know if someone has even looked at that. We’ll want to have this running on at least all release architectures if we go forward with this. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg **************************************************** /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption! ****************************************************
