F22 System Wide Change: Legacy implementations of the Java platform in Fedora

[Jiri Vanek]

On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote:
> I am against official guidelines or policy for legacy JDK packages. I
> don't think that any such policy is needed and it would only encourage
> adoption of old packages for which there might be no security updates.

Well thats the point - people are calling for them. And wont to maintain them with this risk.

Those rules are here to protect the rest - who dont need legacy jdk for daily useage.
>
> Of course package maintainers can agree on specific rules that apply to
> their packages, but it doesn't mean that such rules should be part of
> packaging guidelines.
>
> More details inline. My counter-proposal is at the end.
>
> On 02/24/2015 10:34 AM, Jaroslav Reznik wrote:
>> Currently Fedora supports one main Java runtime and Java Development Kit (JDK)
>> and from time to time one future JDK as a tech preview. This change should be
>> set of rules, which will enable community to maintain legacy JDKs. Please
>> note, people are bugging main JDK maintainers pretty often with this, and to
>> allow them to maintain legacy JDKs is a step in right direction.
>
> Currently anyone is allowed to maintain legacy JDKs in Fedora according
> to general rules, so this change proposal does not "enable" maintenance
> of legacy JDKs.

It is not true. We were killing old packages withut handling the owenership or maintainerships to 
others.

>
>> === Proposed rules ===
>> 0. '''Main JDK maintainers are not never ever responsible for any legacy jdk.
>> This must remain clear'''
>
> Package maintainers are responsible for their packages. If maintainer of
> "main JDK" is also maintaining "legacy JDK" then (s)he should be
> responsible for both of them. I don't see why any special rule should be
> defined.

As I higlighted - we - main jdk team - are never ever going to do so.
>
>> ==== option one - introducing new packages - preferred ====
>> 1. main jdk is proclaimed as dead as it was until now.  The new jdk is derived
>> as new package prviousName-legacy
>
> Fedora already supports multiple JDKs installable in parallel. This was
> inherited from JPackage project. This breaks long-established rule of
> naming JDK packages as "java-x.y.z-vendor" used across different
> distributions (JPackage, Fedora, RHEL, SUSE, ...)
>
>> 4. at least one of the main-jdk's members '''must''' be set as comaintainer
>> (to watch the commits and save the world if necessary)
>
> Again, I don't think we should define such rule. Package owner decides
> who can be comaintainer. I don't think we should prevent someone from
> maintaining package in Fedora just because he doesn't want "main JDK"
> maintainers to comaintain his package or enforce anyone to be
> comaintainer without his/her will. Interested parties can always
> volunteer to become comaintainers or watch for changes, report bugs and
> propose fixes or enhancements.

I do not insists on this rule. But it is the only way how to be sure the those rules are kept or to 
act quickly if something breaks.

It is actually good will of openjdk team that we are willing to do so.

I will happily give up on it.
>
>> 6. as it is generally not new package, the review process '''should''' be only
>> formal - to know maintainer and to create cvs repo
>>   1. this is quite important, otherwise the new maintainer can become really
>> frustrated, and we are forcing the "dead" package over"orpahned" so the full
>> review (especially in alignment with rule 5) really should not be forced.
>>   2. on the contrary, rules agreed here '''must''' be checked.  (even the
>> number 5)
>
> Currently all compat packages must complete full review before being
> introduced. Why JDK should be treated specially? I think that with
> complex system of virtual provides, alternatives and strict directory
> layout it's necessary to fully review "legacy JDK" package to make sure
> it doesn't conflict with primary JDK and that it is integrated with
> Fedora as expected.

Well the jdk - as is now - will never pass regular review - it is handling config files and 
libraries and shared jars really differently - and have good purposes for it.
>
>> 7. all depending packages '''must''' keep requiring java-headless or java (and
>> BuildRequires java-devel). Requirements on any exact jdk - or even worse on
>> any exact legacy jdk are forbidden and needs FESCO exception.
>
> I don't like this rule either. In some cases it may be useful or
> necessary to require specific JDK or JRE package. For example
> icedtea-web requires java-1.8.0-openjdk, which is correct and should not
> be changed.

All packages are requiring java or java-headless or java-devel. The exeptions are rare. ITW actually 
do not need this, but it making my life easier. So I will turn to java or ask for exception. In case 
of trnsition to  jdk9,  I will *not* kepp java-1.8.0-openjdk unless something terrible happens.
>
>
> As counter-proposal I recommend starting discussion within Java SIG on
> how to handle JDK deprecation. The end result could be documenting what
> was agreed somewhere on the wiki.

This one have issue to add much more work to people already taking care of openjdk and java packages 
stack. Thats something I'm definitely against (not against yours proposal, but against adding more 
worklaod to those groups - including mine and yours).
>
> I imagine the process of deprecating JDK could look like:
> 1) announce deprecation in advance and call for volunteers
> 2) if there are volunteers to maintain old JDK then handover package to
> them, discussing packaging details of the old JDK (package naming,
> provides, alternatives and so on) and possibly help with the process
> 3) if no volunteer shows up then retire old JDK package
>

Thank you for your thoughts, and sorry for disagreeing so deeply,

   J.