BeOS Bug Database FAQs
To help explain some of the more subtle facilities of the on-line bug reports, here's a series of Frequently Asked Questions:
- How do you folks at Be classify the bugs which are submitted?
- My feature request received a "Declined Feature". Why was it declined?
- My bug is labeled "Not A Bug", but I'm pretty sure it really is a bug. What should I do?
- If my bug/feature is a duplicate, how do I find the original bug/feature submitted by someone else?
- What does Acknowledged Feature/Bug mean?
- If my bug/feature is a Fixed Bug or an Implemented Feature, does that mean that it really will appear in a future release?
- What's with that "Will Not Fix" field? You guys stink!
- 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?
- What should I do if my bug is labeled "unreproducible", but I can definitely reproduce it on my machine?
- What exactly does "Unclassified" mean?
- How is "Unclassified" different from "Reviewing Bug"?
- Has the internal procedure for bugs changed lately?
- So does that mean that the status fields of bugs displayed on the web are pretty current?
- How do you folks at Be classify the bugs which are submitted?
- How often does the web-based database get updated?
- 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?
Q: How do you folks at Be classify the bugs which are submitted?
A: Melissa Rogers has written a couple of articles on how bugs are dealt with. The Be Newsletter #34 article explains in detail the procedures we use. It's a little long in tooth in some aspects (i.e. 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. Her more recent article in Be Newsletter #105 describes the process even further.
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 PR and PR22, but it will be fixed in R3). Recently, we've been trying to mark bugs/features with "Fixed in R3" or "Implemented in R3" to provide a more accurate time frame.
Q: What's with that "Will Not Fix" field? You guys stink!
A: These are simply some things which aren't quite bugs, but which are unfortunate facts of life. They won't be "fixed". We're just trying to be honest.
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 detailed 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, reference the older bug number, 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 means that the bug/feature hasn't yet been evaluated by us or assigned to someone within Be for review.
Q: How is "Unclassified" different from "Reviewing Bug"?
A: "Reviewing Bug" means someone within Be has been assigned the task of determining the bug's validity, while "Unclassified" bugs haven't been evaluated yet. Unclear and confusing bugs/features are great candidates for staying in "Reviewing Bug" status for some time.
Q: Has the internal procedure for bugs changed lately?
A: Yes! Glad you asked. We recently integrated the developer-submitted bugs with the database that the Be engineering team uses. Developer-submitted bugs are processed much faster now; typically on a daily basis. Check back 24 hours after submitting a bug, and you'll often find it has a status field already.
Q: So does that mean that the status fields of bugs displayed on the web are pretty current?
A: Generally speaking, yes. But keep in mind that our main priority is fixing the bugs, not updating the information about them. The on-line status can lag a bit as we get closer to another BeOS release.
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.
