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

[Mikolaj Izdebski]

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.

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.

> === 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.

> ==== 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.

> 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.

> 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.


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.

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

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk