[Koha-devel] Bugzilla changes/improvements

Mon Oct 24 18:46:29 CEST 2011

Everyone,

First off, Paul, thanks for getting this rolling.  I've been thinking a lot
about optimizing our Bugzilla set up to match today's current practices.
ByWater Solutions uses Bugzilla internally for partners support needs, so
I'm pretty well-versed in some of the configuration changes that we can
make.  Here's my take on Paul's comments:

*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).

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.

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

*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).

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.

Perhaps the issue with "which component to I choose" could be mollified with
some kind instructions saying "It doesn't really matter, it'll get to the
right place!  Just be clear in your report"

*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.

*Priority:*  I agree with Owen that this is pretty arbitrary... it may not
be useful to us right now.

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

*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.

*QA Contact:*  I'd like to move the '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.

The QA Contact field can then be used assign the QA portion of the patch
submission process to one of the three QA team members (myself, Marcel de
Rooy and Jonathan Druart).  This'll make it easier for us to divide the
work, and make sure that work submitted by one company is cross-checked by
another.

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

More soon....

-Ian

On Mon, Oct 24, 2011 at 11:52 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Hello koha-devel,
>
> I'm doing a checking of our bugzilla usage. I've added some pages on the
> wiki about submitting a patch, and have some questions/propositions.
> Please give me your opinion about them. The propositions that won't be
> agreed by all (unanimity) will be discussed in a later IRC meeting.
>
> Here they are, in random order.
>
> • what's the difference between master and Rel_3_8 versions ? I feel
> "master" should not be used for bugs, only for ENH, and, when a patch is
> submitted for an ENH, it should be attached to "next planned version"
> (ie : Rel_3_8 those days)
>
> • The priority is used to set "patch sent". This is a problem as we
> completly loose Priority field usage. A solution would be to have a
> patch status "patch sent" added, have the patch status always visible,
> and keep priority for what it's supposed to be, the priority. Patch
> status could then be "--" (patch not sent), "needs signoff", "does not
> apply"... as we have today.
>
> • QA contact : could we do a better use of this field ? I know Ian & QA
> team are working/thinking to this question, so it's here just for reminder.
>
> • Signed-off & passed QA = The signature and the QA process could be in
> any order: if a patch does not meet our QA rules, there's no need to
> test it if the QA team sees it. So maybe we have a field for "QA status"
> (-- / passed QA / failed) and the patch status for sign-off (-- / signed
> off / does not apply)
>
> • For instance, I don't know how we could keep track of the "patch
> submitter" ? do we want/need ? I throw an open question here.
>
> • bug status : it's NEW/ASSIGNED/RESOLVED and it's not really correctly
> used.
> Many bugs stay "new" = as of today, 12 bugs have a patch for version
> Rel_3_8 and are still marked "new". They should be "assigned". I propose
> to enforce the use of the "ASSIGNED". This question is connected to the
> question of the use of the default assignee i've asked a few weeks ago.
>
> • Components : I proposed to clean them a while ago. Now I have concrete
> & detailled propositions.
>
> http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=component&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap
> I've checked all entries with less than 30 bugs open, and propose
> something for each of them. The global idea is to have component entries
> close from modules we have in Koha.
> ∘ About, importedbugs, = no bugs, drop those entries.
> ∘ Authentication = 19 bugs, move them to "architecture, Internals and
> plumbing"
> ∘ Browser compatibility = 10 bugs, move them to "Architecture internals
> and plumbing" or "templates"
> ∘ bugs.koha-community.org = 2 bugs, move them to "websites, mailing
> lists,..."
> ∘ contribs.koha-community.org  = 1 bug, move it to "websites, mailing
> lists,..."
> ∘ Developer documentation = 5 bugs, move them to "Architecture,
> internals and plumbing"
> ∘ Documentation = 11 bugs, keep them here, interesting for Nicole & doc
> writers
> ∘ Holidays = 2 bugs, move them to "Tools"
> ∘ Installation and upgrade = merge "command line" and "web-based" (20
> and 24 repectively)
> ∘ Label printing = 27 bugs, move them to "Tools"
> ∘ MARC authority and MARC bibliographic (26 and 27 repectively) = we
> could merge them, not sure, i'm not proposing that, your
> opinion/thoughts about that ?
> ∘ MARC bibliographic staging/import = 14 bugs, move them to tools
> ∘ Self-checkout = 4, move them to "circulation"
> ∘ SIP2 = 18, move them to "circulation" or "Architecture, plumbing"
> ∘ Test suite = only 3, but keep them as we want to improve test
> coverage, it's to encourage ppl !
> ∘ Transaction logs = 5, move them to "Tools"
> ∘ translate.koha-community.org = 2, move them to "Websites, Mailing
> lists,..."
> ∘ Z39.50, SRU, OpenSearch = 14, move them to searching
>
> • The "hardware" field is useless.
>
> http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=rep_platform&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap
> 12 are reported "MacIntosh", and not related to Mac specifically, others
> are PC/All/Other.
> I propose we remove it completly from the forms (Can we ? Use it for
> something else & what ?)
>
> • The 'OS' field is useless.
>
> http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=op_sys&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap
> ∘ 5 bugs are "windows", and 3 are "others", it does not seem they are
> relevant.
> I propose we remove it completly from the forms (Can we ? Use it for
> something else & what ?)
>
> • Version field : there are many, only a few are used :
>
> http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=version&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap
> Could we hide all versions that are unsupported and have no bug opened
> now ? (all 1.x & 2.x versions, many 3.0.x and 3.2.x versions)
>
>
> --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20111024/86765eb6/attachment-0001.htm>