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:
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@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@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@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@bywatersolutions.com
Twitter: @sekjal