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