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!
****************************************************
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)