|Discussion||discuss at openjdk dot java dot net|
Extend the JEP Process to cover the creation and maintenance of the set of features intended for delivery in a JDK Release Project, the tracking of the development status of each feature, and the scheduling of releases themselves. Ensure that the revised process can also be used to track work that is of broad interest but not targeted to a specific release. The process may be used by other Projects as they see fit.
We use the current JEP Process to collect, review, sort, and evaluate proposals for enhancements to the JDK. The ongoing result of this process is the JDK Roadmap, a collection of feature ideas and other proposals for consideration by JDK Release Projects and related efforts. The Roadmap is intended to extend at least three years into the future so as to allow sufficient time for the most complex proposals to be investigated, defined, and implemented.
The JEP Process also records the targeting of Feature JEPs to particular releases, but it says nothing about how we make targeting decisions, how feature work is tracked as a release progresses, or how a release’s overall schedule is created and maintained.
We also use the JEP Process to document work that is not associated with a particular release, such as forward-looking research or improvements to our processes and infrastructure. The JEP Process currently does nothing to track the status of such efforts.
This proposal aims to fill these gaps. The existing goals of the JEP Process will not change, nor will its current guidance on making decisions and building consensus, even around wacky ideas. The state model and the proposal format, however, will be revised.
If this proposal is adopted then the end result will be new versions of JEP 1 and JEP 2.
At a high level, the planning part of the revised JEP Process is concerned with the set of features targeted to a release being developed in a specific OpenJDK Project, and with the schedule of the release itself. It works as follows:
Any Committer to a Project may propose to target a Feature JEP to a release of that Project after documenting a realistic engineering plan. The proposer should be the JEP’s owner, or arrange to become the owner.
The owner of a targeted JEP may later propose to drop that JEP from its targeted release.
The Project’s Lead may propose an initial release schedule, and thereafter propose changes to that schedule.
Proposed changes to the feature set and schedule of a release are approved by rough consensus of the Committers to the Project, as determined by the Project Lead. Any particular proposal must be open for discussion for at least one calendar week, major holidays excepted.
NOTE: Per the Bylaws, every Reviewer of a Project is also a Committer to that Project.
Once a Feature JEP is targeted to a release, we need a way to track progress on its development. We will leverage the JDK Bug System (JBS) for this purpose by introducing a new “JEP” issue type. JEP issues will replace the current Mercurial repository of JEP documents, and eventually all existing JEPs will be moved into JBS.
Non-Feature JEPs, of type Infrastructure, Informational, and Process, will also be tracked in this way.
Release schedules will not be tracked in JBS. Project Leads are expected to document release schedules on appropriate Project-related web or wiki pages.
JEP issues in JBS will have the standard JIRA fields, with the following
interpretations relative to JEP 1.0 terminology. Fields preceded
+‘ must not be empty.
JBS JEP 1.0 ---------------------------------- ---------------------------- +Summary: <text> Title +Assignee: <Committer name> Owner +Reporter: <user name> Original author +Created: <date> Created +Updated: <date> Updated +Type: JEP n/a Priority: <priority> NEW (see below) Component/s: <component> Component Labels: <labels> NEW +Status: <status> State (roughly) Resolution: <resolution> NEW (when status = Closed) Fix Version/s: <version> Release Due Date: <date> NEW
(Some of the JBS field names are less than ideal but they are, sadly, not easily customizable.)
JEP issues will, additionally, have some custom fields:
JBS JEP 1.0 ---------------------------------- ---------------------------- +Author: <name> Author JEP number: [0-9]+ JEP +JEP Type: Feature Type | Infrastructure | Informational | Process +Exposure: Open | Closed Exposure Subcomponent: <subcomp> Component Scope: SE | JDK Scope (must be non-empty | Implementation in Feature JEPs) JSR: [0-9]+( MR)? JSR +Discussion: <mailing list> Discussion Effort: XS | S | M | L | XL Effort Duration: XS | S | M | L | XL Duration Reviewed By: <Reviewer names> Reviewed-by Endorsed By: <endorser names> Endorsed-by Integration Due Date: <date> NEW Alert Status: Green | Yellow | Red NEW Alert Date: <date> NEW Alert Reason: <text> NEW
The JBS fields that are new relative to the JEP 1.0 template are interpreted as follows:
Priority — The suggested or, later, agreed priority of this JEP
Labels — Free-form text labels, as in any other JBS issue
Resolution — When a JEP is Closed this will be one of Withdrawn, Rejected, or Delivered (see more below)
Integration Due Date — The date by which the JEP is expected to reach the Integrated state (see below)
Due Date — The date by which the JEP is expected to reach the Complete state (see below)
Alert Status, Date, and Reason — These are used to report on the work underway for the JEP, with the Status color meaning:
Green: All is well
Yellow: Plan at risk, but a credible plan is in place to mitigate that risk
Red: Plan at serious risk, with no plan to mitigate that risk
The owner of a Feature JEP is expected to update the Alert Status and Date on a bi-weekly basis after the JEP is targeted to a specific release. To indicate that the Alert Status is up-to-date, simply set the Alert Date to the current date. If the Alert Status is Yellow or Red then the owner should use the Alert Reason field to explain what is required to return the Status to Green, and should update the Alert Status on a weekly basis until it returns to Green. This way everyone working on the release or otherwise interested in the JEP can easily understand its current state.
Further differences relative to the JEP 1.0 template:
There is no longer a “Research” JEP type. Long-term research work toward a potential feature can be tracked as one or more subtasks of a Feature JEP.
The Author field is used to record the original author of the JEP. It’s a free-form text field, since the original author might not have a username in JBS.
To align with JBS, JEPs will adopt the JBS component/sub-component ontology.
The RFE, Depends, and Blocks headers in the JEP 1.0 template are no longer needed, since a JEP issue in JBS can link directly to related Bug, Enhancement, or JEP issues.
The Internal-refs header of the JEP 1.0 template is no longer needed, since such references can be recorded in JBS labels or comments.
The Start, Organization, Funded-by, and Target headers in the JEP 1.0 template will not have direct replacements in JBS.
The Component or Subcomponent fields of a JEP issue may be empty in the case of a feature that affects multiple components or subcomponents.
The Description field of a JEP issue will contain the body text of the JEP. It will be written in Markdown format, as before, and JBS will render it in appropriate HTML. The structure of the body text will not change except that the Impact section will be removed; this section has proved to be of limited value over the years, and there are better ways (e.g., a FAQ) to encourage JEP owners to analyze and document the impact of a JEP.
The revised JEP Process has the following states and transitions for Feature and Infrastructure JEPs:
A JEP will, most often, move through the sequence of states connected by dark blue edges; light blue edges represent less-common transitions, discussed further below.
The first three states for a Feature or Infrastructure JEP are:
Draft — Initial state in which the JEP is drafted, reviewed, revised, and endorsed
Submitted — By the JEP’s owner, declaring the JEP ready to be evaluated for the JDK Roadmap
Candidate — By the OpenJDK Lead, to add the JEP to the JDK Roadmap
A JEP in the Candidate state is merely an idea worthy of consideration by JDK Release Projects and related efforts; there is no commitment that it will be delivered in any particular release.
A JEP will be assigned a JEP number, distinct from its JBS issue key, the first time it enters the Candidate state. This is for convenience of reference, and for continuity with the set of JEPs created in the JEP 1.0 process.
From this point onward a Feature JEP will, most often, move through these states:
Proposed to Target — By the JEP’s owner, for a specific release, after a credible engineering plan is documented in subtasks of the JEP issue
Targeted — By the Project Lead, after evaluating the JEP’s engineering plan and seeing rough consensus amongst the Committers and Reviewers of the Project
Integrated — By the JEP’s owner, after code and unit tests are integrated into the master code base
Complete — By the JEP’s owner, after functional, performance, and conformance tests have been delivered and the feature has reached the point where only bug fixes are expected
Closed/Delivered — By the Project Lead, when the release ships
The engineering plan documented in subtasks of a Feature JEP should include, but is not limited to, design, implementation, test development (unit, functional, performance, and conformance), and documentation. The assignee of each subtask is considered responsible for completing that subtask.
The Priority, Fix Version, Integration Due Date, and Due Date fields must not be empty in the Proposed-to-Target state or any later state. After a JEP is Targeted, only the Project Lead may modify the Priority and Fix Version fields.
A release, as a whole, is considered Feature Complete only after all of its Feature JEPs reach the Complete state.
Sometimes a JEP will not proceed smoothly from Draft to Closed/Delivered.
If a JEP is submitted prematurely then the JEP’s owner can move it from Submitted back to Draft.
If the OpenJDK Lead determines that a Submitted JEP is not ready to enter the Candidate state, or that a Candidate JEP is no longer suitable for the JDK Roadmap, then the OpenJDK Lead will move it back to Draft.
The OpenJDK Lead can move a JEP from Submitted or Candidate to
to indicate that the JEP is not worth pursuing, or is so unlikely ever to be targeted that it’s not worth maintaining in the Roadmap.
If a JEP is moved to Proposed-to-Target prematurely then the JEP’s owner can move it back to Candidate.
If a JEP in the Draft, Submitted, Candidate, or Proposed-to-Target state is to be withdrawn because no further work on it will be done then the JEP’s owner can move it to
If the JEP is later revived then the owner can move it from Closed/Withdrawn back to Draft.
If a proposal to target a JEP to a specific release is not accepted then the Project Lead will move it back to Candidate.
If the owner of a Targeted JEP, or the relevant Project Lead, wishes to drop the JEP from the targeted release then that person can move the JEP to
in which case the Project Lead will either move the JEP back to the Candidate state, if the drop proposal is accepted, or else revert the JEP to its previous state. If the JEP is moved back to Candidate then its Fix Version, Integration Due Date, and Due Date fields will be cleared.
If a JEP is moved to Integrated prematurely then the owner can move it back to Targeted. If a JEP is moved to Complete prematurely then the owner can move it back to Integrated.
Some Infrastructure JEPs will never be targeted to a specific release, so the owner of an Infrastructure JEP can move it forward from Candidate to Closed/Delivered when work on the JEP is complete.
The states and transitions for Informational and Process JEPs are simpler:
An Active JEP is one whose information or process is currently relevant to the OpenJDK Community.
Minor revisions to an Active Informational or Process JEP may be made after appropriate discussion and review. Major revisions should be proposed and discussed in a separate JEP of the same type. The new JEP may then supersede the original, which should be moved to Closed/Withdrawn, or else the original may be updated in place, in which case the new JEP should be moved to Closed/Delivered.
Informational and Process JEPs need not adhere strictly to the standard JEP body template.
All existing JEPs in the Mercurial archive will be moved into JBS some time after this revised JEP Process is rolled out. Authors of JEPs submitted but not yet posted will be asked to re-draft them in JBS.
We’ll take this opportunity to make two unrelated changes to the JEP Process:
JEP authors will be required only to be Contributors, not Committers. If a JEP’s original author is not even an Author in some OpenJDK Project then that person must find an Author (or Committer or Reviewer) to draft the JEP in JBS. It will remain the case that only a Committer can submit a JEP.
Create a new mailing list where large, cross-component JEPs with deep impact to the platform can be discussed until such time as they have Project-specific mailing lists.