[Koha-devel] Bugzilla changes/improvements

[Paul Poulain]

Le 24/10/2011 18:46, Ian Walls a écrit :
> *Versions: * I think the versions in this list should correspond to the
> main branches on the Koha Git repo.  So, we'd have 3.2.x, 3.4.x, 3.6.x
> and master.  A bug report should be connected to the most current
> version (if it's a problem in 3.6.x and master, report is as master).
It's already the case (see the link i've provided in my initial mail)
Report of bugs NEW or ASSIGNED :
Rel_3_8 	68
master 	1031
rel_3_0 	97
rel_3_2 	132
rel_3_4 	327
rel_3_6 	129
unspecified 	150
Total 	1934

=> we can discard all "old" versions.

> For enhancements, I say we report them against master.  Then, when the
> feature freeze rolls around, we take everything that has submitted code
> so far, and move it 3.8.x.  If it makes it, great, if it doesn't, after
> release it gets moved back to master.
that makes sense. does anyone disagree ?
  * if you report a bug => report it with the version you're
encountering the problem
  * if you report an enhancement => report it against master, the RM
will move to rel_x_x when the patch is pushed.

> We can delete old version values in BZ, but there isn't a way to
> obsolete them like there are with other field statuses.  I think if we
> find anything on a version older than 3.0.x, we should probably:
>    a) verify it's still relevant
>    b) remove or re-report it in the current context
There were only 2, i took care of them.

> *Component*:  I'm with Owen that more is better than less, here.  Each
> component controls the default Assignee, and having a more
> finely-grained default assignee's list will keep folks from getting
> overloaded with bug assignments (in theory).
OK, i'm convinced. But we still could discard a few (about &
importedbugs that have no entries, and bugs.koha-community.org &
translate/koha-community.org.

> The universal problem here being, of course, that while folks can be
> ASSIGNED a bug, we can never guarantee they'll DO anything about it. 
> We're all free agents, and cannot enforce any sort of assignment or
> timetable outside on a community-wide scale.
My proposition is :
  * keep "NEW" by default
  * when someone want to endorse a bug (ie: and say "i'll do
something"), set ASSIGNED.

So by looking at "NEW" bugs, we will know what is orphan and waiting for
a volunteer, and looking at old ASSIGNED, we could send a reminder to
assignees to ask for confirmation they plan to do something (and if they
say "no", we switch back to "NEW")

> *Status*:  We don't use the regular status field much at all, except to
> mark the patch as "resolved".  Why don't we put the Patch Status into
> the regular ol' Status field?  That would have a couple advantages:
> 
>   * Easier searching, since it's a default value, not a custom value
>   * We can enable Workflows between statuses
>   * We no longer have the dependency on Priority to control the display
>     of this critical value
> 
> I'll write up more about the potential for the Workflows, and how I hope
> the QA team can fit into that, in another post.

I'm not sure I understand.

> *Priority:*  I agree with Owen that this is pretty arbitrary... it may
> not be useful to us right now.
OK. But the "patch sent" has nothing to do in "priority". The good
solution would be to have "patch status" always displayed, with value
"--" to say no patch.
It's so true that, if you remove the "patch sent" and keep the failed QA
(for example), the patch will still appear in the "failed QA" report !

> *Severity:*  we should keep, since it highlights issues in red and bold
> if they're critical or blocker
Agreed.

> *Hardware/OS*:  should keep, as well, though they are very seldom
> useful.  A little cluttersome, but a handy categorization for those few
> times when it's relevant.
If you look at my initial mail and the link with report, you'll see it's
never useful !
The more I think of it, the more I feel we need a "browser" field (IE /
Firefox / Chrome / Opera / ... / Other), don't care of Hardware. OS
maybe relevant for some very specific cases where the server is
something strange (like HP-UX or Unix). But we don't have any bug where
this information is usefull, so it's only theoric.

> *QA Contact:*  I'd like to move the 'bugs at lists.koha-community.org
> <mailto:bugs at lists.koha-community.org>' from being the Default QA
> contact to a Global Watcher.  This makes more sense to me, since it's
> always supposed to report on things, and if someone changed the QA
> contact on a bug report, the list would no longer get notified on update.

+1

> I think we should also start talking about making BZ a more central
> component in our Patch Submission Procedures.  I know I don't use the
> patches list-serv now as anymore than a notification means.  Everything
> I write, test and pass QA is done on Bugzilla (either through Git BZ or
> manually).  I think that's the way with most of our other developers, as
> well

+1 (and i've updated the wiki that way a few hours ago)

thread to be continued...

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08