Re: OpenJDK 17 for bullseye-backports
[please ignore this thread started by Adrian; he's making statements on behalf
of other teams, which are not correct. Also he "forgot" to CC the security team
and the package maintainers. The issue is handled in #975016.]
On 2/6/21 11:47 PM, Emmanuel Bourg wrote:
> Le 02/02/2021 à 19:04, Adrian Bunk a écrit :
> I agree that shipping a non LTS release of OpenJDK (12 to 16) is a bad
> idea. Shipping OpenJDK 17 is worth considering though.
>
>
>> My suggestion:
>>
>> No OpenJDK other than 11 is shipped in bullseye.
>>
>> If at the time of the bullseye release openjdk-17 in unstable is ready
>> to migrate to testing except for the freeze, this means that:
>> 1. it will migrate at the first migration of bookworm, and
>> 2. the binaries will be installable on all architectures in bullseye
>>
>> The bootstrap could then be avoided by verbatim copying of this
>> openjdk-17 sources and binaries for all architectures from bookworm
>> to bullseye-backports.
>>
>> Subsequent updates of openjdk-17 in bullseye-backports would then follow
>> the normal backports rules.
>
> If openjdk-17 can't be shipped in bullseyes even with prominent warnings
> that it's unsupported, then this sounds like a good idea.
See #975016.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975016#98
lists the proposals made.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975016#123
lists the OK of the security team for all proposals.
So I'm going with option 1, preparing for an openjdk-17 in bullseye, and
preparing release notes and notes for security support. This is more
conservative than option 2, but allows to do better than the commitment made.
The option also has the advantage that approval is only needed by the security
team. openjdk-17 already is in testing. granting unblock requests for new
snapshot builds by the release team would be appreciated, but isn't strictly
necessary as long as we can build newer snapshots. And that can be checked in
unstable.
Matthias
Reply to: