Have been reading a lot of mails about patch status workflow little bit late. But did we reach consensus on some of these points yet? Status, patch status, version, importance? I would be in favor of using the global watcher and freeing up QA Contact. I would hesitate to change too many fields now, as the procedure in 3.6 was clear. Changing several fields could result in a lot of erroneous statuses, set by unaware reporters. For instance, even making the distinction between master and rel_3_8 will not be intuitive for everyone (enh to master, bugs to rel_3_8). A last question, as Paul mentioned trivial patches too somewhere: Could we allow someone to signoff on his own patch for really trivial patches (touching comments; fixing typos; small obvious bugs pertaining to a few lines; etc.) ? QA could make the decision then to let it pass QA or reset the status to Needs Signoff, asking for an additional signoff? Would we risk getting too much not-trivial self-signoffs ? Marcel ________________________________________ Van: koha-devel-bounces@lists.koha-community.org [koha-devel-bounces@lists.koha-community.org] namens Paul Poulain [paul.poulain@biblibre.com] Verzonden: dinsdag 25 oktober 2011 17:36 Aan: koha-devel@lists.koha-community.org Onderwerp: Re: [Koha-devel] Patch status workflow (for Bugzilla) Le 25/10/2011 17:17, Ian Walls a écrit :
Community,
As I'd mentioned in a previous thread, I think we should consider removing the custom attribute "patch status" from Bugzilla, and keeping track of this information in the regular Status attribute. This has several 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
The Workflows allow us to specify how tickets are allowed to change status, from which to which. Here's an example workflow:
* NEW (default for all incoming tickets) * ASSIGNED (to the developer working on it) * NEEDS_SIGNOFF (once a patch has been submitted) * SIGNED_OFF (after signoff) * PASSED_QA (once QA'ed successfully) * PATCH_PUSHED * RESOLVED
other potential problem : when moving all existing bugs/patches to those new status, we will set the "last modification date" to "today" right ? can't it be the source of some glitch/pain/problem/surprise/misunderstanding ? (just asking) -- 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/