[libreoffice-users] Understanding the Bugzilla issue tracker

Charles S. (aka. Tanstaafl) asked in this thread: 
Sent: Saturday, October 04, 2014 7:07 AM
Subject: Re: [libreoffice-users] Re: How to handle regressions

> Follow-up...
>
> In the bug UI, is there an easy way to get a list of bugs that have been
> patched/fixed in master, that a user like me could browse, and pick
> certain ones that I could then test and if confirmed fixed, could
> request be back-ported (if they haven't been already)?
>
> I would be very happy to participate in this manner, but honestly, the
> bug UI is a bit daunting, so anything that makes this easier for non
> devs would be very welcome for technically inclined non-devs like yours
> truly. 

@Charles, *,

Great question!  As it happens you can do just that as the project has
implemented use of a set of status messages posted to the *Whiteboard* field
in Bugzilla to hold various QA and development status notes.  

Notice of patch commits against specific BZ issues are automatically
posted** 

-=To search against the Whiteboard=-

Open Bugzilla --> Search,  and select the "Advanced Search" panel tab
Under the Product column select "LibreOffice"
Under the Status column keep the default of NEW-ASSIGNED-REOPENED (unless
looking at historical details)
In the Detailed Bug Information section, on the Whiteboard row enter
"target:4.4.0" (i.e. either current master, or specific branch) 


The general and advanced details are in these two Wiki articles:
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard/Advanced

=-=-=
From the  Complete List of Accepted Whiteboard Tags
<https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard/Advanced#Complete_List_of_Accepted_Whiteboard_Tags>
  
*target*
Description: target refers to the version(s) where a commit which fixes the
problem can be expected to be seen.

Use: Generally “target” is automatically entered when a developer commits a
patch specifically to fix a bug reported on the bug tracker. Users, QA and
Developer should generally not manually enter “target” into whiteboard, the
only exception is when the automatic system did not tag the bug and a
developer or QA member knows the exact commit which fixed the bug and what
version of LibreOffice will see the patch. In these cases a QA member can
mark a bug as “target:x.x.x.x” where x.x.x.x is the version(s) of
LibreOffice where the commit was pushed to.

*Example:*

target:4.2.0.0

This means that a commit which fixes the problem was committed to the
4.2.0.0, and therefore if a user or QA member tests 4.2.0.0 they should not
see the bug any longer.
=-=-=

Looking at Bugzilla and the Wiki, the whole process is a little daunting,
but really can be quickly mastered. 

A good starting point for the QA process--this Wiki page is helpful: 
https://wiki.documentfoundation.org/QA/BugTriage#Introduction

Stuart


**Generating the automatic target:xx.xx.xx tag does require that the dev
working in git/gerrit annotate the bug being addressed, a manual action so
it is not 100%.  But, well structured BZ issues facilitate both the QA
triage on intake and tracking at all stages as devs work on issues--so the
preferred workflow is to capture details into BZ. 








--
View this message in context: 
http://nabble.documentfoundation.org/Understanding-the-Bugzilla-issue-tracker-tp4124888.html
Sent from the Users mailing list archive at Nabble.com.

-- 
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted