Re: [Libreoffice-qa] Closing bugs in bugzilla: fixed in master or fixed everywhere?
On Wed, Sep 05, 2012 at 09:24:41PM +0200, Bjoern Michaelsen wrote: On Wed, Sep 05, 2012 at 06:30:30PM +0200, Lionel Elie Mamane wrote: 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? Yeah, a query would work, you make me realise that. However, just going to the webpage and seeing how much in the Depends on area is crossed out and how much is not is more immediate, IMHO. (Yes, it make give too much, because that bug is fixed in that branch and waiting for action on another branch, but I prefer to err on the side of overevaluation instead of underevaluation). So, different people have given arguments in both directions. IMHO, the advantages of doing it (one way or the other) consistently outweigh the advantages of either direction; thus I'd like us to be consistent as a community on this question. So how do we go from here to establish a community standard? -- 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] Closing bugs in bugzilla: fixed in master or fixed everywhere?
Hi, On Wed, Sep 05, 2012 at 10:46:24AM +0200, 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. To me, RESOLVED/FIXED means simply the bug is fixed. Which it is as soon as I push the fix into 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. Right. Because the next step, review of my proposed fix for inclusion in older branch(es), depends on _other_ developers. 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, Nobody has claimed otherwise. 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. But this part is handled separately from bugzilla, via the ML (or gerrit). D. ___ 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?
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?
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?
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=37361hide_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] Closing bugs in bugzilla: fixed in master or fixed everywhere?
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=37361hide_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/
