5,576
edits
Changes
From SME Server
Jump to navigationJump to search→Verifying Bugs
===Verifying Bugs===
===Verifying Bugs===
Bugs in the SME Server Release, SME Contribs & SME Server Translations products
Bugs in the SME Server Release, SME Server Future & 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 />
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.
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'''
'''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.
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:
When performing verification, please use the following template:
'''VERIFICATION TEMPLATE'''
'''VERIFICATION TEMPLATE'''
= ENVIRONMENT: [eg: sme 8.0 64 bits clean from CD + all updates]
= ENVIRONMENT:
= ORIGINAL PROBLEM:
= RESOLUTION:
= CURRENT VERSION INSTALLED:
= TESTING:
= UPDATED VERSION INSTALLED:
= PROBLEM FIXED:
= ~]# /sbin/e-smith/audittools/newrpms [Provide this if customised]
= 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:
= ORIGINAL PROBLEM:
[Description]
[Summarise bug]
= RESOLUTION:
= RESOLUTION:
[Reprint changelogs of new package being verified
[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:
= CURRENT VERSION INSTALLED:
[rpm -q]
[rpm -qa <package name>]
=TESTING:
=TESTING:
[Show problem being fixed by new package]
[Reproduce bug if you can, showing steps taken]
= UPDATED VERSION INSTALLED:
= UPDATED VERSION INSTALLED:
[Show installation of new package]
[Update to new package, show steps taken]
and:
[rpm -qa <package name>]
= PROBLEM FIXED?:
[rpm -q again showing new package installed]
[Repeat steps carried out under TESTING above.
= PROBLEM FIXED:
= VERIFIED OR REOPEN:
[Repeat testing]
[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:
= DOCUMENTATION IMPACT:
[Eg: is a DB variable created/removed?]
[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:
= SUGGESTED RELEASE NOTES:
[Summary of what has been fixed in new package]
[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===
===General===
Now look at the bug reports in Bugzilla with your developer hat on.
Now look at the bug reports in Bugzilla with your developer hat on.
* Go into triage mode this page can help You [[Bugzilla_Reports]]
* Go into triage mode this page can help You : [[Bugzilla_Reports]]
* Ask the questions asked by the essay
* Ask the questions asked by the essay
* Get the information from the reporter
* Get the information from the reporter
New bugs submitted by ordinary users are created in this state.
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.
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
* CONFIRMED
Once bugs are confirmed, '''by anyone''' see note above, change the status to new,
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
Set the flag to ? to say someone needs to look at it
Set the flag to ? to say someone needs to look at it
[[Category:SME Server]][[Category:SME9-Development]]
[[Category:SME Server]][[Category:SME9-Development]][[Category:Developer]]
