Proposal for Assistance with QA Testing for Koha 3.6
Dear Community, As you are likely aware, I am the elected Quality Assurance Manager for the 3.6 release. As you may also be aware, there are currently 96 patches in Bugzilla that are signed off and ready for QA testing (at the time of this writing). My goal for my term as QAM was to keep this list under 10, but as we can see, that's not the current state of things. I do not want to become a bottleneck against good code getting into Koha. Quality Assurance is by it's nature a painstaking process, especially with more complex patches, to ensure that there are no regressions of functionality, or massive, unexpected shifts in default behavior. Often, numerous configurations of data need to checked against, to make sure fixing a bug for one possible setup doesn't cause a new bug in another. So far, we've not had to pull any code from master due to a regression, so it seems this process is working. But, that said, we've still got nearly a hundred patches waiting in the queue. Paul Poulain has offered to assist me with QA for the remainder of the Koha 3.6 release cycle. He's got the hours to dedicate towards this, and can help put some of these patches through their paces. While anyone can test any patch that's been published (and everyone is encouraged to do so), Paul is asking for the additional power to mark the patches he's tested as "Passed QA" if they do indeed pass his tests. Here are the exact terms of the proposal: a) he would not mark any patch he himself has written as Passed QA b) any patch written by BibLibre would need a signoff from another, external person before he'd test it c) he would start with the patches that have been waiting the longest d) the QAM and RM could reject any "Passed QA" patch if they feel it's not sufficient for whatever reason (which would need to be noted in the bug report) I do not feel that I necessarily have the right to transfer the "mark patches as Passed QA" power over to another person without the community's consent. So, I bring this to the group. Is this an acceptable proposal? Does the QAM have the right to "deputize" community members and transfer this particular power, or does the community need to vote on it? Are there any aspects of the issue that I'm missing? Thanks for your consideration and attention on this matter, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
+1, QAM is not the same as carry the yolk alone! On Aug 2, 2011, at 1:04 PM, Ian Walls wrote:
Dear Community,
As you are likely aware, I am the elected Quality Assurance Manager for the 3.6 release. As you may also be aware, there are currently 96 patches in Bugzilla that are signed off and ready for QA testing (at the time of this writing). My goal for my term as QAM was to keep this list under 10, but as we can see, that's not the current state of things.
I do not want to become a bottleneck against good code getting into Koha. Quality Assurance is by it's nature a painstaking process, especially with more complex patches, to ensure that there are no regressions of functionality, or massive, unexpected shifts in default behavior. Often, numerous configurations of data need to checked against, to make sure fixing a bug for one possible setup doesn't cause a new bug in another. So far, we've not had to pull any code from master due to a regression, so it seems this process is working. But, that said, we've still got nearly a hundred patches waiting in the queue.
Paul Poulain has offered to assist me with QA for the remainder of the Koha 3.6 release cycle. He's got the hours to dedicate towards this, and can help put some of these patches through their paces. While anyone can test any patch that's been published (and everyone is encouraged to do so), Paul is asking for the additional power to mark the patches he's tested as "Passed QA" if they do indeed pass his tests. Here are the exact terms of the proposal:
a) he would not mark any patch he himself has written as Passed QA b) any patch written by BibLibre would need a signoff from another, external person before he'd test it c) he would start with the patches that have been waiting the longest d) the QAM and RM could reject any "Passed QA" patch if they feel it's not sufficient for whatever reason (which would need to be noted in the bug report)
I do not feel that I necessarily have the right to transfer the "mark patches as Passed QA" power over to another person without the community's consent. So, I bring this to the group. Is this an acceptable proposal? Does the QAM have the right to "deputize" community members and transfer this particular power, or does the community need to vote on it? Are there any aspects of the issue that I'm missing?
Thanks for your consideration and attention on this matter,
-Ian
-- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal _______________________________________________ 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/
On 3 Aug 2011 05:39, "Stephen Wills" <swills@beyond-print.com> wrote:
+1, QAM is not the same as carry the yolk alone!
Indeed, and like Marcel I have no issues in this case. But I do think he is right about it being a community decision. Having said that, I think paul will do fine. But everyone can help, it still shouldn't be left to Ian and Paul. How can you help you ask. Write a how to test on your bug Write a good description of what the patch should do, remember the more you tell, the easier it is to test Write accompanying tests. And even though a patch has been signed off, there is no reason you can't add your signoff too. To strengthen the confidence we have that the patch will work. It is a law of the universe, immutable even. Release Managers Law : In no circumstances ever can a patch have too many sign offs Chris
On Aug 2, 2011, at 1:04 PM, Ian Walls wrote:
Dear Community,
As you are likely aware, I am the elected Quality Assurance Manager for
I do not want to become a bottleneck against good code getting into
Koha. Quality Assurance is by it's nature a painstaking process, especially with more complex patches, to ensure that there are no regressions of functionality, or massive, unexpected shifts in default behavior. Often, numerous configurations of data need to checked against, to make sure fixing a bug for one possible setup doesn't cause a new bug in another. So far, we've not had to pull any code from master due to a regression, so it seems
Paul Poulain has offered to assist me with QA for the remainder of the
Koha 3.6 release cycle. He's got the hours to dedicate towards this, and can help put some of these patches through their paces. While anyone can test any patch that's been published (and everyone is encouraged to do so), Paul is asking for the additional power to mark the patches he's tested as "Passed QA" if they do indeed pass his tests. Here are the exact terms of
a) he would not mark any patch he himself has written as Passed QA b) any patch written by BibLibre would need a signoff from another,
external person before he'd test it
c) he would start with the patches that have been waiting the longest d) the QAM and RM could reject any "Passed QA" patch if they feel it's not sufficient for whatever reason (which would need to be noted in the bug report)
I do not feel that I necessarily have the right to transfer the "mark
the 3.6 release. As you may also be aware, there are currently 96 patches in Bugzilla that are signed off and ready for QA testing (at the time of this writing). My goal for my term as QAM was to keep this list under 10, but as we can see, that's not the current state of things. this process is working. But, that said, we've still got nearly a hundred patches waiting in the queue. the proposal: patches as Passed QA" power over to another person without the community's consent. So, I bring this to the group. Is this an acceptable proposal? Does the QAM have the right to "deputize" community members and transfer this particular power, or does the community need to vote on it? Are there any aspects of the issue that I'm missing?
Thanks for your consideration and attention on this matter,
-Ian
-- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal _______________________________________________ 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/
FWIW: I personally would welcome Paul as assistant QAM. But I do not think that QAM should "deputize" others without consent of the community. QAM and assistants could be elected on a meeting. In this case I would suggest to let Paul start and make it formal on the next meeting. ________________________________ Van: koha-devel-bounces@lists.koha-community.org [koha-devel-bounces@lists.koha-community.org] namens Ian Walls [ian.walls@bywatersolutions.com] Verzonden: dinsdag 2 augustus 2011 19:04 Aan: koha-devel@lists.koha-community.org Onderwerp: [Koha-devel] Proposal for Assistance with QA Testing for Koha 3.6 Dear Community, As you are likely aware, I am the elected Quality Assurance Manager for the 3.6 release. As you may also be aware, there are currently 96 patches in Bugzilla that are signed off and ready for QA testing (at the time of this writing). My goal for my term as QAM was to keep this list under 10, but as we can see, that's not the current state of things. I do not want to become a bottleneck against good code getting into Koha. Quality Assurance is by it's nature a painstaking process, especially with more complex patches, to ensure that there are no regressions of functionality, or massive, unexpected shifts in default behavior. Often, numerous configurations of data need to checked against, to make sure fixing a bug for one possible setup doesn't cause a new bug in another. So far, we've not had to pull any code from master due to a regression, so it seems this process is working. But, that said, we've still got nearly a hundred patches waiting in the queue. Paul Poulain has offered to assist me with QA for the remainder of the Koha 3.6 release cycle. He's got the hours to dedicate towards this, and can help put some of these patches through their paces. While anyone can test any patch that's been published (and everyone is encouraged to do so), Paul is asking for the additional power to mark the patches he's tested as "Passed QA" if they do indeed pass his tests. Here are the exact terms of the proposal: a) he would not mark any patch he himself has written as Passed QA b) any patch written by BibLibre would need a signoff from another, external person before he'd test it c) he would start with the patches that have been waiting the longest d) the QAM and RM could reject any "Passed QA" patch if they feel it's not sufficient for whatever reason (which would need to be noted in the bug report) I do not feel that I necessarily have the right to transfer the "mark patches as Passed QA" power over to another person without the community's consent. So, I bring this to the group. Is this an acceptable proposal? Does the QAM have the right to "deputize" community members and transfer this particular power, or does the community need to vote on it? Are there any aspects of the issue that I'm missing? Thanks for your consideration and attention on this matter, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com<mailto:ian.walls@bywatersolutions.com> Twitter: @sekjal
Le 02/08/2011 19:04, Ian Walls a écrit : > c) he would start with the patches that have been waiting the longest Just FYI : I can't find how to sort reliably by "waiting the longest". * Sorting by bug number is approximative but wrong : a bug can be 5 years old and the patch provided 5 days ago * Sorting by "last modification" is worst : any comment update the "last modification" field * I can't find a "attachment date" sorting I think I'll use the bug number (from oldest to newest). I think it's the less worst solution, unless someone has another suggestion... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Hello everybody, I started the work, here is a summary of my 1st day of QA-ing : * I worked all the day on it (except a few distractions on IRC, colleagues, or mail). Something like 7 hours probably. * I've QA'ed 18 bugs (over 95 waiting) : 4002, 4222, 4415, 4518, 4839, 4959, 5072, 5079, 5098, 5131, 5166, 5429, 5433, 5436, 5468, 5602, 5630, 5633 * 8 have been set "passed QA" * 2 have been set as "failed QA" (one by owen, answering to a question I had) * 1 does not apply anymore (sorry tcohen :\) * 7 are still "signed-off" = I didn't wanted to endorse the "passed QA", either because I signed-off the patch already, or I'm not sure (i've added a comment for Ian though, with my opinion) I'll continue tomorrow (probably not all the day) HTH -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
participants (5)
-
Chris Cormack -
Ian Walls -
Marcel de Rooy -
Paul Poulain -
Stephen Wills