< Changes
(→Scope) |
(A few changes to fullfil formal requirements) |
||
| Line 90: | Line 90: | ||
== Scope == | == Scope == | ||
* Proposal owners | * Proposal owners: are responsible for initial setup of those guidelines. | ||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
The FESCO, the owners and pssible legacy JDKs maintainers have to agree on those rules. New legacy JDK can be then added anytime in Fedora lifecycle. | The FESCO, the owners and pssible legacy JDKs maintainers have to agree on those rules. New legacy JDK can be then added anytime in Fedora lifecycle. | ||
| Line 108: | Line 108: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
== How To Test == | == How To Test == | ||
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. | <!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. | ||
| Line 131: | Line 129: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
== User Experience == | == User Experience == | ||
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | <!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --> | ||
Revision as of 09:18, 24 February 2015
Legacy implementations of the Java platform in Fedora
Summary
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.
Owner
- Name: Jiri Vanek
- Email: jvanek@redhat.com
- #fedora-java
- #fedora-devel
- Release notes owner:
- FESCo shepherd: Would_Be_Nice_To_Have
Current status
- Targeted release: Fedora 22
- Last updated: 2014-02-23
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
This is no real work proposal. The result of this proposal is set of rules, which will allow community maintainers to pack any legacy jdk and will be ensuring that this JDKs will not conflict by any other JDK and will smoothly integrate to system. The results are summarized here, and pledged for discussion until final resolution is done.
Proposed rules
0. Main JDK maintainers are not never ever responsible for any legacy jdk. This must remain clear
option one - introducing new packages - preferred
- main jdk is proclaimed as dead as it was until now. The new jdk is derived as new package prviousName-legacy
- so from killed java-1.7.0-openjdk will become new package java-1.7.0-openjdk-legacy
- next main jdk do Obsolete previous one as usually
- new package must not do any virtual provides (aka java,java-devel)... (protection against random pull by as dependence)
- it provides only itself by name
- its priority must be kept on less digits (right now it would be 5) then main jdk (protection against winning in alternatives after update)
- the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084 are mandatory
- at least one of the main-jdk's members must be set as comaintainer (to watch the commits and save the world if necessary)
- new package should to follow both original jdk (ideally not change at all (except source updates and necessary)) and current main jdk as close as possibly
- here it requires some common sense and a lot of testing if integration with system is as expected
- as it is generally not new package, the review process should be only formal - to know maintainer and to create cvs repo
- 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.
- on the contrary, rules agreed here must be checked. (even the number 5)
- 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.
This option is forcing maintainers to fight with the name x current setup of alternatives. However, the work should be minimal. But it makes the update path pretty clear and it keeps users well protected against legacy jdk.
option two - orphaning legacy jdks and ensure update path
- main JDK is only orphaned when new main JDK landed
- it do not Obsolate previous jdk
- other rules (2-7) are same
This is making life of legacy JDK maintainers a bit simpler. But I don't know, how to ensure proper "obsolete" implementation in this case.
Benefit to Fedora
There do exists products being developed in Fedora, but targeted for third party. Those products may be targeted for different then Fedora's main JDK. Also there exists out of repo java applications which are bound to older JDK version. To make development of such a product more simple or running of those bounded apps easier, to have legacy JDKs directly in Fedora would be nice
Scope
- Proposal owners: are responsible for initial setup of those guidelines.
The FESCO, the owners and pssible legacy JDKs maintainers have to agree on those rules. New legacy JDK can be then added anytime in Fedora lifecycle.
- Other developers: no developers
- Release engineering: in ideal case, no release engineer needed
- Policies and guidelines: The proposal may split to proposal and "Legacy JDKs in Fedora guidelines" pages
Upgrade/compatibility impact
The result of this proposal should ensure, that upgrading users will not be non-volunteerly affected by legacy jdk
How To Test
not interested user
- if you will not notice existence of legacy jdk in koji, the test passed
interested user
- If you are able to install any legacy JDK by simple yum, and it works for you, then the test passed
User Experience
not interested user
- update of Fedora will not keep legacy jdk on your system, or at least it will not be set as default
- operations with packages will not lead to accidental install of legacy jdk (at least easily)
- you will be able to remove legacy jdk without any complications
- the packages stack will be run by main jdk
interested user
- is able to install legacy jdks without any complications
- is able to use them (also in parallel with regular one)
- the packages stack will be run by main jdk (but not obligatory without manual interference)
- you are able to use the legacy jdk for your work
Dependencies
- No current package should depend on this proposal
- future legacy JDKS are all depending on the result of proposal
- packages which may depend on legacy jdk may appear in future, but have to attend
Contingency Plan
- Contingency mechanism: The legacy JDKs must follow here agreed rules. Theirs not keeping may lead to ban package. However the existence of legacy JDK is not condition for existence of those rules. So no legacy jdk is also an success. Main JDK maintainers are not never ever responsible for any legacy jdk. This must remian clear
- Contingency deadline: Beta freeze
- Blocks release? NO
- Blocks product? NO
Documentation
This proposal itself is an documentation, unless it is split to proposal and guideline.
Release Notes
Release notes should be mentioning, that any legacy jdk which is coming with this Fedora is subject of those conditions.