Hello devs, I would like to suggest a simplification of the integration workflow for some patches. Indeed the signoff queue is back to a critical threshold (200) and the signoffer's activity is very low. Being part of the QA team, I try not to test patches in the Needs Signoff queue as I loose my QA token. The active members of the QA team are very limited and when we do SO, this increase the QA queue. As a result there is less chances my patches are QAed as there are more and more patches in the QA queue. It's a bit egoistic, but we all have the same problem. So I suggest that for some patches, the ones with a minor severity, small or template changes could, IMO, bypass the signoff step. I would like to discuss this during the next dev meetings, but I am keen to get some feedbacks on this idea. Cheers, Jonathan PS: If I am correct, we already have discussed about that previously.
So I suggest that for some patches, the ones with a minor severity, small or template changes could, IMO, bypass the signoff step.
This idea comes up every now and then (just as we see our queues growing and slinking again..). I would suggest to make the Complexity field mandatory. Some people do not fill it. And if the Complexity== Trivial or String, test it yourself and put your own signoff below. Everything above Trivial needs another signoff. Marcel
I should have added that I can engage my own responsibility and will provide a fix as quickly as possible if the patch introduced a regression or was buggy. 2015-08-20 15:03 GMT+01:00 Marcel de Rooy <M.de.Rooy@rijksmuseum.nl>:
So I suggest that for some patches, the ones with a minor severity, small or template changes could, IMO, bypass the signoff step.
This idea comes up every now and then (just as we see our queues growing and slinking again..). I would suggest to make the Complexity field mandatory. Some people do not fill it. And if the Complexity== Trivial or String, test it yourself and put your own signoff below. Everything above Trivial needs another signoff.
Marcel _______________________________________________ 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/
I'd say it should be evaluated on a per-bug/patch basis. Overall I agree, but let the QAM and the RM have the final word about the bugs qualifying for this proposed fast-track treatment. I will add this to tomorrow's agenda for formally talking about this. 2015-08-20 12:44 GMT-03:00 Jonathan Druart < jonathan.druart@bugs.koha-community.org>:
I should have added that I can engage my own responsibility and will provide a fix as quickly as possible if the patch introduced a regression or was buggy.
2015-08-20 15:03 GMT+01:00 Marcel de Rooy <M.de.Rooy@rijksmuseum.nl>:
So I suggest that for some patches, the ones with a minor severity, small or template changes could, IMO, bypass the signoff step.
This idea comes up every now and then (just as we see our queues growing and slinking again..). I would suggest to make the Complexity field mandatory. Some people do not fill it. And if the Complexity== Trivial or String, test it yourself and put your own signoff below. Everything above Trivial needs another signoff.
Marcel _______________________________________________ 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/
I can totally agree with this bit I would suggest it's best for the qa'er to be the final determiner of complexity. Kyle Sent from my phone. Please excuse my brevity. On Aug 20, 2015 10:03 AM, "Marcel de Rooy" <M.de.Rooy@rijksmuseum.nl> wrote:
So I suggest that for some patches, the ones with a minor severity, small or template changes could, IMO, bypass the signoff step.
This idea comes up every now and then (just as we see our queues growing and slinking again..). I would suggest to make the Complexity field mandatory. Some people do not fill it. And if the Complexity== Trivial or String, test it yourself and put your own signoff below. Everything above Trivial needs another signoff.
Marcel _______________________________________________ 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/
+1 On those 200, how many have a severity of trivial or lower ? Le 20/08/2015 15:51, Jonathan Druart a écrit :
Hello devs,
I would like to suggest a simplification of the integration workflow for some patches. Indeed the signoff queue is back to a critical threshold (200) and the signoffer's activity is very low.
Being part of the QA team, I try not to test patches in the Needs Signoff queue as I loose my QA token. The active members of the QA team are very limited and when we do SO, this increase the QA queue. As a result there is less chances my patches are QAed as there are more and more patches in the QA queue. It's a bit egoistic, but we all have the same problem.
So I suggest that for some patches, the ones with a minor severity, small or template changes could, IMO, bypass the signoff step.
I would like to discuss this during the next dev meetings, but I am keen to get some feedbacks on this idea.
Cheers, Jonathan
PS: If I am correct, we already have discussed about that previously. _______________________________________________ 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/
-- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers@biblibre.com
I'd be ok testing Jonathan's suggestion of moving to Passed QA directly for for bugs with'string change' or 'trivial' complexity. QA and RM could still reset to 'Needs signoff' for a second opinion when they feel it's needed. I think the patch complexity can only be set after developing a patch - so making it mandatory might not work as a technical solution here. Maybe we can encourage the use of the field a bit more? Currently for most of the patches in the 'Needs Sign-off' queue the patch complexity is not set - so it's hard to tell how many patches this change would affect. Katrin Am 25.08.2015 um 14:57 schrieb Fridolin SOMERS:
+1
On those 200, how many have a severity of trivial or lower ?
Le 20/08/2015 15:51, Jonathan Druart a écrit :
Hello devs,
I would like to suggest a simplification of the integration workflow for some patches. Indeed the signoff queue is back to a critical threshold (200) and the signoffer's activity is very low.
Being part of the QA team, I try not to test patches in the Needs Signoff queue as I loose my QA token. The active members of the QA team are very limited and when we do SO, this increase the QA queue. As a result there is less chances my patches are QAed as there are more and more patches in the QA queue. It's a bit egoistic, but we all have the same problem.
So I suggest that for some patches, the ones with a minor severity, small or template changes could, IMO, bypass the signoff step.
I would like to discuss this during the next dev meetings, but I am keen to get some feedbacks on this idea.
Cheers, Jonathan
PS: If I am correct, we already have discussed about that previously. _______________________________________________ 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/
+1 for Jonathan's proposition Marc Am 31.08.2015 um 07:41 schrieb Katrin Fischer:
I'd be ok testing Jonathan's suggestion of moving to Passed QA directly for for bugs with'string change' or 'trivial' complexity. QA and RM could still reset to 'Needs signoff' for a second opinion when they feel it's needed.
I think the patch complexity can only be set after developing a patch - so making it mandatory might not work as a technical solution here. Maybe we can encourage the use of the field a bit more?
Currently for most of the patches in the 'Needs Sign-off' queue the patch complexity is not set - so it's hard to tell how many patches this change would affect.
Katrin
Am 25.08.2015 um 14:57 schrieb Fridolin SOMERS:
+1
On those 200, how many have a severity of trivial or lower ?
Le 20/08/2015 15:51, Jonathan Druart a écrit :
Hello devs,
I would like to suggest a simplification of the integration workflow for some patches. Indeed the signoff queue is back to a critical threshold (200) and the signoffer's activity is very low.
Being part of the QA team, I try not to test patches in the Needs Signoff queue as I loose my QA token. The active members of the QA team are very limited and when we do SO, this increase the QA queue. As a result there is less chances my patches are QAed as there are more and more patches in the QA queue. It's a bit egoistic, but we all have the same problem.
So I suggest that for some patches, the ones with a minor severity, small or template changes could, IMO, bypass the signoff step.
I would like to discuss this during the next dev meetings, but I am keen to get some feedbacks on this idea.
Cheers, Jonathan
PS: If I am correct, we already have discussed about that previously. _______________________________________________ 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/
String changes can be calculated algorithmically. I suspect that the other complexities are largely a function of lines of code, number of files touched, and number of dependencies... but I'm sure that there other factors. The smaller the patch, the more likely that the complexity could be determined by a machine. On Aug 31, 2015 1:41 AM, "Katrin Fischer" <Katrin.Fischer.83@web.de> wrote:
I'd be ok testing Jonathan's suggestion of moving to Passed QA directly for for bugs with'string change' or 'trivial' complexity. QA and RM could still reset to 'Needs signoff' for a second opinion when they feel it's needed.
I think the patch complexity can only be set after developing a patch - so making it mandatory might not work as a technical solution here. Maybe we can encourage the use of the field a bit more?
Currently for most of the patches in the 'Needs Sign-off' queue the patch complexity is not set - so it's hard to tell how many patches this change would affect.
Katrin
Am 25.08.2015 um 14:57 schrieb Fridolin SOMERS:
+1
On those 200, how many have a severity of trivial or lower ?
Le 20/08/2015 15:51, Jonathan Druart a écrit :
Hello devs,
I would like to suggest a simplification of the integration workflow for some patches. Indeed the signoff queue is back to a critical threshold (200) and the signoffer's activity is very low.
Being part of the QA team, I try not to test patches in the Needs Signoff queue as I loose my QA token. The active members of the QA team are very limited and when we do SO, this increase the QA queue. As a result there is less chances my patches are QAed as there are more and more patches in the QA queue. It's a bit egoistic, but we all have the same problem.
So I suggest that for some patches, the ones with a minor severity, small or template changes could, IMO, bypass the signoff step.
I would like to discuss this during the next dev meetings, but I am keen to get some feedbacks on this idea.
Cheers, Jonathan
PS: If I am correct, we already have discussed about that previously. _______________________________________________ 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/
Some guidelines for the complexity setting can be found in the wiki: http://wiki.koha-community.org/wiki/SubmitingAPatch string patch = a patch that touches a string or the documentation/POD only trivial patch = a patch that just changes trivial things. Like removing a warn, adding some html in a template,... small patch = a patch that changes only a few Perl things medium patch = a patch that changes many things, with a low-medium side-effect risk, no or small DB changes large patch = a patch that changes many things with a high side-effect risk, large DB change. Gesendet: Montag, 31. August 2015 um 13:09 Uhr Von: "Barton Chittenden" <barton@bywatersolutions.com> An: "Katrin Fischer" <Katrin.Fischer.83@web.de> Cc: Koha-devel <koha-devel@lists.koha-community.org> Betreff: Re: [Koha-devel] Facilitate integration of some patches String changes can be calculated algorithmically. I suspect that the other complexities are largely a function of lines of code, number of files touched, and number of dependencies... but I'm sure that there other factors. The smaller the patch, the more likely that the complexity could be determined by a machine. On Aug 31, 2015 1:41 AM, "Katrin Fischer" <Katrin.Fischer.83@web.de> wrote:I'd be ok testing Jonathan's suggestion of moving to Passed QA directly for for bugs with'string change' or 'trivial' complexity. QA and RM could still reset to 'Needs signoff' for a second opinion when they feel it's needed. I think the patch complexity can only be set after developing a patch - so making it mandatory might not work as a technical solution here. Maybe we can encourage the use of the field a bit more? Currently for most of the patches in the 'Needs Sign-off' queue the patch complexity is not set - so it's hard to tell how many patches this change would affect. Katrin Am 25.08.2015 um 14:57 schrieb Fridolin SOMERS:
+1
On those 200, how many have a severity of trivial or lower ?
Le 20/08/2015 15:51, Jonathan Druart a écrit :
Hello devs,
I would like to suggest a simplification of the integration workflow for some patches. Indeed the signoff queue is back to a critical threshold (200) and the signoffer's activity is very low.
Being part of the QA team, I try not to test patches in the Needs Signoff queue as I loose my QA token. The active members of the QA team are very limited and when we do SO, this increase the QA queue. As a result there is less chances my patches are QAed as there are more and more patches in the QA queue. It's a bit egoistic, but we all have the same problem.
So I suggest that for some patches, the ones with a minor severity, small or template changes could, IMO, bypass the signoff step.
I would like to discuss this during the next dev meetings, but I am keen to get some feedbacks on this idea.
Cheers, Jonathan
PS: If I am correct, we already have discussed about that previously. _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org[Koha-devel@lists.koha-community.org] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel[http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel] website : http://www.koha-community.org/[http://www.koha-community.org/] git : http://git.koha-community.org/[http://git.koha-community.org/] bugs : http://bugs.koha-community.org/[http://bugs.koha-community.org/]
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org[Koha-devel@lists.koha-community.org] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/[http://www.koha-community.org/] git : http://git.koha-community.org/[http://git.koha-community.org/] bugs : http://bugs.koha-community.org/[http://bugs.koha-community.org/]
Le 31/08/2015 07:41, Katrin Fischer a écrit :
I think the patch complexity can only be set after developing a patch - so making it mandatory might not work as a technical solution here. Maybe we can encourage the use of the field a bit more?
Maybe we could have a specific status "TBD" (to be defined) or unknown : by default, the value is "empty", the field is mandatory, if the bug submitter don't know the complexity of the patch, he set it to "TBD". (the best option would be to have a rule like "the complexity is mandatory if the status is nso". But I don't think it's possible to set such a rule in Bugzilla) PS: Back from a full month of holiday today. 600+ mails after a quick sorting in my mailbox, be patient if you've asked me something ! -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries
participants (9)
-
Barton Chittenden -
Fridolin SOMERS -
Jonathan Druart -
Katrin Fischer -
Kyle Hall -
Marc Véron -
Marcel de Rooy -
Paul Poulain -
Tomas Cohen Arazi