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/
