Page History

...

Bugs in OpenJFX are cleared by the teams daily.  It It is unlikely that a bug will remain untriaged for a long period of time but this can happen in circumstances where it is unclear where the bug should go.  Here Here is a link to the something that is sometimes called "inbox" (the untriaged bugs).  For example here is Inbox for 8u40: untriaged bugs (bugs that are in the "New" state):

https://javafx-jira.kenai.com/secure/Dashboard.jspa?selectPageId=12304bugs.openjdk.java.net/issues/?filter=23827

Triaging bugs in OpenJFX

Triaging is the process of evaluating a bug and determining when and who should work on it.  Sometimes Sometimes it is hard to determine which component is at fault or who a bug should belong to.  FortunatelyFortunately, OpenJFX has the concept of code ownership and clear responsibilities in the code base.

1. Ensure that the bug has test code and steps
   If a bug does not have enough information to recreate it, then the bug will be closed as incomplete.  There There are some exceptions to this rule, for example, the submitter reporter might already know that the bug cannot be recreated easily.  In In general, we require sample code and numbered steps before we can fix a bug.
2. Ensure that the bug has a meaningful title
   Very often, we process huge lists of bugs.  It It is very helpful if the title of the bug describes is as accurately as possible without being too long to read.  Bug Bug titles like "XXX doesn't work" require us to click on the bug every time or remember exactly what doesn't work every time we process bug lists.
3. Ensure that the following are set correctly:
   1. IssueType - <MORE HERE>Bug versus Enhancement
   2. Component/Subcomponent - <MORE HERE>
   3. Priority - <MORE HERE>
   4. FixVersion - <MORE HERE>
   5. Assignee - <MORE HERE>
   6. Key Words - <MORE HERE>
4. Perform an initial assessment
   When a bug submitter reporter provides steps and code, the bug needs to be recreated.  If If the problem does not happen, the bug may have already been fixed or the submitter reporter may be mistaken about the issue.  If If the problem does happen, then it might be a regression.  This This is quite easy to prove by running the code under older release, starting with the last update release (XuYY) and moving backward.
5. Select 'Evaluation Complete'
   This should only be done a project lead or technical lead.  It is important for project leaders to keep track which bugs are being fixed right away and which are being deferred or moved to another release.  This is especially critical during ramp down phases and milestones.
6. . If more information is needed, then "resolve" the bug as "Incomplete" and request more information from the bug reporter.
7. Press the 'Triage' button

****** OLD CONTENT ***** IN PROGRESS *******

1. Ensure that the following are set correctly:  

   IssueType 

   Component (should be javafx)

   Subcomponent Component 

   Priority (default = P4, but you may need to adjust) 

...

      This must be (for example) "Lombard9" for P1-P3 bugs.

      This can be either "9" or "tbd_major" for P4-P5 bugs.

      This can either be "tbd_major" (a good default) or "9" for Enhancements.

      During rampdown , this should be "9" for for a release, P4-P5 bugs and for all Features and Tweaksall Enhancements should go to "tbd_major" or the next release.

   Assignee (someone who will look at the bug) 

2. Select "Evaluation CompleteTriage" to indicate that the above are correct.