Patch status workflow (for Bugzilla)
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 For a patch that fails testing, it would look more like this: - NEW - ASSIGNED - NEEDS_SIGNOFF - FAILED QA (some obvious problem found by tester) - NEEDS_SIGNOFF (again, now that the problem is fixed - SIGNED OFF - FAILED QA (less obvious problem) - NEEDS_SIGNOFF - SIGNED OFF - PASSED QA - PATCH_PUSHED - RESOLVED Workflows could prevent jumping a status straight from ASSIGNED to PASSED QA, for example; that status could only be reached from SIGNED OFF. All the changes to these statuses are recorded in the bug reports history, so we have a record of the life cycle. I think this is what Status was initially designed to do, so we just need to leverage it. -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
Community, Workflows could prevent jumping a status straight from ASSIGNED to PASSED QA, for example; that status could only be reached from SIGNED OFF. All the changes to these statuses are recorded in the bug reports history, so we have a record of the life cycle.
I think this is what Status was initially designed to do, so we just need to leverage it. +1 ! Note we must be able to reach RESOLVED from anywhere (in case it's wontfix / duplicate / ... ) In my previous mail, I suggested to have a short circuit for trivial
Le 25/10/2011 17:17, Ian Walls a écrit : patches. Is it incompatible with preventing jumping from assigned to passed QA ? in your idea would you prevent anyone oustide from QA team to move to "passed QA" or "failed QA" ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
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
On Tue, Oct 25, 2011 at 11:36 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
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
Speaking as a third-term release maintainer (fwiw), I would like to see an additional patch status added to be known as NEEDS BACKPORTING. This will allow for a quick search by the release maintainer to see what people expect to be backported. The simple distinction between enhancement and bug disappears once an enhancement has made its way into master and/or the current stable release and bugs are filed against it, thus making it hard to know just by looking at the git bug-branch or bugzilla nomenclature. Setting the patch status to NEEDS BACKPORTING would greatly ease this job. Kind Regards, Chris
Le 26/10/2011 18:54, Chris Nighswonger a écrit :
On Tue, Oct 25, 2011 at 11:36 AM, Paul Poulain <paul.poulain@biblibre.com <mailto:paul.poulain@biblibre.com>> wrote:
> 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 Speaking as a third-term release maintainer (fwiw), I would like to see an additional patch status added to be known as NEEDS BACKPORTING. I feel it should not be a status but another field. When should we set "backporting" ? after patch pushed ? in which case ? aren't all bugfixes supposed to be backported to stable ?
This will allow for a quick search by the release maintainer to see what people expect to be backported. The simple distinction between enhancement and bug disappears once an enhancement has made its way into master and/or the current stable release and bugs are filed against it, thus making it hard to know just by looking at the git bug-branch or bugzilla nomenclature. Setting the patch status to NEEDS BACKPORTING would greatly ease this job. ...OK, got it (the answer to my question just below) So I've a proposition : all bugs should be version rel_3_6, all ENH and bugs attached to ENH should be version rel_3_8 version "master" being dedicated to ENH that still haven't made their way to rel_3_8. So you could find all bugs that needs backporting : all patches attached to rel_3_6 !
makes sense ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Wed, Oct 26, 2011 at 1:01 PM, Paul Poulain <paul.poulain@biblibre.com>wrote:
...OK, got it (the answer to my question just below) So I've a proposition : all bugs should be version rel_3_6, all ENH and bugs attached to ENH should be version rel_3_8 version "master" being dedicated to ENH that still haven't made their way to rel_3_8. So you could find all bugs that needs backporting : all patches attached to rel_3_6 !
So let us say I create an ENH request for an enhancement 'foo.' 1. I open an ENH bug against 'master' for 'foo.' 2. I do development work and attach a patch to the ENH bug. 3. The patch passes through all QA hoops (English-ism suspected). 4. The RM pushes the ENH and moves it to 'rel_3_8'. 5. A bug is discovered and a bug report opened against 'rel_3_8.' 6. <normal-bug-workflow-stuff-goes-here> Now, let us say I discover bug 'bar' in rel_3_8 and in rel_3_6. 1. I open a bug report against 'rel_3_8' for bug 'bar.' 2. I fix 'bar' and attach a patch to the bug. 3. The fix passes QA. 4. The RM pushes the patch and moves it to 'rel_3_6' if applicable. (But he has to have this knowledge somehow.) That is ok as long as it works out in practice. It would probably be better to have a way for the bug reporter to indicate *all* branches to which the bug applies, but I don't know if this is possible. Perhaps Ian can comment on that. Kind Regards, Chris
Le 26/10/2011 20:02, Chris Nighswonger a écrit : > Now, let us say I discover bug 'bar' in rel_3_8 and in rel_3_6. > > 1. I open a bug report against 'rel_3_8' for bug 'bar.' mmm... I think there are 2 sub-cases here: - library A, that uses Koha 3.6, find the bug and open it in rel_3_6 - hacker B, that uses master, find the bug and open it in master (or in rel_3_8 ? that's where there can be a confusion between master and rel_3_8) > 2. I fix 'bar' and attach a patch to the bug. > 3. The fix passes QA. > 4. The RM pushes the patch and moves it to 'rel_3_6' if applicable. (But > he has to have this knowledge somehow.) right, this point is the problem. And I feel it's not solved by this proposed workflow (not by the "need backporting as well") > That is ok as long as it works out in practice. not sure it will work well then... I think we haven't completly found the "perfect" workflow > It would probably be better to have a way for the bug reporter to > indicate *all* branches to which the bug applies, but I don't know if > this is possible. Perhaps Ian can comment on that. I've investigated bugzilla, and can't find a way to have a multiple version selection. OTH, it's easy to have another field "backport needed", that could be used for that. I don't know if it's a good idea, I just throw it... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Thu, Oct 27, 2011 at 3:19 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
Le 26/10/2011 20:02, Chris Nighswonger a écrit :
That is ok as long as it works out in practice. not sure it will work well then... I think we haven't completly found the "perfect" workflow
It would probably be better to have a way for the bug reporter to indicate *all* branches to which the bug applies, but I don't know if this is possible. Perhaps Ian can comment on that. I've investigated bugzilla, and can't find a way to have a multiple version selection. OTH, it's easy to have another field "backport needed", that could be used for that. I don't know if it's a good idea, I just throw it...
Actually, I don't have a strong personal preference for the technique of flagging a bug as needing to be backported. I am strongly desirous to see it implemented in some fashion, however. It will reduce the chances of a patch being dropped which should have been backported by simplifying the creation of reports to that effect. If an additional field raises no objections, then I say let us go ahead and implement it. Kind Regards, Chris
Chris, So, to summarize, you're looking for a status that can be set to you know which of the Patches Pushed need to be applied to the previous release? There is currently no facility for specifying multiple releases that a bug applies to. We'd have to create a custom field. The difficulty would come with making use of it. For my part, I only test bugs on master, because I only work on master. Verifying the bug in previous releases doubles or triples the work (depending on how many previous releases I'm supporting). That makes filing the bug report much less sustainable a practice, from a workflow point of view. I would think that anything that gets applied to master would be a candidate for inclusion in the stable release branch. It would be the job of the RM to determine a) if the bug applies, b) if the patch applies and c) if it's too big a new feature to include in stable. Given the quantity of code produced in a release cycle, I can see this being a massive job. Would it help to have additional Koha officer(s) responsible for verifying each Patch Pushed bug report is applicable to the stable release, and then flag it one way or the other? This would reduce the Release Maintainer's tasks to just c) above: determining if this is something that should be backported because it's a bug fix (not a new feature). Cheers, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
Hi Ian, On Thu, Oct 27, 2011 at 9:39 AM, Ian Walls <ian.walls@bywatersolutions.com>wrote:
So, to summarize, you're looking for a status that can be set to you know which of the Patches Pushed need to be applied to the previous release?
Correct.
There is currently no facility for specifying multiple releases that a bug applies to. We'd have to create a custom field. The difficulty would come with making use of it. For my part, I only test bugs on master, because I only work on master. Verifying the bug in previous releases doubles or triples the work (depending on how many previous releases I'm supporting). That makes filing the bug report much less sustainable a practice, from a workflow point of view.
The fundamental problem is differentiation between bug fixes for existing features versus bug fixes for enhancements applied either to the current dev cycle or master (they seem the same from my POV). During the 3.6.0 release cycle, we attempted to maintain the distinction between bug fixes and enhancements by this topic branch nominclature: 'new/bug_X' for bug fixes meant to apply to the current dev branch/master and to the current stable branch 'new/enh/bug_Y' for enhancements meant to apply only to the current dev branch/master. As we moved forward and the 'new/enh/bug_Y' branch was merged with the current dev branch/master, folks begin filing bug reports for bugs in 'new/enh/bug_Y.' These patches were, in turn, pushed out as 'new/bug_Z' topic branches. Given that these "new" bugs related to 'new/enh/bug_Y' were practically disassociated with 'new/enh/bug_Y' both by a different topic branch designation and a different, unassociated bug number, it became quite difficult to decide what should or should not be backported. (Other problems were caused by this as well, but those will be resolved if we can arrive at a solution for this one.)
I would think that anything that gets applied to master would be a candidate for inclusion in the stable release branch. It would be the job of the RM to determine a) if the bug applies, b) if the patch applies and c) if it's too big a new feature to include in stable. Given the quantity of code produced in a release cycle, I can see this being a massive job.
Perhaps we have not clearly established the job of the RMaint then. You may recall that when I took up the 3.2.x RMaint job, I specified that the burden of ensuring clean application of a given patch to the current stable branch is the job of the submitter rather than the RMaint. This was agreed to by silent consent. [1] I have followed this policy throughout the 3.4.x RMaint cycle as well. Typically if a commit a) is designated as a 'new/bug_X' topic branch *and* b) does not apply cleanly to the current stable branch, I post a request to the submitter to rebase and reformat the patch to apply over the current stable branch *if it should.* This places the burden of determining if the patch should, indeed, be backported on the author. (Which is where it should be IMHO. ie. When I mark a bug as assigned to me, I accept the responsibility of ensuring I fix it in all currently supported releases as well as master. Otherwise, I have not truly fixed the bug.) If this is not what works the best for the majority if the development community, then we need to come up with a work flow which best fits and implement it. Any significant work flow alterations will require more bodies to help with the RMaint process. Based on the response to the call for RMaint volunteers for the 3.6.x branch, I'm guessing we'll have a pretty hard time coming up with the more bodies. ;-) That said, It seems much simpler to me to just add/modify a field in BZ to allow the author of a given bugfix to indicate which branches the fix should apply to. If the fix needs to be reformatted to apply over multiple branches, the author can attach multiple patches to the bug report, indicating which patch applies to which branch. Give the capabilities of GIT, this should not greatly disrupt the developer's work flow. (While I'm wishing... it would really be cool to have a hook which updated the bug with the commit id when it was pushed to whichever branch...) Maybe the entire problem is overblown from my prospective, so I'm certainly open to correction. But with two RMaint cycles under the belt and a staring a third down the throat (Englishism here), I'd love to get this whittled down to size. [1] http://tinyurl.com/3facmhg Kind Regards, Chris
Now that KohaCon is past, I'd like to see us come to a resolve on this issue. On Thu, Oct 27, 2011 at 10:48 AM, Chris Nighswonger <cnighswonger@foundations.edu> wrote:
Hi Ian,
On Thu, Oct 27, 2011 at 9:39 AM, Ian Walls <ian.walls@bywatersolutions.com> wrote:
So, to summarize, you're looking for a status that can be set to you know which of the Patches Pushed need to be applied to the previous release?
Correct.
There is currently no facility for specifying multiple releases that a bug applies to. We'd have to create a custom field. The difficulty would come with making use of it. For my part, I only test bugs on master, because I only work on master. Verifying the bug in previous releases doubles or triples the work (depending on how many previous releases I'm supporting). That makes filing the bug report much less sustainable a practice, from a workflow point of view.
The fundamental problem is differentiation between bug fixes for existing features versus bug fixes for enhancements applied either to the current dev cycle or master (they seem the same from my POV).
During the 3.6.0 release cycle, we attempted to maintain the distinction between bug fixes and enhancements by this topic branch nominclature:
'new/bug_X' for bug fixes meant to apply to the current dev branch/master and to the current stable branch
'new/enh/bug_Y' for enhancements meant to apply only to the current dev branch/master.
As we moved forward and the 'new/enh/bug_Y' branch was merged with the current dev branch/master, folks begin filing bug reports for bugs in 'new/enh/bug_Y.' These patches were, in turn, pushed out as 'new/bug_Z' topic branches. Given that these "new" bugs related to 'new/enh/bug_Y' were practically disassociated with 'new/enh/bug_Y' both by a different topic branch designation and a different, unassociated bug number, it became quite difficult to decide what should or should not be backported. (Other problems were caused by this as well, but those will be resolved if we can arrive at a solution for this one.)
I would think that anything that gets applied to master would be a candidate for inclusion in the stable release branch. It would be the job of the RM to determine a) if the bug applies, b) if the patch applies and c) if it's too big a new feature to include in stable. Given the quantity of code produced in a release cycle, I can see this being a massive job.
Perhaps we have not clearly established the job of the RMaint then.
You may recall that when I took up the 3.2.x RMaint job, I specified that the burden of ensuring clean application of a given patch to the current stable branch is the job of the submitter rather than the RMaint. This was agreed to by silent consent. [1] I have followed this policy throughout the 3.4.x RMaint cycle as well.
Typically if a commit a) is designated as a 'new/bug_X' topic branch *and* b) does not apply cleanly to the current stable branch, I post a request to the submitter to rebase and reformat the patch to apply over the current stable branch *if it should.* This places the burden of determining if the patch should, indeed, be backported on the author. (Which is where it should be IMHO. ie. When I mark a bug as assigned to me, I accept the responsibility of ensuring I fix it in all currently supported releases as well as master. Otherwise, I have not truly fixed the bug.)
If this is not what works the best for the majority if the development community, then we need to come up with a work flow which best fits and implement it. Any significant work flow alterations will require more bodies to help with the RMaint process. Based on the response to the call for RMaint volunteers for the 3.6.x branch, I'm guessing we'll have a pretty hard time coming up with the more bodies. ;-)
That said, It seems much simpler to me to just add/modify a field in BZ to allow the author of a given bugfix to indicate which branches the fix should apply to. If the fix needs to be reformatted to apply over multiple branches, the author can attach multiple patches to the bug report, indicating which patch applies to which branch. Give the capabilities of GIT, this should not greatly disrupt the developer's work flow. (While I'm wishing... it would really be cool to have a hook which updated the bug with the commit id when it was pushed to whichever branch...)
Maybe the entire problem is overblown from my prospective, so I'm certainly open to correction. But with two RMaint cycles under the belt and a staring a third down the throat (Englishism here), I'd love to get this whittled down to size.
[1] http://tinyurl.com/3facmhg
Kind Regards, Chris
Poke. On Thu, Nov 10, 2011 at 11:49 AM, Chris Nighswonger <cnighswonger@foundations.edu> wrote:
Now that KohaCon is past, I'd like to see us come to a resolve on this issue.
On Thu, Oct 27, 2011 at 10:48 AM, Chris Nighswonger <cnighswonger@foundations.edu> wrote:
Hi Ian,
On Thu, Oct 27, 2011 at 9:39 AM, Ian Walls <ian.walls@bywatersolutions.com> wrote:
So, to summarize, you're looking for a status that can be set to you know which of the Patches Pushed need to be applied to the previous release?
Correct.
There is currently no facility for specifying multiple releases that a bug applies to. We'd have to create a custom field. The difficulty would come with making use of it. For my part, I only test bugs on master, because I only work on master. Verifying the bug in previous releases doubles or triples the work (depending on how many previous releases I'm supporting). That makes filing the bug report much less sustainable a practice, from a workflow point of view.
The fundamental problem is differentiation between bug fixes for existing features versus bug fixes for enhancements applied either to the current dev cycle or master (they seem the same from my POV).
During the 3.6.0 release cycle, we attempted to maintain the distinction between bug fixes and enhancements by this topic branch nominclature:
'new/bug_X' for bug fixes meant to apply to the current dev branch/master and to the current stable branch
'new/enh/bug_Y' for enhancements meant to apply only to the current dev branch/master.
As we moved forward and the 'new/enh/bug_Y' branch was merged with the current dev branch/master, folks begin filing bug reports for bugs in 'new/enh/bug_Y.' These patches were, in turn, pushed out as 'new/bug_Z' topic branches. Given that these "new" bugs related to 'new/enh/bug_Y' were practically disassociated with 'new/enh/bug_Y' both by a different topic branch designation and a different, unassociated bug number, it became quite difficult to decide what should or should not be backported. (Other problems were caused by this as well, but those will be resolved if we can arrive at a solution for this one.)
I would think that anything that gets applied to master would be a candidate for inclusion in the stable release branch. It would be the job of the RM to determine a) if the bug applies, b) if the patch applies and c) if it's too big a new feature to include in stable. Given the quantity of code produced in a release cycle, I can see this being a massive job.
Perhaps we have not clearly established the job of the RMaint then.
You may recall that when I took up the 3.2.x RMaint job, I specified that the burden of ensuring clean application of a given patch to the current stable branch is the job of the submitter rather than the RMaint. This was agreed to by silent consent. [1] I have followed this policy throughout the 3.4.x RMaint cycle as well.
Typically if a commit a) is designated as a 'new/bug_X' topic branch *and* b) does not apply cleanly to the current stable branch, I post a request to the submitter to rebase and reformat the patch to apply over the current stable branch *if it should.* This places the burden of determining if the patch should, indeed, be backported on the author. (Which is where it should be IMHO. ie. When I mark a bug as assigned to me, I accept the responsibility of ensuring I fix it in all currently supported releases as well as master. Otherwise, I have not truly fixed the bug.)
If this is not what works the best for the majority if the development community, then we need to come up with a work flow which best fits and implement it. Any significant work flow alterations will require more bodies to help with the RMaint process. Based on the response to the call for RMaint volunteers for the 3.6.x branch, I'm guessing we'll have a pretty hard time coming up with the more bodies. ;-)
That said, It seems much simpler to me to just add/modify a field in BZ to allow the author of a given bugfix to indicate which branches the fix should apply to. If the fix needs to be reformatted to apply over multiple branches, the author can attach multiple patches to the bug report, indicating which patch applies to which branch. Give the capabilities of GIT, this should not greatly disrupt the developer's work flow. (While I'm wishing... it would really be cool to have a hook which updated the bug with the commit id when it was pushed to whichever branch...)
Maybe the entire problem is overblown from my prospective, so I'm certainly open to correction. But with two RMaint cycles under the belt and a staring a third down the throat (Englishism here), I'd love to get this whittled down to size.
[1] http://tinyurl.com/3facmhg
Kind Regards, Chris
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/
Marcel, I think we can agree that using QA Contact is a good idea. I'd be very much surprised if anyone objects to that (feel free to prove me wrong). As far as trivial bug signoffs, I think the QA team's act of accepting an author-signoff would be equivalent to signing off themselves (we are signing off on the signoff). The only difference would be allowing people to mark trivial bugs as "signed off" directly, instead of after they were set to "needs signoff".... and the QA team busting a report back down to "needs signoff" if they don't feel it's trivial. I'm amenable to allowing this, at least for 3.8, to see if it works. If we find people are abusing it to get non-trivial bugs looked at by QA sooner than they should, then we can revoke the issue. What do others think of this provision? I'll ask those in Mumbai directly on Friday at the hackfest, but any opinions before then will help frame the discussion. -Ian On Wed, Nov 2, 2011 at 10:58 AM, Marcel de Rooy <M.de.Rooy@rijksmuseum.nl>wrote:
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/
-- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
participants (4)
-
Chris Nighswonger -
Ian Walls -
Marcel de Rooy -
Paul Poulain