Frysk's Bugzilla - a To-Do List

All frysk's tasks (to-do items, features, change-requests, bugs) are tracked using bugzilla. They each hang off of one or more or the following Tracker Bugs.

Bugzilla Questions, With Answers

How do I submit a bug report?

Please use this form.
Before accessing the bug database you will need to create a new account.

Before submitting a new bug must I first check for an existing bug?

No.
Duplicate bug reports are helpful; for instance, when multiple people report the same bug there's a strong indicator of a more critical problem.

Should I submit JUnit test failures?

Yes.
Just one request. When submitting the bug, please use the first line of the failure as the summary (and the entire trace back in the description). Doing this makes checking for duplicates easier. For instance, given the failure:

testClone(frysk.util.TestFStack)junit.framework.AssertionFailedError:
event loop run explictly stopped (test)
   at frysk.proc.TestLib.assertRunUntilStop(TestRunner)
   at frysk.proc.TestLib.assertRunUntilStop(TestRunner)
   at frysk.util.TestFStack.testClone(TestRunner)
   at frysk.junit.Runner.runCases(TestRunner)
   at frysk.junit.Runner.runArchCases(TestRunner)
   at frysk.junit.Runner.runTestCases(TestRunner)
   at TestRunner.main(TestRunner)

The summary would be:

testClone(frysk.util.TestFStack)junit.framework.AssertionFailedError:
event loop run explictly stopped (test)

Should I submit a bug when the root-cause is likely not frysk?
(What do I do when the root-cause is either the build (Java-GNOME, GCJ) or runtime (kernel) environment?)

Yes.
If the root cause of a bug is determined to be something other than frysk, then the following action is normally taken:

• A bug report is filed against the root-cause, and cross referenced to the local bug.
• A reproducer is found, and added to frysk-imports/tests under fryskNNNN.
  PASS indicates that it must work.
  XFAIL if a work around is available.
• The local bug is SUSPENDED; when the root-cause is fixed the bug is closed.

Doing this has proven to greatly simplify the task of monitoring for regressions in frysk's build dependencies, and that is, unfortunatly, a relatively common occurance.

Why are some tracker bugs SUSPENDED?

It is a kludge.
Tracker bugs have the following lifetime:

• NEW (unassigned): An un-assigned task or goal.
• NEW (assigned) | ASSIGNED: Initial development in progress; as sub tasks are identified they are opened as blockers to the tracker bug and closed as completed
• SUSPENDED: Initial development has come to a halt (not all tasks are completed); remaining tasks and problems are identified as blockers to the tracker
• CLOSED: The issue is no longer applicable; for instance an operating system tracker would be CLOSED/WONTFIX when it's support is no longer being pursued.

When closing a bug, what should I do?

Here's a useful check list:

• Assign the bug to who ever fixed it (may not be you ;-).
• Credit others that helped with the bug (adding them to the bugzilla CC) or fix (adding them to the ChangeLog entry).
• Add the ChangeLog entry to the bug (so what was changed is easy to see)
• Close the bug.

Is there a bugzilla mailing list?

Yes.
All submitted bugzillas are sent to, and initially assigned, to the account frysk-bugzilla. See Get Involved for how to subscribe to that list.

How can I follow changes to a specific bugzilla?

Just add yourself to the bugzilla's CC list.
This is needed, since, to keep traffic down, the frysk-bugzilla@ mailing list only carries minimal information on unassigned bugs.

Should I assign a bugzilla that I am working on to myself?

Yes
If you are working on a bugzilla then assign it to yourself; and if find you are unable to continue working on a bugzilla then assign it back to frysk-bugzilla.