Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index

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


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

@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

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

From the  Complete List of Accepted Whiteboard Tags
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.



This means that a commit which fixes the problem was committed to the, and therefore if a user or QA member tests 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:


**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:
Sent from the Users mailing list archive at

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.