Hi to all, this questyion is about Bugzilla workflow. The bug 7245 is fixed, code is updated in HEAD and in 3.6.x But the status is ASSIGNED and no 'RESOLVED'. Why ? Bye Zeno Tajoli -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer
On 12 January 2012 21:55, Zeno Tajoli <tajoli@cilea.it> wrote:
Hi to all,
this questyion is about Bugzilla workflow. The bug 7245 is fixed, code is updated in HEAD and in 3.6.x
But the status is ASSIGNED and no 'RESOLVED'.
Why ?
Quite simple really, the bug submitter has not tested and marked it resolved. We are at step 8 of http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow (Bug closer: the person who checked that the bug is now fixed. Can be the reporter, it's preferred that the patch writer is not the closer.) So if you can confirm it is resolved and fixed, you can mark it so Chris
Le 12/01/2012 09:59, Chris Cormack a écrit :
On 12 January 2012 21:55, Zeno Tajoli <tajoli@cilea.it> wrote:
Why ?
Quite simple really, the bug submitter has not tested and marked it resolved. We are at step 8 of http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow
(Bug closer: the person who checked that the bug is now fixed. Can be the reporter, it's preferred that the patch writer is not the closer.)
So if you can confirm it is resolved and fixed, you can mark it so And there are tons of bugs in this status, so if you (zeno) can dedicate time to this task, you're welcomed ;-) There is a "Patch pushed" query, that you can add to your footer (bugzilla > Preferences > saved query > check "Patch pushed" It shows 437 bugs "pushed but not yet closed"
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Chris Cormack <chris@bigballofwax.co.nz>
Quite simple really, the bug submitter has not tested and marked it resolved. We are at step 8 of http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow
(Bug closer: the person who checked that the bug is now fixed. Can be the reporter, it's preferred that the patch writer is not the closer.)
One of two things seems a bit confusing there: Maybe the "bug closer" is slightly misnamed and should be replaced by "bug reporter or QA worker" to make it clear who should do this because I think many of us are used to patch writers closing bugs in other projects. Maybe the task is misdescribed and the patch writer should set it RESOLVED, then the bug closer sets it to VERIFIED, which would be more like as described in http://bugs.koha-community.org/bugzilla3/page.cgi?id=fields.html Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/
Le 12/01/2012 16:41, MJ Ray a écrit :
Maybe the task is misdescribed and the patch writer should set it RESOLVED, then the bug closer sets it to VERIFIED, which would be more like as described in http://bugs.koha-community.org/bugzilla3/page.cgi?id=fields.html So the workflow would be: NEW > Patch sent > signed-off > passed QA > pushed > resolved > fixed ? I'm OK with it, but i've a question: as the RM set "pushed", couldn't he move to "resolved" as well, the reporter or someone else saying "fixed". And the workflow would finally be: NEW > Patch sent > signed-off > passed QA > resolved (pushed) > fixed
many/most projects work this way I think. Once a patch has been applied, the problem is resolved from dev point of view. The reporter just confirm by marking "FIXED". Question to RMaint = is it worth having one more status I would set, to tell you, after pushing on master, that you should/must apply the bug also on stable ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Thu, Jan 12, 2012 at 10:51 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
Question to RMaint = is it worth having one more status I would set, to tell you, after pushing on master, that you should/must apply the bug also on stable ?
That would be fantastic! I'll even buy you lunch sometime for it. Sorry for being out of the loop for the past few weeks.... my schedule is super-busy right now. Kind Regards, Chris
On Thu, Jan 12, 2012 at 10:51 AM, Paul Poulain <paul.poulain@biblibre.com <mailto:paul.poulain@biblibre.com>> wrote: Question to RMaint = is it worth having one more status I would set, to tell you, after pushing on master, that you should/must apply the bug also on stable ? That would be fantastic! I'll even buy you lunch sometime for it. Sorry for being out of the loop for the past few weeks.... my schedule is super-busy right now. Ian is about to change the workflow next week-end. So Ian => can you add
Le 12/01/2012 18:00, Chris Nighswonger a écrit : this as well ? Chris_n = if you meet ian 1st, then i'm OK if you buy him a lunch instead of me ;-) The other option would be to come to the hackfest in Europe in March (that's a general reminder ;-) Some ppl have expressed the idea to come, but there are many many chairs that are waiting for you as of today ;-) ) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Paul Poulain <paul.poulain@biblibre.com>
And the workflow would finally be: NEW > Patch sent > signed-off > passed QA > resolved (pushed) > fixed
many/most projects work this way I think. Once a patch has been applied, the problem is resolved from dev point of view. The reporter just confirm by marking "FIXED".
I don't mind but I would really like the bugzilla workflow to match the intended workflow. It confuses me a bit that we move into the patch status attribute and the person who sets the final state in that (the RM, patch pushed) does not change the main status at all... and I suspect I am not alone if there are many bugs stuck in the Assigned+Pushed state. This would have the benefit of making the bugzilla-produced report tables more useful, too. A backport-needed status may be a good move for that, too. Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/
participants (5)
-
Chris Cormack -
Chris Nighswonger -
MJ Ray -
Paul Poulain -
Zeno Tajoli