Re: [Libreoffice-qa] Closing bugs in bugzilla: fixed in master or fixed everywhere?

[Bjoern Michaelsen]

On Wed, Sep 05, 2012 at 06:30:30PM +0200, Lionel Elie Mamane wrote:
> We can change our opinion on these questions, and then the "intended
> branches" set changes.

Yes, but everytime we change our opinion on this, possibly the bug state would
need to change, which is why Im not too happy with this.

> So if you go to https://bugs.freedesktop.org/show_bug.cgi?id=37361 (LO
> 3.5 MAB), you have to click through on *each* resolved bug to read the
> bug log and try to see if there is a "fixed in 3.5.x" comment (or
> possibly look in whiteboard for a target:3.5", so that you can
> evaluate whether it is still relevant, or if action is needed?
> This makes it IMHO too easy for a bug to "slip under the radar" and be
> forgotten.

Why not just query for target 3.5.x in whiteboard?

> In the ESC call agenda, we have MAB statistics that say e.g.
> 
>  * 3.5 most annoying bugs ...
>  + 81 open (of 269) older 73/258 73/257 76/256 75/253 77/253 73/250  
> 72/249
> 30% 26%28%30% 30%30%29% 29%
>  + 
> https://bugs.freedesktop.org/showdependencytree.cgi?id=37361&hide_resolved=1

While this is also queryable, Im not too happy with the MAB concept in the long
run anyway -- Petr suggested we should try to move to getting the bug
priorities right if we get the manpower for it in QA. That should be a lot
better to query in the end.

> We could consider automoving on RC release rather than final release?

I personally would stick with finals, RCs are prereleases just like daily 
builds.

Best,

Bjoern
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] QA Easyhack prosposal

[Florian Reisinger]

Hi @ll


Am 05.09.2012 17:34, schrieb Petr Mladek:

reisi007 píše v St 05. 09. 2012 v 02:34 -0700:

Petr Mladek wrote

Florian Reisinger píše v Po 03. 09. 2012 v 17:47 +0200:

What is the exact plan with the queries? :-)

If there is a question like this:

"Hmm, I want to help LibreOffice, but I don't know where to start..!"

There is no real answer for QA, except: "Have a look at bugzilla.
There you have to query the bugs you want to triage and then filter
the OS, so that you can test properly... TBC ... BTW: If you have any
questions, feel free to ask at this list"

Answer like it should IMHO be: "You can download a .ods file here:
 In this file, you can see bugs, which needs to be triaged. Open
the table with your OS and click one of the bug numbers. The queries
are auto-updated each hour. For more info, questions ect. ask here."

I made a "HTMLPASTE" with the queries from this post. Hopefully it is
helpful.
LINK
http://pastehtml.com/view/calh0sflu.html
LINK

The page can be adapted quite quickly, I hope you like it ;)

I very like the idea and the simplicity.

My only concern is about the context. Where this box would appear?




Will
people understand what they are supposed to do with the listed bugs?
We can add items quite easily (In order to play with the code the HTML 
page is attached (Not at the ML, but Astron and Petr will get it


Quote from: http://www.libreoffice.org/get-involved/qa-testers/

*Bug triage*: you can take part in the triage and confirmation of bugs 
having been reported on theLibreOffice bug tracker 
. To 
start doing so, create an account on the bug tracker and then follow 
theinstructions on our wiki page 
.


New version:

*Bug triage*: you can take part in the triage and confirmation of bugs 
having been reported on theLibreOffice bug tracker 
. To 
start doing so, create an account on the bug tracker and then follow 
theinstructions on our wiki page 
. Some queries, which may 
help you to get started can be found  -->here<---




Also I added Astron from the desing team. He might help with the
graphics part to well fit the LO Website branding.

I think that we are on the right way. Thanks for working on this.


You are welcome ;)




Best Regards,
Petr



Title: Bugzilla Query




 

Help at QA today!




  MacOS
   
   Linux
   
Windows

All OS

Unusual OS
 

___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Closing bugs in bugzilla: fixed in master or fixed everywhere?

[Lionel Elie Mamane]

On Wed, Sep 05, 2012 at 12:44:58PM +0200, Bjoern Michaelsen wrote:
> On Wed, Sep 05, 2012 at 11:39:04AM +0200, Stephan Bergmann wrote:
>> On 09/05/2012 10:46 AM, Lionel Elie Mamane wrote:

>>> I thought we close the bug when the fix is committed in all branches
>>> where it should be, and that's what I was doing in the bugs I was
>>> fixing.

>> That's my understanding too, setting a bug to RESOLVED/FIXED only
>> once all the relevant commits have reached the intended branches.

> That is quite tricky as "intended branches" is not clearly defined,

How is it "not clearly defined"?

 - Either we want the fix in 3.6.x or we don't.

 - When in the RC phase of 3.6.2, either we want the fix in
   3.6.2.next-rc or not.

 - Either we want the fix in 3.5.x or we don't.

 - When in the RC phase of 3.5.7, either we want the fix in
   3.5.7.next-rc or not.

Once these decisions are taken, the intended branches are fixed:

 - Yes -> libreoffice-3-6

 - Yes -> libreoffice-3-6-2

 - Yes -> libreoffice-3-5

 - Yes -> libreoffice-3-5-7

We can change our opinion on these questions, and then the "intended
branches" set changes.

> and in addition it runs counter to what mozilla defines the RESOLVED state:

>  https://bugzilla.mozilla.org/page.cgi?id=fields.html

Bugzilla has absolutely no clue about multiple development branches,
and this is one of its main flaws.

Even considering this, in the link you give "RESOLVED" is: "A
resolution has been taken, (...)", which to me does not say whether it
is "a resolution has been taken in some branch" or "a resolution has
been taken in all intended branches".

> In our case, as we dont really verify yet, I would suggest the following:

> RESOLVED: assumed to be fixed for some branch, not tested, not yet released

So if you go to https://bugs.freedesktop.org/show_bug.cgi?id=37361 (LO
3.5 MAB), you have to click through on *each* resolved bug to read the
bug log and try to see if there is a "fixed in 3.5.x" comment (or
possibly look in whiteboard for a target:3.5", so that you can
evaluate whether it is still relevant, or if action is needed?
This makes it IMHO too easy for a bug to "slip under the radar" and be
forgotten.

With my / Stephan's way you'd have to click on each *open* bug to get
certainty whether action is needed for 3.5; but each of these bugs has
"action needed for some branch".

I feel less bad about making people reviewing MAB list go to bugs that
need some action, but elsewhere, rather than having to look at all
already handled bugs.

In the ESC call agenda, we have MAB statistics that say e.g.

 * 3.5 most annoying bugs ...
 + 81 open (of 269) older 73/258 73/257 76/256 75/253 77/253 73/250  72/249
30% 26%28%30% 30%30%29%   29%
 + 
https://bugs.freedesktop.org/showdependencytree.cgi?id=37361&hide_resolved=1

   With your suggestion, this would mean "81 not fixed anywhere", and
   this might be... between 81 and 269 fixed in 3.5.

   With my / Stephan's way, this means "81 not fixed everywhere it
   should", and this might be between 0 and 81 fixed in 3.5.

I prefer to err on the side of caution, that is overreporting the
number of relevant bugs rather than underreproting them.


> CLOSED: there is a version with the fix released

OK with me (and a nice service to our users). Same bikeshedding on
"all intended branches have a version with the fix" or "at least one
branch has a version with the fix".

We could consider automoving on RC release rather than final release?

-- 
Lionel
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] QA Easyhack prosposal

[Petr Mladek]

reisi007 píše v St 05. 09. 2012 v 02:34 -0700:
> Petr Mladek wrote
> > 
> > Florian Reisinger píše v Po 03. 09. 2012 v 17:47 +0200:
> >> > What is the exact plan with the queries? :-)
> >> 
> >> If there is a question like this:
> >> 
> >> "Hmm, I want to help LibreOffice, but I don't know where to start..!"
> >> 
> >> There is no real answer for QA, except: "Have a look at bugzilla.
> >> There you have to query the bugs you want to triage and then filter
> >> the OS, so that you can test properly... TBC ... BTW: If you have any
> >> questions, feel free to ask at this list"
> >> 
> >> Answer like it should IMHO be: "You can download a .ods file here:
> >>  In this file, you can see bugs, which needs to be triaged. Open
> >> the table with your OS and click one of the bug numbers. The queries
> >> are auto-updated each hour. For more info, questions ect. ask here."
> >
> I made a "HTMLPASTE" with the queries from this post. Hopefully it is
> helpful. 
> LINK
> http://pastehtml.com/view/calh0sflu.html
> LINK
> 
> The page can be adapted quite quickly, I hope you like it ;)

I very like the idea and the simplicity.

My only concern is about the context. Where this box would appear? Will
people understand what they are supposed to do with the listed bugs?

Also I added Astron from the desing team. He might help with the
graphics part to well fit the LO Website branding.

I think that we are on the right way. Thanks for working on this.


Best Regards,
Petr

___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

[Libreoffice-qa] LibreOffice QA Call 2012-09-07

[Petr Mladek]

Hi,

you are all welcome on the next qa call is taking place on 2012-09-07 13UTC.

!!!It is 1 hour earlier than usual!!!

The new time has been suggested on the last meeting. Nobody obected in
the pool at http://doodle.com/ng83xh2bc4kz2ns8

Prototype agenda below. Additions welcome, although its already packed:
lots of stuff moving recently ;) 


QA Call prototype agenda:

pending action items:
   - write update scenario testcase in Litmus/MozTrap (Kendy)
   - Invite active bugwranglers to next call/QA list, CC Rainer (Bjoern)
   - merge 3.5 and 3.6 in one big bibisect repo (Bjoern)
   - recheck and tweak bibisect details (Bjoern)
   - Ping cloph if we can make that switchable to say "Bug" instead of
 "EasyHack" when explcitly requested (Bjoern)
   - new Bug Hunting Sessions (Cor)

updated schedule
   - http://wiki.documentfoundation.org/ReleasePlan
   - two weeks between RCs
   - 3.7.0 and 3.7.1 collision

structured manual testing (Yifan/Petr):
   - localization
   - 3.6.3 testing
   - presentation on the LO conference

bug wrangling (Rainer):
   - bugzilla contract improvements (Rainer)
   - last 5 hardhacks retrospedctive
   - find another 5 HardHacks
   - bug priotization, can we start for real (continue)?
 
http://nabble.documentfoundation.org/Libreoffice-qa-Bugs-prioritization-missing-pieces-td4002450.html

community building/communication:
   - new time for QA call retrospective
   - Joel's new page describing the BugTriage process
- https://wiki.documentfoundation.org/BugTriage_InProgress
   - Nino picked my mail and put excepts up as a QA mission statement
 - 
http://nabble.documentfoundation.org/Libreoffice-qa-QA-Mission-Statement-was-Re-Fwd-Re-Closing-NEEDINFO-bugs-td4002426.html
 - http://wiki.documentfoundation.org/QA#Bug_Triage.5B1.5D
 - what is the message for a newcomer?
 - is there a more clear and encouraging alternative?

Dial-in numbers for countries outside Germany can be found at:
http://www.talkyoo.net/main/telefonkonferenz_internationale_rufnummern

Dial-in numbers inside Germany are:

+49 40 18881000 (Hamburg, landline)
+49 40 95069970 (Hamburg, landline)
+49 89 60893 (Munich, landline)
+49 1570 3336000 (vistream mobile network)

Free Skype contact[*]: talkyoo_skype

Room:

Room number: 53 71 38
No participant PIN is required
All calls will be recorded
All participants can speak


Comments and additions most welcome.

[*] Talkyoo has to confirm your contact before you could call in. This
might take several hours or even days. Please, start preparation on
time.

Best Regards,
Petr

___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Closing bugs in bugzilla: fixed in master or fixed everywhere?

[Bjoern Michaelsen]

On Wed, Sep 05, 2012 at 11:39:04AM +0200, Stephan Bergmann wrote:
> On 09/05/2012 10:46 AM, Lionel Elie Mamane wrote:
> >I thought we close the bug when the fix is committed in all branches
> >where it should be, and that's what I was doing in the bugs I was
> >fixing.
> 
> That's my understanding too, setting a bug to RESOLVED/FIXED only
> once all the relevant commits have reached the intended branches.

That is quite tricky as "intended branches" is not clearly defined, and in
addition it runs counter to what mozilla defines the RESOLVED state:

 https://bugzilla.mozilla.org/page.cgi?id=fields.html

Note that there are two more bug states "after" RESOLVED in standard bugzilla:
VERIFIED and CLOSED. AFAIK the default workflow is:

RESOLVED: assumed to be fixed for some branch, not tested, not yet released
VERIFIED: verified to be fixed for some branch
CLOSED: there is a version with the fix released

In our case, as we dont really verify yet, I would suggest the following:

RESOLVED: assumed to be fixed for some branch, not tested, not yet released
CLOSED: there is a version with the fix released

Endusers should then look for CLOSED bugs (not RESOLVED unless they run
dailies), and we would automove bugs from RESOLVED->CLOSED with a release.

Best,

Bjoern

P.S.: IMHO launchpad does this a lot better with the explicit states "Fix
committed" and "Fix released".
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Closing bugs in bugzilla: fixed in master or fixed everywhere?

[Michael Stahl]

On 05/09/12 10:46, Lionel Elie Mamane wrote:
> I'd like to check if maybe I misunderstood our bugzilla handling
> standards.
> 
> I thought we close the bug when the fix is committed in all branches
> where it should be, and that's what I was doing in the bugs I was
> fixing.
> 
> But obviously, if our community standards are the other way round,
> I'll follow them.
> 
> 
> I asked because I have now lived several times now that several
> developers close a bug I'm CCed to as soon as they commit the fix to
> master.
> 
> The disadvantage of the latter method is that these bugs appear
> crossed out in the "most annoying" (and other) lists.
> 
> Its advantage, maybe, is that it goes away from said developer's
> list: their job is "finished" so it should get the hell out of their
> TODO list.

the fundamental problem is that bugzilla has a single "FIXED" state,
which is insufficient for our workflow; it should have one FIXED-x.y for
every release, so that this can be tracked properly (iirc LaunchPad
works that way).

if you set the bug to FIXED after the fix is in master, then people will
get confused because they will assume that the fix is already in the
release branch when it is not.

if you set the bug to FIXED after it is on all branches, then people
will get confused because they will assume that whatever was committed
to master doesn't fully fix the bug (a partial fix?), which is not
actually an unrealistic scenario.

currently i set the FIXED after the fix is in master, because we already
have an approximation of the FIXED-x.y states via the target:x.y
whiteboard field; those familiar with our bugzilla process will
interpret the combination of status and whiteboard target entries correctly.

> I've come to see this last point as not completely obvious, and maybe
> even wrong: when I commit a fix to master, I regard it as also my job
> to get it backported to the other branches, so my job on this bug is
> _not_ finished, so it makes sense for it to linger in my TODO list
> until the fix is everywhere it should.

yes, but we track the fix backport proposals in gerrit (or via the
legacy mechanism: mailing list), we have never used bugzilla for that.


___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Closing bugs in bugzilla: fixed in master or fixed everywhere?

[Stephan Bergmann]

On 09/05/2012 10:46 AM, Lionel Elie Mamane wrote:

I thought we close the bug when the fix is committed in all branches
where it should be, and that's what I was doing in the bugs I was
fixing.


That's my understanding too, setting a bug to RESOLVED/FIXED only once 
all the relevant commits have reached the intended branches.


Stephan
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] QA Easyhack prosposal

[reisi007]

Petr Mladek wrote
> 
> Florian Reisinger píše v Po 03. 09. 2012 v 17:47 +0200:
>> > What is the exact plan with the queries? :-)
>> 
>> If there is a question like this:
>> 
>> "Hmm, I want to help LibreOffice, but I don't know where to start..!"
>> 
>> There is no real answer for QA, except: "Have a look at bugzilla.
>> There you have to query the bugs you want to triage and then filter
>> the OS, so that you can test properly... TBC ... BTW: If you have any
>> questions, feel free to ask at this list"
>> 
>> Answer like it should IMHO be: "You can download a .ods file here:
>>  In this file, you can see bugs, which needs to be triaged. Open
>> the table with your OS and click one of the bug numbers. The queries
>> are auto-updated each hour. For more info, questions ect. ask here."
>> 
>> But it didn't work due to a bug (which should be filed ASAP).
> 
> 
> 
> I see, it makes sense. Note that Joel already created some documents,
> see "Google Documents Bug Groups" at
> https://wiki.documentfoundation.org/BugTriage_InProgress
> 
> 
> Best Regards,
> Petr
> 
> ___
> List Name: Libreoffice-qa mailing list
> Mail address: Libreoffice-qa@.freedesktop
> Change settings:
> http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
> 


Hi!

I am writing via Nabble now and really don't know how it will looke like
finally

I made a "HTMLPASTE" with the queries from this post. Hopefully it is
helpful. 
LINK
http://pastehtml.com/view/calh0sflu.html
LINK

The page can be adapted quite quickly, I hope you like it ;)

Yours

Florian

PS: The bug I was previously talking about is filed now: 
https://bugs.freedesktop.org/show_bug.cgi?id=54533

It would be really nice, if a Windows user can confirm this one
https://bugs.freedesktop.org/show_bug.cgi?id=54304




--
View this message in context: 
http://nabble.documentfoundation.org/Libreoffice-qa-QA-Easyhack-prosposal-tp4004577p4005625.html
Sent from the QA mailing list archive at Nabble.com.
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

[Libreoffice-qa] Closing bugs in bugzilla: fixed in master or fixed everywhere?

[Lionel Elie Mamane]

I'd like to check if maybe I misunderstood our bugzilla handling
standards.

I thought we close the bug when the fix is committed in all branches
where it should be, and that's what I was doing in the bugs I was
fixing.

But obviously, if our community standards are the other way round,
I'll follow them.


I asked because I have now lived several times now that several
developers close a bug I'm CCed to as soon as they commit the fix to
master.

The disadvantage of the latter method is that these bugs appear
crossed out in the "most annoying" (and other) lists.

Its advantage, maybe, is that it goes away from said developer's
list: their job is "finished" so it should get the hell out of their
TODO list.

I've come to see this last point as not completely obvious, and maybe
even wrong: when I commit a fix to master, I regard it as also my job
to get it backported to the other branches, so my job on this bug is
_not_ finished, so it makes sense for it to linger in my TODO list
until the fix is everywhere it should.

-- 
Lionel
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/