Hi All<br><br>I will be putting the latest workflow bug triaging flowchart on a wiki page this afternoon with a link on the QA wiki page to it. I saw an email in the digest that had a ton of questions. I answered some to the best of my abilities, if someone else wants to look at the questions (bolded) and comment, please do so. I feel like as the new guy I really don't want to overstep, mis-state, etc....<div>
<br></div><div>Here are my responses to the questions:<br><br>Just want to clarify a bit before addressing eah question. This is only meant to be a guide for users, one example of many that is feasible to use. Many people have said that they like the general guidelines but as was mentioned earlier, there is no expectation what so ever that everyone will follow this identically or at all really, it's up to the QA person if they feel this is appropriate or not. <br>
<br><b>I'd change the workflow a little bit by putting the obvious things at the<br>top:<br>- feature requests aka wishlist - add target milestone if a feature is<br>planned already<br>- bugs reported against not supported branches - exclude those at reporting<br>
level by disabling old versions in select fields; but what to do when they<br>appear anyway - mark them as INVALID at triaging? ask the reporter to check<br>in new version? Any comments?<br>- is it Most Frequently Reported - then just dupe it<br>
and now, if a bug is still there, triage it by the proposed workflow.</b><div><b><br></b></div><div><b><br></b></div><div>As of now there isn't the extra stuff, it may be included later, this all began just a few days ago and I'm still trying to figure out how much to include. Because this is only a general guideline, putting too much time into detailing every step just makes it mechanical which this project will never be. As for INVALID and other status', I've been asked to make another flowchart for this and I intend on doing that soon (currently working on a couple bugs so it's going to have to wait a bit)</div>
<div><br></div><div><br><b><br>- how you define most and many - I reported those two bugs on behalf of ~xx<br>people - is my bug better than other reports? Should this be controlled by<br>number of dupes? At what levels? Maybe enabling voting feature of Bugzilla<br>
would help here... <br></b><br>Up to the person triaging and if I try to force my views, I'll get push back ;) My general thought: most is >75%, many is >30%</div><div><br></div><div><br></div><div><b>- regressions - this is a major problem and I think it deserves its own<br>
place in the workflow. It is not a big problem for home users to switch the<br>version back and forth. But when we are talking in terms of bigger<br>deployment, when you have xx computers (and growing) it becomes a real<br>
blocker sometimes. What good are new and fixed versions for, where there is<br>a regression which disqualifies the software for daily use? That is a big<br>problem.</b></div><div><br></div><div>New one addresses this as a special note on the bottom. I agree that it's important<br>
<br><br><b>- backtraces - not all people can do proper backtrace, especially on<br>Windows, so maybe while triaging crash bugs one could ask for one a QA<br>member? BTW: Having own dev build of LO 3.5.4.2 I can be QA contact for<br>
missing bt for all Windows crash bugs (except Base) on that branch. </b></div><div><b><br></b></div><div>If you can't do a backtrace on something that needs a backtrace, the bug shouldn't be triaged by you IMO. Many bugs don't require backtracing, those that do should be left to people who know how to do it to triage.My backtracing abilities are nill but on the list of to learn so until I learn, I skip over the questions that need a backtrace.</div>
<div><br></div><div><br></div><div><b>- permissions - seems like every user has canconfirm (Can confirm a bug) and<br>editbugs (Can edit all aspects of any bug). Did you think about changing<br>that, so one could not interfere with QA actions or vandalize the bug<br>
reports? </b></div><div><b><br></b></div><div>I addressed something similar and ultimately we want to keep it open. There is no vandalizing bugs, sometimes mis-triaging occurs (many times) but hopefully with our team of qualified QA people most bugs are done correctly. When someone reports it's left as UNCONFIRMED and from what I see, only people from our staff really change that status. Until it's out of that status, we know that most likely what was reported was by the user and not our staff (ie. we check things)</div>
<div><br></div><div><br></div><div><b>Bugs triaged. But those are only b.f.o. bugs. Checking release info for<br>3.5.5.1 I can see such acronyms like bnc, i, rhbz and there are bugs<br>reported on b.f.o. coming from aoo (where they may be fixed already). Not<br>
mentioning ubuntu, gentoo, opensuse and other bugtrackers. This is a very<br>serious problem, because not all bugs are in one place. Any comments about<br>that?</b></div><div><br></div><div>I'm new to the team so I don't have a comment about this, maybe someone else does though.</div>
<div><br></div><div><br></div><div><b>So, not bad but if there is more not assigned RESOLVED FIXED or NEW bugs<br>with commits in the repo, then I see a problem here. QA should know what is<br>happening with the bugs without the need to follow the comments. How does it<br>
look for xxxx commits? Also I see a lot of commits without bug report number<br>in it. What is fixed then? I see it as another problem. <br></b><br>Same response as above. As I get used to the workflow and the realities of doing such a large project with such a limited number of users I'll see what my opinions are. I made this to just clarify for myself and share with others who might find it useful. This is out of the scope of the flowchart but others may have opinions about it.<br>
<br><br><b>I see you do not use QA field in Bugzilla. Why is that? Every component of a</b><br><b>product can have its default QA specialist. Then developers responsible for</b><br><b>a component quality can get a notice of new bugs instead of news about all</b><br>
<b>of them. Also QA specialist assigned here could be responsible for</b><br><b>bibisecting, bt delivery or verifying the bug.</b><br><br>Not sure. I don't see it as needed really and I think with the limited time, people and man hours (a bit redundant?), adding even more to fill out is problematic. <br>
<br><br><b>By the way - Browsing through dev/qa mailinglist I can see that you prefer</b><br><b>those lists than bugs in Bugzilla. For instance - are those action items</b><br><b>from ESC or QA meetings reported as bugs in Bugzilla? b.f.o is not used</b><br>
<b>project wide or am I missing something?</b></div><div><b><br></b></div><div>Not sure that I understand, maybe someone else can answer it.<br><br><b>Do you VERIFY bugs? I see just 62 bugs as VERIFIED FIXED. I do not see such</b><br>
<b>section in Getting Involved. Surely there are users willing to participate</b><br><b>this way.</b></div><div><b><br></b></div><div>Agreed, I'll put this on my to do list.<br><br><b>I see you do not use flags and prefer Whiteboard. Why is that? Maybe a</b><br>
<b>better idea than a MAB nightmare (IMHO meta bugs with >300 comments are</b><br><b>useless) would be a release tracking flag, where QA would like to see a fix.</b><br><b>Mozilla projects use them a lot for instance... </b><br>
<br>I think too much is already written about using whiteboard correctly and too many on the QA staff (as well as others) are comfortable with the whiteboard. I am yet to use it really but don't see this as a major obstacle personally.</div>
<div><br></div><div><br></div><div>I hope that I answered things correctly and others may have more feedback. Appreciate the feedback. My goal is by end of year to be at 0 UNCONFIRMED bugs > 2 weeks old. It's a hefty goal but I think with a workflow <br>
<br><br><br>Hi.<br>This is a very nice workflow, but I have some questions:<br>- how you define "Bug prevent users from making professional quality work?"<br>Interoperability issues are a big obstacle. If this package is supposed to<br>
read/write MSOffice files, then every new bug in this area should have high<br>priority by default. I have reported two annoying:<br><a href="https://bugs.freedesktop.org/show_bug.cgi?id=47138" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=47138</a> 47138 and<br>
<a href="https://bugs.freedesktop.org/show_bug.cgi?id=49102" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=49102</a> 49102 . Are those<br>"prevent users from making professional quality work" enough? Home users can<br>
live with a workaround, but it is impossible to expect that xx(x) users will<br>do it xx times a day. Everyday. That is not "professional" (even worse - it<br>is very "unprofessional" for those users migrated from MSO, where it just<br>
worked).<br><br>I'd change the workflow a little bit by putting the obvious things at the<br>top:<br>- feature requests aka wishlist - add target milestone if a feature is<br>planned already<br>- bugs reported against not supported branches - exclude those at reporting<br>
level by disabling old versions in select fields; but what to do when they<br>appear anyway - mark them as INVALID at triaging? ask the reporter to check<br>in new version? Any comments?<br>- is it Most Frequently Reported - then just dupe it<br>
and now, if a bug is still there, triage it by the proposed workflow.<br><br>- how you define most and many - I reported those two bugs on behalf of ~xx<br>people - is my bug better than other reports? Should this be controlled by<br>
number of dupes? At what levels? Maybe enabling voting feature of Bugzilla<br>would help here...<br><br>- regressions - this is a major problem and I think it deserves its own<br>place in the workflow. It is not a big problem for home users to switch the<br>
version back and forth. But when we are talking in terms of bigger<br>deployment, when you have xx computers (and growing) it becomes a real<br>blocker sometimes. What good are new and fixed versions for, where there is<br>
a regression which disqualifies the software for daily use? That is a big<br>problem.<br><br>- backtraces - not all people can do proper backtrace, especially on<br>Windows, so maybe while triaging crash bugs one could ask for one a QA<br>
member? BTW: Having own dev build of LO 3.5.4.2 I can be QA contact for<br>missing bt for all Windows crash bugs (except Base) on that branch.<br><br>- permissions - seems like every user has canconfirm (Can confirm a bug) and<br>
editbugs (Can edit all aspects of any bug). Did you think about changing<br>that, so one could not interfere with QA actions or vandalize the bug<br>reports?<br><br>Bugs triaged. But those are only b.f.o. bugs. Checking release info for<br>
3.5.5.1 I can see such acronyms like bnc, i, rhbz and there are bugs<br>reported on b.f.o. coming from aoo (where they may be fixed already). Not<br>mentioning ubuntu, gentoo, opensuse and other bugtrackers. This is a very<br>
serious problem, because not all bugs are in one place. Any comments about<br>that?<br><br>Does the developers have their workflow in Bugzilla? I compared few commits<br>(libreoffice/core libreoffice-3-5-5) with b.f.o reports:<br>
- 50603 - not assigned, UNCONFIRMED>RESOLVED FIXED<br>- 43967 - assigned, UNCONFIRMED>NEW>RESOLVED<br>FIXED>REOPENED>ASSIGNED>RESOLVED FIXED<br>- 48601 - not assigned, UNCONFIRMED>NEW<br>- 50988 - assigned, UNCONFIRMED>ASSIGNED>RESOLVED FIXED<br>
- 43249 - assigned, UNCONFIRMED>NEW>RESOLVED FIXED<br><br>So, not bad but if there is more not assigned RESOLVED FIXED or NEW bugs<br>with commits in the repo, then I see a problem here. QA should know what is<br>happening with the bugs without the need to follow the comments. How does it<br>
look for xxxx commits? Also I see a lot of commits without bug report number<br>in it. What is fixed then? I see it as another problem.<br><br>I see you do not use QA field in Bugzilla. Why is that? Every component of a<br>
product can have its default QA specialist. Then developers responsible for<br>a component quality can get a notice of new bugs instead of news about all<br>of them. Also QA specialist assigned here could be responsible for<br>
bibisecting, bt delivery or verifying the bug.<br><br>By the way - Browsing through dev/qa mailinglist I can see that you prefer<br>those lists than bugs in Bugzilla. For instance - are those action items<br>from ESC or QA meetings reported as bugs in Bugzilla? b.f.o is not used<br>
project wide or am I missing something?<br><br>Do you VERIFY bugs? I see just 62 bugs as VERIFIED FIXED. I do not see such<br>section in Getting Involved. Surely there are users willing to participate<br>this way.<br><br>
I see you do not use flags and prefer Whiteboard. Why is that? Maybe a<br>better idea than a MAB nightmare (IMHO meta bugs with >300 comments are<br>useless) would be a release tracking flag, where QA would like to see a fix.<br>
Mozilla projects use them a lot for instance...<br><br>Well, sorry for such a pack of off-topic questions, but I'd like to<br>understand QA in this project better.<br>Best regards.<br></div></div><br><div class="gmail_quote">
On Thu, Jun 14, 2012 at 10:15 AM, Joel Madero <span dir="ltr"><<a href="mailto:jmadero.dev@gmail.com" target="_blank">jmadero.dev@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just an update on this since some people showed interest. I am/was<br>
willing to do a manual list using a quick macro in calc but the wiki<br>
blocks me from using href so unless that is changed I don't see how I<br>
can link the bug to FDO which makes this endeavor a bit useless. If<br>
someone knows if I can get around the spam block I'll get the page<br>
updated, otherwise going to say this one is off :(<br>
<span><font color="#888888"><br>
<br>
Joel<br>
</font></span><div><div><br>
On Sat, Jun 2, 2012 at 3:39 PM, Joel Madero <<a href="mailto:jmadero.dev@gmail.com" target="_blank">jmadero.dev@gmail.com</a>> wrote:<br>
> I've never used this kind of API before. I could just use it within the wiki<br>
> at Libre Office Development? I apologize for the lack of knowledge, trying<br>
> to pick it up and contribute just need a little guidance. Is there a how to<br>
> somewhere that I can look over?<br>
><br>
> I'm going to say I'm a beginner but not absolute beginner so that gives a<br>
> bit of a scope of my abilities. Thanks again to all of you<br>
><br>
> On Sat, Jun 2, 2012 at 3:03 PM, Markus Mohrhard<br>
> <<a href="mailto:markus.mohrhard@googlemail.com" target="_blank">markus.mohrhard@googlemail.com</a>> wrote:<br>
>><br>
>> Hello Joel,<br>
>><br>
>> 2012/6/2 Joel Madero <<a href="mailto:jmadero.dev@gmail.com" target="_blank">jmadero.dev@gmail.com</a>>:<br>
>> > In order to use the API would one of the webmasters have to add things<br>
>> > to<br>
>> > the server? Looks much more promising than it did a few hours ago.<br>
>> > Thanks<br>
>> > for pointing me in the right directino<br>
>> ><br>
>> ><br>
>><br>
>> I did not have success using the REST Api with the fdo bugzilla. As<br>
>> much as I understood from the documentation it is an optional module<br>
>> and it seems it is not activated at fdo. However there is another<br>
>> package that we now succesfully use for git bugzilla integration:<br>
>> <a href="http://search.cpan.org/~bmc/WWW-Bugzilla-1.5/" target="_blank">http://search.cpan.org/~bmc/WWW-Bugzilla-1.5/</a><br>
>><br>
>> Regards,<br>
>> Markus<br>
><br>
><br>
</div></div></blockquote></div><br>