No problem with moving the existing patch statuses to Status. But just another thought: isn’t patch status actually a status that should be on the level of attachment? Sometimes we have reports with several patches and it may happen that not all active patches are on the same patch status level. If we make a change now, we could look at those situations..

About status “In Discussion”: Discussion should be in the beginning of development and could be anywhere later on. As I understand this point now, this relates to a patch with larger impact that could pass qa but may not have community consensus. Just setting the status to In Discussion will not help; mailing the list while the status remains as-is could work as well. If such a patch meets qa standards and would reach Passed QA, it becomes a problem for the RM (even more if the patch came from him ;). The RM could again ask for community response before pushing that patch. In conclusion, I would not per se add this new status.

In the particular case of 7167, I would say that the QA team could ask for more signoff’s (instead of the current Failed QA). This could also be a new status (at attachment level)? If a patch reaches signoff but QA feels that one or two additional signoff’s would be beneficial, QA could set the status “Needs additional signoff”.

Van: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] Namens Ian Walls
Verzonden: vrijdag 6 januari 2012 15:37
Aan: koha-devel@lists.koha-community.org
Onderwerp: [Koha-devel] Proposal to change Bugzilla Status and Patch Status values

Fellow Koha-ckers,


A comment on bug 7167 (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167) has gotten my interest re-awakened about a proposed Bugzilla revision that had been floated earlier this release cycle.

I'd like to remove Patch Status, and move all those values to the regular Status field.  This has the following advantages:

• Status is a built-in field, so it's got much richer support in Bugzilla.  For example, status workflows can be added.  Patch Status is a custom field, and is just a list of values
• We would no longer lose the Priority value of a bug by having to set it to Patch Sent in order to get the Patch Status values visible
• Statuses can be updated as part of submitting an attachment like a patch, streamlining the patch submission process (fewer clicks to keep all the fields up to date).

I'd also like to add a new status, "In Discussion", for bug reports that have deeper procedural, philsophical or technical implications outside that of mere coding (bug 7167 being an example).

We're not using Status for anything else, so there is no trade-off there.  This is really how the Status field is meant to be used.  We will, however, have to rebuild the canned searches that look for patches that Need Signoff, are Signed Off, and are Passed QA/Failed QA.

The other difficulty of this proposal is that we'll need to turn off automatic bug emails for a bit while we make the bulk changes to the Patch Statuses; otherwise, we'll all get spammed to high heaven with meaningless updates when the migration occurs.

What do people think?  Does this sound like a reasonable change to make?  Any objections?

Cheers,

-Ian

-- Ian Walls

Lead Development Specialist
ByWater Solutions
ALA Midwinter Booth #2048
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls@bywatersolutions.com
Twitter: @sekjal