Difference between revisions of "Bugzilla Help"

From SME Server
Jump to navigationJump to search
 
(97 intermediate revisions by 8 users not shown)
Line 1: Line 1:
−
==Chapter 8. Bug Tracker==
+
<noinclude>{{Languages}}</noinclude>
−
Find, report and fix bugs here http://bugs.contribs.org/
+
==Bug Tracker==
  
−
You don't have to be a programmer to help or use the bug tracker.
+
Please help us to make our software as reliable as possible. Please report possible bugs only via the bug tracker and encourage others to do the same.  
−
Bugs also include fixing things and making suggestions on documentation, translations and the SME Server web sites.
 
  
−
General Instructions for using the bug Tracker are here [http://www.bugzilla.org/docs/tip/html/using.html Using Bugzilla]
+
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
  
−
===Searching for bugs===
+
Find, report and fix bugs here http://bugs.contribs.org
−
To help find bugs, some prepared searches have been added in page headers, with more [[SME_Server:Documentation:HowTo:BugzillaReports | BugzillaReports]] here
 
  
−
1. Simple search <br />
+
===Bugzilla is easy===
−
At the top of the search page choose 'Find a specific bug' <br />
 
−
Select a Status and a Product category and enter your search term <br />
 
  
−
2. Advanced search <br />
+
A frequent complaint is Bugzilla is too hard or convoluted, but it is hard to justify the complaint.
−
At the top of the search page choose 'Advanced search'
 
  
 +
*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  <br />
 
You can restrict searches by using a selection or multiple selections of a category  <br />
−
Use Control Click to select/deselect from selection sets, if none are selected all are.
+
Use Control Click to select/deselect from selection sets, if none are selected the defailt is all.
 +
 
 +
* 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
 +
[http://www.chiark.greenend.org.uk/~sgtatham/bugs.html 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 so use some discretion, see 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 Contribs & SME Server Translations products
 +
need to be verified when fixed, see the [[Verification_Queue]] for the current list. See [[SME_Server:Documentation:QA:Verification]] for a detailed description of the verification process. <br />
 +
 
 +
An example is [[bugzilla:3727]] or [[bugzilla:7364]].
 +
 
 +
'''Information from here is used in the Updates Announcements and if you use this format, it will save duplication of work'''
 +
 
 +
Other Products can be Closed after being fixed, as they are not part of the updates process.
 +
 
 +
The bug report will detail the exact package and version needed. These are normally in smeupdates-testing and can be installed by :
 +
yum --enablerepo=smeupdates-testing update <package>
 +
 
 +
for example
 +
yum --enablerepo=smeupdates-testing update e-smith-ldap
 +
 
 +
As it is a manual step to move packages into smeupdates-testing the most recent packages will be in smetest and can be installed from there if necessary.
 +
for example
 +
  yum --enablerepo=smetest update e-smith-ldap
 +
or if you need several repositories :
 +
  yum --enablerepo=smetest,smeupdates-testing,smedev update e-smith-ldap
 +
 
 +
When performing verification, please use the following template:
 +
 
 +
'''VERIFICATION TEMPLATE'''
 +
 
 +
= ENVIRONMENT:
 +
 +
= ORIGINAL PROBLEM:
 +
 +
= RESOLUTION:
 +
 +
= CURRENT VERSION INSTALLED:
 +
 +
= TESTING:
 +
 +
= UPDATED VERSION INSTALLED:
 +
 +
= PROBLEM FIXED:
 +
 +
= VERIFIED OR REOPEN:
 +
 +
= DOCUMENTATION IMPACT:
 +
 +
= SUGGESTED RELEASE NOTES:
  
−
typically you may restrict Product to use  '7.x/Future/Documentation' <br />
+
AS AN EXAMPLE:
−
and enter a search term into either 'Summary' or 'A Comment'
 
  
−
eg. Status = CLOSED, Resolution = WONTFIX, Summary = yum <br />
+
VERIFICATION
−
will return about 7 bugs
+
 +
= ENVIRONMENT:
 +
[description of test system (version, installation methods, upgrade history. etc).
 +
If you have some non-core package installed, run /sbin/e-smith/audittools/newrpms and provide output]
 +
 +
= ORIGINAL PROBLEM:
 +
[Summarise bug]
 +
 +
= RESOLUTION:
 +
[Insert changelog for new package]
 +
In example:
 +
Fixed in e-smith-base
 +
* Mon Apr 21 2013 chris burnat <devlist@burnat.com> 5.4.0-27.sme
 +
- Fix the way '.' works in bash [SME: 7532]
 +
 +
= CURRENT VERSION INSTALLED:
 +
[rpm -qa <package name>]
 +
 +
=TESTING:
 +
[Reproduce bug if you can, showing steps taken]
 +
 +
= UPDATED VERSION INSTALLED:
 +
[Update to new package, show steps taken]
 +
and:
 +
[rpm -qa <package name>]
 +
 +
= PROBLEM FIXED?:
 +
[Repeat steps carried out under TESTING above.
 +
 +
= VERIFIED OR REOPEN:
 +
[Problem fixed, then VERIFIED - not fixed, then REOPEN]
 +
Note: if you may not have rights to toggle resolution, someone will do it for you
 +
 +
= DOCUMENTATION IMPACT:
 +
[Does something need documentation, eg a db or new procedure? if affirmative, please provide details, someone will later punt to docteam for action]
 +
 +
= SUGGESTED RELEASE NOTES:
 +
[Summary of what was fixed]
  
−
eg. Status = CLOSED, Resolution = WONTFIX, A Comment = yum <br />
+
===Testing===
−
will return about 17 bugs
+
It is recommended that some basic tests be carried out before resolving VERIFIED. The scope of these tests very much depends on functionality associated with the package(s) under consideration. The following list whilst not fully inclusive can be used as a guide:
  
−
*Modifying your search
+
*Hosting http
 +
*Hosting https
 +
*Access external http
 +
*Access external https
 +
*SSH access to server
 +
*Send Email
 +
*Receive Email
 +
*Use Webmail
 +
*Use Samba
 +
*FTP access to SME
 +
*Check /var/log/messages or/and any other relevant log.
  
−
- Click on the hyperlinked headers to sort your list
+
===General===
 +
====Bug Categories====
  
−
- Click 'Edit Search' near the page footer
+
Bugs are sorted by '''Product''', they should be mostly self explanatory. Future/7.x/8.x/9.x may need clarifying.
−
* you can adjust your selection sets
 
−
* add a search tern in the summary or comments fields
 
−
* restrict the dates, eg between 365d and Now the last year,  60d and 7d from 2months ago but not the last week
 
−
* bugs you are working on or watching,  add you email address to the left field in email and numbering and check cc:, commenter, etc
 
  
−
- If you have a favourite search,  
+
With the release of SME 8.0, development is now focussed on reaching 9.0
−
* when the bug list is displaying, add a name in the  Remember field, these will show in your footer
 
−
* add the search to the  [[:BugzillaReports | BugzillaReports]] page
 
  
−
===Reporting Bugs===
+
*SME Server Future       
−
Please help us to make our software as reliable as possible. Your role in that is to report possible bugs only via the bug tracker, and to encourage others to do the same. Thanks.
+
-  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.
  
−
[[http://www.bugzilla.org/docs/tip/html/bugreports.html#fillingbugs Reporting a New Bug]]
+
-  Bugs that should be fixed, but not sure which future release they will be fixed in
−
If you have searched the Manual and Bug Tracker and not found an answer or someone else's report that matches yours, you should register on the Bug Tracker and enter a new bug. The debugging process of any issue requires active participation on the part of the reporter, providing further information and clarification of the problem.
+
 +
*SME Server Release 7.X   
 +
-  The error is severe enough that we need to fix it, taking time away from 9.x development
  
−
* So how do I know it is a bug?
+
-  The bug is being worked on actively
−
You don't need to. If there's any chance that it is a bug, please report to the bug tracker. It doesn't matter whether anyone else has seen it. It doesn't matter whether anyone else has a theory as to what is happening. You have noticed something that doesn't seem to work right, so just report it. Please.
 
  
−
To enter a bug choose a category, component, fill in the details of the bug, and commit.  
+
-  The bug has been cloned from 8.x for backporting
−
Please use a descriptive Summary, as most of the header searches just show the Summary
 
−
* 'panel errors' is not helpful, what panel, what errors ?
 
−
* 'Add option to limit mailman web access ' explains the topic very well
 
  
−
Anyone reporting problems, ask yourself these important questions, so that you
+
*SME Server Release 8.X   
−
know what to tell the developers in the bug report:
+
-  The error is severe enough that we need to fix it, taking time away from 9.x development
  
−
# What version am I using and are there any contribs installed or other customisations?
+
-  The bug is being worked on actively
−
# What did I do?
 
−
# What did I expect to happen?
 
−
# What happened?
 
−
# What do the logs say?
 
  
 +
*SME Server Release 9.X
 +
-  current development
  
−
===Bug and New Feature Verification===
+
====Bug Triage====
−
If you find a bug you can work on, please do so.
 
  
−
As an example, the documentation section, only requires you to take the answer determined in the bug and copy the information onto the wiki.
+
If you can help, the developers can concentrate on fixing the bugs. <br >
−
There are likely to be a lot of these as they were generated before the wiki was in place.
+
The steps in this list take approx 90% of the time in the resolving of most bugs.  
  
−
In this example of adding documentation,
+
Reread [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to report bugs effectively]
−
* find a bug where you understand the problem resolved
 
−
* update the wiki, information will go in a manual, be added to the FAQ or a howto, or create a new howto
 
−
* return to the bug post brief details of the fix, and how to verify it, eg 'updated wiki re: passwords' and give the URL
 
−
* then change the Status to 'Resolved - Fixed'.
 
−
* let someone else verify, or verify someone else's work
 
  
−
At the appropriate stage change the Status to 'Resolved - Fixed' or 'Resolved - Verified'
+
Now look at the bug reports in Bugzilla with your developer hat on.
  
−
Bug Tracker Administrators Close bugs in SME Current or SME Future, but the reporter or maintainer can close in other sections.
+
* Go into triage mode this page can help You : [[Bugzilla_Reports]]
 +
* 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====
  
−
===Bug Status===
+
[http://www.bugzilla.org/docs/tip/html/lifecycle.html Lifecycle of a Bug]
−
[[http://www.bugzilla.org/docs/tip/html/lifecycle.html Lifecycle of a Bug]]
 
  
−
Resolution statuses:
+
Resolution status:
  
 
* UNCONFIRMED
 
* UNCONFIRMED
Line 94: Line 244:
 
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.
 
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
+
* NEEDINFO
−
Once bugs are confirmed, '''by anyone''' see note above, change status to new,
+
This is a new state that should be used when more information is needed by the bug reporter.
 +
 
 +
* CONFIRMED
 +
Once bugs are confirmed to be valid and present in SME Server, '''by anyone''' see note above, change the status to CONFIRMED.
 +
Only change to CONFIRMED if the bug is well written and has enough information to proceed.
 +
 
 +
* IN_PROGRESS
 +
This indicates a developer is actively working on the bug.
  
 
* FIXED
 
* FIXED
Line 101: Line 258:
 
eg a new rpm is available, documentation has been added, etc.
 
eg a new rpm is available, documentation has been added, etc.
  
−
* INVALID
+
For SmeServer category bugs changing to FIXED is reserved for devs.
−
If you see that a bug and are able to pinpoint the error a user made and  
+
 
−
there is in fact nothing wrong.
+
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 :
 +
 
 +
* NOTABUG
 +
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
 
* WONTFIX
−
The problem should be solved elsewhere,  
+
This bug is: <br>
−
eg an rpm maintained elsewhere, such as Horde webmail.
+
- Too hard to fix <br>
 +
- Too rare <br>
 +
- Not something we can fix <br>
 +
- 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
 
* LATER
Line 114: Line 292:
  
 
* REMIND
 
* REMIND
−
Close until the reporter can provide the requested feedback.
+
Needs follow-up from the reporter or someone else to get any further.
 +
Please REOPEN bugs when the follow-up comes in.
  
 
* WORKSFORME
 
* 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
 
* DUPLICATE
 
For when the reporter didn't find the related bug.
 
For when the reporter didn't find the related bug.
  
 +
----
 
* VERIFIED
 
* VERIFIED
 
Check the fix provided solves the issue.
 
Check the fix provided solves the issue.
  
 
* CLOSED
 
* CLOSED
−
Bug Tracker Administrators Close bugs in SME Current or SME Future,  
+
Bug Tracker Administrators Close bugs in SME Current or SME Future, <br>
−
but the reporter or maintainer can close in other sections, eg Documentation, Websites, Contribs
+
but the reporter or maintainer can close in other sections, eg Documentation, Websites, Contribs <br>
 +
There is no need to verify a non-fix. Invalid/wontfix bugs can move straight to closed.
  
−
===Bugzilla flags===
+
====Bugzilla flags====
−
 
 
−
{{FixMe}}
 
−
what do the -+? mean, when do you set them, if in doubt just use + ?? <br>
 
−
not sure why we have some of the flags, check comments below
 
  
 +
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 [-+?]  
 
* need_help_to_verify [-+?]  
−
You don't understand the fix provided,
+
"I don't understand how to verify this bug - please help" - a request to
−
explain what you think the fixed means or what you have tried
+
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 [-+?]
 
−
Is this needed, shouldn't you just close the bug ?
 
−
 
 
−
 
 
−
* patch_in_cvs [-+?]
 
−
So a new RPM will shortly be available, untested presumably
 
  
 +
* 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 [-+?]
 
* patch_or_code_attached [-+?]
−
Great, a solution not a problem, lets make it clear
+
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 [-+?]
 
* Review [-+?]
−
You have made a suggestion or added code you would like comment on
+
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
  
−
* addl. patch_or_code_attached [-+?]
+
[[Category:SME Server]][[Category:SME9-Development]][[Category:Developer]]
−
You added more code, is this needed just leave the above flag on ?
 

Latest revision as of 11:06, 12 February 2015

Geographylogo.png Languages: 

English


Bug Tracker

Please help us to make our software as reliable as possible. Please report possible bugs only via the bug tracker and 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 the complaint.

  • 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 the defailt is all.

  • 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 so use some discretion, see 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 Contribs & SME Server Translations products need to be verified when fixed, see the Verification_Queue for the current list. See SME_Server:Documentation:QA:Verification for a detailed description of the verification process.

An example is bugzilla:3727 or bugzilla:7364.

Information from here is used in the Updates Announcements and if you use this format, it will save duplication of work

Other Products can be Closed after being fixed, as they are not part of the updates process.

The bug report will detail the exact package and version needed. These are normally in smeupdates-testing and can be installed by : 

yum --enablerepo=smeupdates-testing update <package>

for example 

yum --enablerepo=smeupdates-testing update e-smith-ldap

As it is a manual step to move packages into smeupdates-testing the most recent packages will be in smetest and can be installed from there if necessary. for example 

 yum --enablerepo=smetest update e-smith-ldap

or if you need several repositories : 

 yum --enablerepo=smetest,smeupdates-testing,smedev update e-smith-ldap

When performing verification, please use the following template:

VERIFICATION TEMPLATE 

= ENVIRONMENT: 

= ORIGINAL PROBLEM:

= RESOLUTION:

= CURRENT VERSION INSTALLED:

= TESTING:

= UPDATED VERSION INSTALLED:

= PROBLEM FIXED:

= VERIFIED OR REOPEN:

= DOCUMENTATION IMPACT:

= SUGGESTED RELEASE NOTES:

AS AN EXAMPLE: 

VERIFICATION

= ENVIRONMENT:
[description of test system (version, installation methods, upgrade history. etc).
If you have some non-core package installed, run /sbin/e-smith/audittools/newrpms and provide output]

= ORIGINAL PROBLEM:
[Summarise bug]

= RESOLUTION:
[Insert changelog for new package]
In example:
Fixed in e-smith-base
* Mon Apr 21 2013 chris burnat <devlist@burnat.com> 5.4.0-27.sme
- Fix the way '.' works in bash [SME: 7532]

= CURRENT VERSION INSTALLED:
[rpm -qa <package name>]

=TESTING:
[Reproduce bug if you can, showing steps taken]

= UPDATED VERSION INSTALLED:
[Update to new package, show steps taken]
and:
[rpm -qa <package name>]

= PROBLEM FIXED?:
[Repeat steps carried out under TESTING above.

= VERIFIED OR REOPEN:
[Problem fixed, then VERIFIED - not fixed, then REOPEN]
Note: if you may not have rights to toggle resolution, someone will do it for you

= DOCUMENTATION IMPACT:
[Does something need documentation, eg a db or new procedure? if affirmative, please provide details, someone will later punt to docteam for action]

= SUGGESTED RELEASE NOTES:
[Summary of what was fixed]

Testing

It is recommended that some basic tests be carried out before resolving VERIFIED. The scope of these tests very much depends on functionality associated with the package(s) under consideration. The following list whilst not fully inclusive can be used as a guide:

  • Hosting http
  • Hosting https
  • Access external http
  • Access external https
  • SSH access to server
  • Send Email
  • Receive Email
  • Use Webmail
  • Use Samba
  • FTP access to SME
  • Check /var/log/messages or/and any other relevant log.

General

Bug Categories

Bugs are sorted by Product, they should be mostly self explanatory. Future/7.x/8.x/9.x may need clarifying.

With the release of SME 8.0, development is now focussed on reaching 9.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 9.x development

- The bug is being worked on actively

- The bug has been cloned from 8.x for backporting

  • SME Server Release 8.X

- The error is severe enough that we need to fix it, taking time away from 9.x development

- The bug is being worked on actively

  • SME Server Release 9.X

- current development

Bug Triage

If you can help, the developers can concentrate on fixing the bugs.
The steps in this list take approx 90% of the time in the resolving 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 this page can help You : Bugzilla_Reports
  • 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

Lifecycle of a Bug

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.

  • NEEDINFO

This is a new state that should be used when more information is needed by the bug reporter.

  • CONFIRMED

Once bugs are confirmed to be valid and present in SME Server, by anyone see note above, change the status to CONFIRMED. Only change to CONFIRMED if the bug is well written and has enough information to proceed.

  • IN_PROGRESS

This indicates a developer is actively working on the bug.

  • 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 :

  • NOTABUG

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

Retrieved from "https://wiki.koozali.org/index.php?title=Bugzilla_Help&oldid=27435"