[Koha-devel] FW: Patch status workflow (for Bugzilla)

Marcel de Rooy M.de.Rooy at rijksmuseum.nl
Wed Nov 2 15:58:23 CET 2011


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 at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Paul Poulain [paul.poulain at biblibre.com]
Verzonden: dinsdag 25 oktober 2011 17:36
Aan: koha-devel at 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 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/


More information about the Koha-devel mailing list