Difference between revisions of "Bugzilla Help"
Line 44: | Line 44: | ||
For bugs in SME Server Release, SME Server Future & SME Server Translations the following format is suggested. It's not always appropriate eg. New Feature Requests | For bugs in SME Server Release, SME Server Future & SME Server Translations the following format is suggested. It's not always appropriate eg. New Feature Requests | ||
− | When reporting a new bug, and after choosing the platform, the next screen asks for more details on your problem. There are 4 main fields that need to be completed. These are '''Component,''' '''Found-In-Version,''' '''Summary,''' and '''Description.''' Fields such as '''Flags''' and '''Requestee''' should be left blank initially by most reporters. The '''CC''' field is for other people you would like notices on this issue to be sent to. YOU will always be automatically included by default, so you don't need to 'cc' yourself. | + | When reporting a new bug, and after choosing the platform, the next screen asks for more details on your problem. There are 4 main fields that need to be completed. These are '''Component,''' '''Found-In-Version,''' '''Summary,''' and '''Description.''' Fields such as '''Flags''' and '''Requestee''' should be left blank initially by most reporters. The '''CC''' field is for other people you would like notices on this issue to be sent to. YOU will always be automatically included by default, so you don't need to 'cc' yourself. The '''Attachment''' button at the bottom of the page is used to attach additional file information such as log files that may be helpful. |
'''Component:''' As accurately as possible, you may choose which category your issue fits into. If Unknown then choose UNKNOWN. | '''Component:''' As accurately as possible, you may choose which category your issue fits into. If Unknown then choose UNKNOWN. | ||
Line 57: | Line 57: | ||
'''Description:''' Present the details of your problem in this section. You may use the following as a template: | '''Description:''' Present the details of your problem in this section. You may use the following as a template: | ||
− | '''ENVIRONMENT''': | + | '''ENVIRONMENT''': '''''Give a brief server history''''' |
eg. SME Server 7.1, Updated to 7.3 with yum | eg. SME Server 7.1, Updated to 7.3 with yum | ||
− | '''MODIFICATIONS''': | + | '''MODIFICATIONS''': '''''List any contribs or modifications you have on the server''''' |
eg. If the following produce any output, attach the results (don't post inline) | eg. If the following produce any output, attach the results (don't post inline) | ||
Line 69: | Line 69: | ||
'''''or say''''', no custom-templates or contribs. | '''''or say''''', no custom-templates or contribs. | ||
− | '''ORIGINAL PROBLEM''': | + | '''ORIGINAL PROBLEM''': '''''State what you were trying to do.''''' |
− | '''STEPS TO REPRODUCE''': | + | '''STEPS TO REPRODUCE''': '''''As accurately and exactly as possible state what you did to get your problem.''''' |
− | '''ACTUAL RESULTS''': | + | '''ACTUAL RESULTS''': '''''List what you got as a result.''''' |
− | '''EXPECTED RESULTS''': | + | '''EXPECTED RESULTS''': '''''List what you expected to happen.''''' |
+ | |||
+ | '''Attachment:''' This is used to attach (not post in line) any logs or results of command line queries such as the examples listed in "Modifications" above. | ||
+ | |||
+ | Finally, when satisfied with your entries, submit your bug report by pressing the '''COMMIT''' button. | ||
===Verifying Bugs=== | ===Verifying Bugs=== |
Revision as of 22:58, 26 February 2009
Bug Tracker
Please help us to make our software as reliable as possible. Please report possible bugs only via the bug tracker and to encourage others to do the same.
Bugzilla is just a standard communication format for problem solving. Replies may seem abrupt but that is just the nature of the medium. Don't be concerned by a stark Wontfix or Invalid, it's how the system works. Discussions are for forums
Find, report and fix bugs here http://bugs.contribs.org
Bugzilla is easy
A frequent complaint is Bugzilla is too hard or convoluted, but it is hard to justify.
- You open an account
- Then report your problem
SME is run by volunteers so we expect you to help by searching for existing bugs and by filing your bug in the format described below. To begin you need only read 'searching' and 'reporting'.
Searching Bugs
Have you searched bugzilla, and read the SME Server Manual and FAQ ?
Simple and Advanced aren't necessarily easy so we added prepared searches to the bugzilla page headers.
- Simple
Select a Status and a Product category and enter your search term
- Advanced
You can restrict searches by using a selection or multiple selections of a category
Use Control Click to select/deselect from selection sets, if none are selected all are.
- Reports
A wiki page with more prepared searches.
- Matrix
A Grid with one view of current bugs, more are available in Reports.
- Recent
Bugs with activity in the last two days
Reporting Bugs
Please take the time to read How to report bugs effectively (available in multiple languages)
For bugs in SME Server Release, SME Server Future & SME Server Translations the following format is suggested. It's not always appropriate eg. New Feature Requests
When reporting a new bug, and after choosing the platform, the next screen asks for more details on your problem. There are 4 main fields that need to be completed. These are Component, Found-In-Version, Summary, and Description. Fields such as Flags and Requestee should be left blank initially by most reporters. The CC field is for other people you would like notices on this issue to be sent to. YOU will always be automatically included by default, so you don't need to 'cc' yourself. The Attachment button at the bottom of the page is used to attach additional file information such as log files that may be helpful.
Component: As accurately as possible, you may choose which category your issue fits into. If Unknown then choose UNKNOWN.
Found-in-version: Usually self explanatory. If it applies to more than one version, choose the most recent stable release.
Summary: How would you describe the bug. BE BRIEF. A good summary should quickly and uniquely identify a bug report. It should explain the problem, not your suggested solution.
- Good: "Canceling a File Copy dialog crashes File Manager"
- Bad: "Software crashes"
- Bad: "Browser should work with my web site"
Description: Present the details of your problem in this section. You may use the following as a template:
ENVIRONMENT: Give a brief server history eg. SME Server 7.1, Updated to 7.3 with yum MODIFICATIONS: List any contribs or modifications you have on the server eg. If the following produce any output, attach the results (don't post inline) /sbin/e-smith/audittools/templates /sbin/e-smith/audittools/newrpms or say, no custom-templates or contribs. ORIGINAL PROBLEM: State what you were trying to do. STEPS TO REPRODUCE: As accurately and exactly as possible state what you did to get your problem. ACTUAL RESULTS: List what you got as a result. EXPECTED RESULTS: List what you expected to happen.
Attachment: This is used to attach (not post in line) any logs or results of command line queries such as the examples listed in "Modifications" above.
Finally, when satisfied with your entries, submit your bug report by pressing the COMMIT button.
Verifying Bugs
Bugs in the SME Server Release, SME Server Future & SME Server Translations products
need to be verified if fixed. (otherwise they can be closed)
An example is bugzilla:3727. You can use the text below as a template.
Information from here is used in the Updates Announcements and if you use this format will save duplication of work
Other Products can be Closed after being fixed, as they are not part of the updates process.
= Environment: = Current version installed: = Original problem: = Resolution: = Updated version installed: = Problem fixed: = Verified or Reopen: Marking VERIFIED.
General
Bug Categories
Bugs are sorted by Product, they should be mostly self explanatory. Future/7.x/8.x may need clarifying.
With the release of SME 7.3, development is now focussed on reaching 8.0
- SME Server Future
- Bugs can be moved to future if they can be classified as NewFeatureRequest
- or as cleanup functionality that does not have a major (user-visible) impact.
- Bugs that should be fixed, but not sure which future release they will be fixed in
- SME Server Release 7.X
- The error is severe enough that we need to fix it, taking time away from 8.x development
- The bug is being worked on actively
- The bug has been cloned from 8.x for backporting
- SME Server Release 8.X
- current development
Bug Triage
If you can help do these steps, the developers can concentrate on fixing the bugs.
The steps in this list is maybe 90% of the time of most bugs.
Reread How to report bugs effectively
Now look at the bug reports in Bugzilla with your developer hat on.
- Go into triage mode
- Ask the questions asked by the essay
- Get the information from the reporter
- Reproduce the issue
- Confirm the bug or mark it invalid if you can't reproduce it
- Summarise the issue if the report isn't clear
- Add a note about a workaround/fix if one is obvious to you
- That fix may not be the one we adopt, but it often helps if you tell us what you did to fix it
Bug Status
Resolution status:
- UNCONFIRMED
New bugs submitted by ordinary users are created in this state. Note. Project Developers tend not to look at unconfirmed bugs as they only have so much time, so it's important regular users check each others bugs.
- NEW
Once bugs are confirmed, by anyone see note above, change the status to new,
- FIXED
Set to fixed after the problem has been solved for others, eg a new rpm is available, documentation has been added, etc.
For SmeServer category bugs changing to FIXED is reserved for devs.
Occasionally the dev will forget to set the FIXED status and as part of the verification process will be pushed to FIXED on the way to VERIFIED by the person verifying the package. It should never be set to FIXED or VERIFIED without having a released package that is in CVS.
Bugs in Documentation, Translation, Contribs, or Websites categories need community involvement, anyone can resolve these FIXED.
Alternatives to Fixed are :
- INVALID
If you see that a problem is not a bug. eg User error Mark INVALID if the report is of documented (i.e. expected and correct) behaviour, or was encountered in some explicitly unsupported circumstance
- WONTFIX
This bug is:
- Too hard to fix
- Too rare
- Not something we can fix
- Something we chose not to expend resources on fixing
This is a hard call, usually made by the dev team. It may be a serious issue for the reporter but we may simply say "Sorry, that's just not worth the effort involved"
- LATER
Leave the bug for later, eg in case another bug will fix a related issue.
- REMIND
Needs follow-up from the reporter or someone else to get any further. Please REOPEN bugs when the follow-up comes in.
- WORKSFORME
You've been able to show that the problem does not happen for you. You should do this on a known good test box without any contribs installed. Many of our reports are breakage due to contribs.
- DUPLICATE
For when the reporter didn't find the related bug.
- VERIFIED
Check the fix provided solves the issue.
- CLOSED
Bug Tracker Administrators Close bugs in SME Current or SME Future,
but the reporter or maintainer can close in other sections, eg Documentation, Websites, Contribs
There is no need to verify a non-fix. Invalid/wontfix bugs can move straight to closed.
Bugzilla flags
These will be obvious to the people they are intended to serve. If you feel comfortable setting them based on information contained in the bug or needs you have for the bug then set them. If not then leave them be.
- need_help_to_verify [-+?]
"I don't understand how to verify this bug - please help" - a request to the dev team or other verifiers to have another look at the bug. Please say what you don't understand and what you've looked at.
- package_maintained_upstream
The package is maintained in an upstream repository. We won't be patching it locally. We've deemed it to be not important enough for us to fork the package, and so we'll wait for the fix to propogate from upstream. In these case we like to add a URL to the upstream bug report.
- patch_or_code_attached [-+?]
There is either a patch or some code attached to this bug. Attached may actually mean inline in the text, but the bug contains some code change which someone says works for them.
- Review [-+?]
This bug/change needs review by someone else. This is used by the dev team for "Do you think this change is a good one?"
- [-+?]
Set the flag to ? to say someone needs to look at it