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+unsubscr...@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