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.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
