...

Overview

JavaFX bug tracking will move has moved to the JDK Bug System (JBS) at https://bugs.openjdk.java.net/ on Friday, June 12. If you have an existing account in the JavaFX JIRA bug tracker, you can file a bug directly as outlined below until the transition is complete. You can learn more about JBS here.

Most application developers will file a bug at http://bugs.java.com/. After checking that your bug hasn't already been reported, you can click on the “here” link on that page to go to the bug submission form. Choose “JavaFX” as the Product/Category and then select the appropriate Subcategory, Release, and Operating System.

...

Filing a Bug

Most of this section applies whether you enter a bug via bugs.java.com or directly in JBS

...

JavaFX uses JIRA as its bug tracking database. Our JIRA instance can be found at https://javafx-jira.kenai.com/.

The most important thing you can do when entering a bug report is to ensure that the person who investigates it has enough information to recreate it.  The The best way to ensure this is to provide:

• a complete code sample (paste it in the comment section)
• a set of steps (numbered is best)

NOTE:  If If you are seeing multiple issues, please enter a bug report for each issue.  A A bug report that contains multiple independent problems can only be marked fixed when all of the problems it covers are fixed.  If If you have a single bug with what seems like many different manifestations, you can indicate this in the bug report.

...

• a screen shot of the problem
• the exception or crash log
• platform specific information (ie. "only happens on Windows")

IMPORTANT:  Bugs Bugs that are missing the information needed to recreate them will be closed as 'Incomplete'.  The message that you should take away from this is "there is more work to do before this bug can be processed" and not "we do not care that there is a problem".

JBS-Specific Information

This section mainly applies to people filing bugs or working with bugs directly on JBS, but may be of interest to application developers browsing JBS.

Project / Component

Use the Runtime (RT) project JDK Project in JIRA for FX bugs.  This This is the default.

Use the javafx Component (except for deployment or packager issues, which use the deploy Component)

Subcomponent

The javafx component is divided into subcomponents and these are used to assign default ownership of a bug report.

UPDATE THIS: Typically, many bugs are in 'controls', 'graphics', or 'base'. If you do not know the component, please make your best effort based on the component in Code Ownership.

Select the Subcomponent that most closely matches the problem you are seeing, for example controls if you have a bug relating to UI controls.

Issue Types

Issues are classified by the following types:

1. Bug - A defect.
2. Feature - New functionality or a significant upgrade to existing functionality.
3. Tweak - A minor enhancementEnhancement - A small new feature, minor improvement, optimization, re-factoring, or code cleanup. Tweaks Enhancements are usually small in scope. As a rule they should be no more than 2 weeks in duration, or else a JEP is needed (LINK TO JEP PAGE).
4. Task - A work item that does not change the repository.   Examples: baselining the PRD, open source approvals or architecture reviews. Do not use this for a bug or other enhancement. If it touches any file in the repo, it isn't a Task!
5. Sub-task - A sub item of any of the above.
6. Test - Deprecated - Do not use this issue type.
7. Optimization -  Deprecated - Do not use this issue typeBackport - A port of a bug or enhancement to another release. For example, if you push a bug fix to 9 and want to backport it to 8u60 then you create a backport for the fix to 8u60.

IMPORTANT: Many processes are different for different issue types. Unless you are a committer, submit only Bugs or Tweaks Enhancements.

More Detail About Issue Types

Features get tracked against as larger work items while Bugs and Tweaks do not.  Tests and Tasks may be allowed at times when Features, Tweaks or Bugs are restricted.  Bugs are counted in quality metrics while other types are not.  As a result it's important to get the issue type right.  Calling something a Bug rather than a Feature or calling any kind of code change a Task are the most common mistakes.

API changes are not distinguished via issue type.  Features, Tweaks and Bugs may all cause API changes.

Sub-tasks are often used by developers to break a complex issue into more manageable parts.   As such they are a convenience for the development teams.   The release team does not track at the level of sub-tasks.   To make this work, however, an issue should not have sub-tasks with different Fix For versions.   If an issue is so complex that it spans multiple releases, it should be broken into several separate issues.

Summary

The summary field should contain a very short description of the problem such that it is possible to read it and understand the area that is affected and what the symptoms are.  Phrases such as "buttons do not work" are not very helpful.  Instead, look for better descriptions like "Push button draws garbage when pressed" or "Push button fails to send callback when pressed".  

...

If you add an ad hock categorization, it might be deleted or changed later by the component owner or another committer.

Component

OpenFX is divided into components and these are used to assign default ownership of a bug report.  Typically, many bugs are in 'Controls', 'Graphics' or 'Base'.  If you do not know the component, please make your best effort based on the component in Code Ownership.  Unfortunately, the component ownership table does not quite line up with this the choice of components but this will be addressed in future.

Affects Version

This should be the version that you are running / testing in which you found the Bug.

Fix Version

If this field is present, do not set it or alter it.  This This field is for use by committers only.

Description

This is the most important part of the bug.  A bug that cannot be reproduced cannot be fixed.  In fact, committers won't make code changes without a test case that shows the problem and then shows the that problem is gone after the fix is applied.

...

//TODO - find good example in JIRA and point to it

Environment

This field is used to capture the platform where you are running.

//TODO - list environments

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Priorities

Priorities indicate the order in which issues should be resolved relative to a release.  Priority encompasses the concepts of importance and urgency.  The two concepts are highly correlated in that most of the time the worst bugs should be fixed first.  There are cases, however, when an issue might be urgent but not important or vice versa. 

...

1. If the system is functioning properly, there should be more issues at a given priority level than at the next higher level.  Think of it this way.  The purpose of priority level n is to find the important stuff out of the pile of issues at priority level n+1.  A priority level can't do that if there is little discrimination against neighboring levels.  Or put another way, if everybody is somebody then nobody's anybody.
2. The distribution of priorities should apply to future releases as well as the current release.  It is not helpful to insist that everything that is not done right away is therefore a low priority.  That just makes it hard to find the important stuff in the future.  This is why priorities are relative to a release.  (This has some limits.)
3. Priorities may change over time.  Neither importance nor urgency are immutable.
4. Priority values are under control of the Assignee.

Labels (a.k.a. keywords, tags)

In general, teams or individuals may label their issues as they see fit.   There are, however, a set of common labels that are defined project wide.  These labels should be used as defined and should not be used for other purposes.

...