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/
_______________________________________________
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/