Page History

A number of fields are common between the CSR issue type and normal bug/RFE issue types and between the CSR issue type and the JEP issue type. Unless otherwise noted, by default the fields in common among different issue types are used in analogous ways in each issue type with the field.

If a field has not been set, the field may not be displayed. To set such a field, when logged in hit the "Edit" button of the CSR issue.

Description: pre-populated with CSR template. The CSR template has four sections, Summary, Problem, Solution, and Specification. Follow the stated instructions on how to provide the requested information for each section.

Assignee: the engineer who is currently the person primarily responsible for advancing the proposal. The assignee may change over time as different people work on the request.

Priority: JIRA default field. Not used by the CSR process.

Labels: Free-form text

Component & Subcomponent: the technological area of the proposal; same classification scheme as used in the JDK project. If the proposal spans multiple areas, choose the area comprising the largest fraction of the proposal or break the proposal into multiple CSR issues.

Status & Resolution: State of the proposal in the CSR process. There are seven basic states captured in the Status and resolution fields:

...

• Compatibility kind: check boxes for source, binary, and behavioral. Check which kinds of compatibility are impacted by this proposal. See Kinds of Compatibility for a detailed discussion on the different kinds of compatibility.
• Compatibility risk: minimal, low, medium, high
• Compatibility risk description: Issues with a compatibility risk of low, medium, or high should usually have a release note.

...

Reviewed by: The other engineers who have reviewed the request. At least one reviewer is required. The reviewers must include one or more engineers familiar with the components being modified by the request. CSR group members may serve as reviewers, but it is not mandatory to have a CSR member as a reviewer.

Interface Kind: Java API, System or security property, Language construct, ..., add/remove command line option, ...
Check the boxes for which kinds of interfaces are affected by this requerequest.

Fix Version/s: The versions the proposal is targeted to change. For update releases, it is accepted to use one of the "pool" pseudo-release values such as "8-pool" to indicate some yet-to-be-determined release in the 8 update family. If known, a particular update release version may also be given.

Attachments: Files related to the proposal, such as webrev.zip of specdiff representing the changes. Engineers are strongly encouraged to put bug numbers  into into the file names that are attached. For example, for JDK-8123456 instead of attaching "webrev.zip" attach "8123456-webrev.zip". If the request is updated, leave any old attachments in place and attach updated versions (8123456-webrev.1.zip, etc.). The CSR members may want to compare versions of the proposals and verify requested changes were made.