BeOS Bugs On-Line

The BeOS isn't perfect.

We've been collecting bugs from developers for a long time, and now we're offering some feedback on the status of the publicly available bugs in our database. Before you dive into the bugs, please take a moment to read this document thoroughly, especially the FAQs at the bottom. Your understanding of the information provided here really will help everyone involved.

The two main goals of the Bug reporting area are:

1. Provide feedback on the status of an individual bug submitted by a developer/user.

2. Enable other users/developers to search the database of publicly available bugs in the hope that pitfalls in the BeOS can be avoided and duplicate bugs aren't submitted.

The Bug Search Form has been set up to facilitate both of these things. A specific bug can be found by searching for the bug's Bug Number (assigned when the bug was submitted).

Multiple bugs can also be found based on certain search criteria on the form. The bugs displayed using these criteria are only the publicly available bugs. Publicly available bugs are bugs which developers/users have submitted via the Bug Report Form and were declared available to the public.

Publicly available bugs can be browsed in batches of 100 at a time. The bugs submitted within the last month are also summarized on the New Bugs page.

The items of information available for each bug are as follows:

• Bug Number -- This was assigned when the bug was submitted using the Bug Report Form. The format is YYMMDD-HHMMSS, so you can also use the bug number to find out exactly when the bug was submitted.

• BeOS Version -- The version of the BeOS used when the bug was reported.

• Bug Status at Be -- The bug's status at Be. Possibilities for this status are:
  • Declined Feature - The feature request was declined.
  • Not a Bug - The "bug" submitted isn't actually a bug or we couldn't reproduce the bug here at Be.
  • Duplicate Feature - The feature requested was submitted by someone else earlier.
  • Duplicate Bug - The bug was submitted by someone else earlier.
  • Acknowledged Feature - The feature was acknowledged as one which could possibly be added.
  • Acknowledged Bug - The bug was placed in the queue for fixing.
  • Implemented Feature - The feature will be implemented in an upcoming BeOS release.
  • Fixed Bug - The bug will be fixed in an upcoming BeOS release.
  • Unreproducible - We couldn't reproduce this bug.
  • Unclassified - The bug's status has not yet been defined in the web-based bug database.

  The subtleties of these bug status levels are explained in the FAQs below.

• Short Description -- The short description of the bug which the user supplied when the bug was submitted

• Full Description -- The full description of the bug which the user supplied when the bug was submitted. The Full Description as displayed by the web site might have carriage returns in odd places; this occurs due to the nuances of displaying information over the web, and is not a result of bad spelling or strange punctuation on the part of the bug submittor.

To help explain some of the more subtle facilities of the on-line bug reports, here's a series of Frequently Asked Questions:

Q: How do you folks at Be classify the bugs which are submitted?

A: Melissa Rogers wrote a great article on how bugs are dealt with in a Be Newsletter article; it explains in detail the procedures we use. It's a little long in tooth in some aspects (i.e. our three month schedule has lengthened for DR9's major upgrades, bugs aren't slurped from the web site once a week any more but enter a database straight from the web form), but it's still pretty accurate.

Q: My feature request received a "Declined Feature". Why was it declined?

A: We receive many, many, many feature requests from our users and developers, through the Bug Report Form, the BeDevTalk and BeUserGroup mailing lists, and from the comp.sys.be heirarchy. The feature requests are summarized and reviewed in weekly meetings; some are accepted but many are declined. Unfortunately, we simply can't implement all of the features suggested to us.

Q: My bug is labeled "Not A Bug", but I'm pretty sure it really is a bug. What should I do?

A: The "bug" could be an intended feature of the system (it's a matter of perspective; often the BeOS User's Guide explains as a feature the very functionality the submittor is describing as a "bug"), pilot error, we couldn't understand what the submittor was trying to describe, or a bug in a product which we don't manufacture. If you're convinced it's a bug, describe in detail the specific steps to take to reproduce the bug on the Bug Report Form and reference the previous bug number. Our QA Team's dream is to have every bug submitted in step-by-step format describing the bug to the letter. Bugs submitted like that have a much better chance of being identified and fixed.

Q: If my bug/feature is a duplicate, how do I find the original bug/feature submitted by someone else?

A: Use the Bug Search Form and search for a string which would likely occur in someone else's description of your bug/feature. Please understand that we can't provide direct information on which bug it's a duplicate of; we're trying to concentrate on fixing new bugs.

Q: What does Acknowledged Feature/Bug mean?

A: It means that the bug/feature is in the queue for fixing or possible adoption. Acknowledged features might or might not be adopted (we'll need to evaluate it further), while we try to fix every bug before the next release.

Q: If my bug/feature is a Fixed Bug or an Implemented Feature, does that mean that it really will appear in a future release?

A: Yes. Now it's possible that the bug may re-appear when we thought we'd fixed it, that the feature somehow got dropped at the last minute, or that the entry in the database was an error. But our intent is that yes, it has been implemented/fixed. Note that the fix might not appear in the next release, but it will appear in a future release (i.e. it might not have been fixed between DR8 and DR8.2, but it will be fixed in the Preview Release).

Q: If it turns out that my bug/feature wasn't fixed/implemented in the next major release, or if I simply don't like the way my bug has been assigned, should I stomp around and complain about it?

A: Actually, the best way to go is to submit another bug report, mentioning the Bug Number in question along with a deatiled and thorough description of the bug.

Q: What should I do if my bug is labeled "unreproducible", but I can definitely reproduce it on my machine?

A: Help us reproduce the bug so that we can fix it! Fill out another Bug Report Form and include a more detailed description of your system with the exact steps you take to reproduce the bug.

Q: What exactly does "Unclassified" mean?

A: It could mean that the bug/feature is still being evaluated. Unclear and confusing bugs/features are great candidates for staying "Unclassified" for some time. But usually "Unclassified" means that the database which the web site reads from simply hasn't been updated for that bug yet. The bug/feature could already have been evaluated by the QA Team at Be, but the web database hasn't been updated yet.

Q: Does Be's QA Team focus mainly on updating this web-based database or fixing bugs?

A: Fixing bugs, by far. The QA Team tries to break the BeOS in every way possible; this is done both for the current BeOS version using bug reports submitted from users and developers, and the next BeOS version as it's readied for release. The QA Team has done an outstanding job in providing the information here; they've already worked long hours updating the web-based bug database. But their main focus is breaking the BeOS.

Q: So does that mean that the bugs displayed on the web might not have the most up-to-date status labels?

A: Yes. Hopefully the information about bugs which have already been submitted will prove to be the most helpful aspect of the web-based bug database. Some people will inevitably want word-for-word descriptions of everything said or implied about their bug/feature here at Be along with why it was or wasn't adopted and what is being done about it and who tested it when; we simply don't have the resources to support an undertaking like that and make it publicly available.

Q: I noticed that when I do a search for a string in the Short and Full Description that some of the bugs which the search engine finds don't have any bold (matching) words. Why is that?

A: It means that words in the Full Description matched the search criteria. Since the Full Description isn't displayed in the search results, no bold-faced words will appear for that entry.

Q: How often does the web-based database get updated?

A: Information gets uploaded every night.

Q: Does this mean that my newly submitted, publicly available bugs won't be browsable for 24 hours?

A: Yes.

Q: I can find my bug using the Bug Search Form and my bug Number, but it doesn't appear in the search I perform using a string I know is in my Full/Short Description. Why doesn't it show up?

A: Your bug probably isn't publicly available; the search engine only searches the publicly available bugs. The Bug Report Form has a checkbox to make bugs publicly available; if it wasn't checked (or this wasn't available on the form at the time you submitted the bug), your bug isn't publicly available. We did this so that source code submitted wouldn't become publicly available unless the submittor decreed it so.

Q: Is there a way to go back and make my bugs publicly available?

A: The next time you submit a bug you could check the "Make all previously submitted bugs available to the world" checkbox.

So, in summary, you can view the bugs via a few different methods:

• Search for a specific bug using a Bug Number on the Bug Search Form
• Search for all the bugs which match a set of search criteria on the Bug Search Form
• Browse summaries of the New Bugs
• Browse the bugs available in sets of 100 at a time.

As always, we encourage you to submit the bugs you encounter to us using the Bug Report Form. Happy hunting!