+1 for QA signoffs; it seems a trivial addition. On Mon, Nov 26, 2012 at 8:52 AM, Jared Camins-Esakov < [email protected]> wrote:
> > > Until now, we said the QA goal was to be concentrated on code quality, >> > testing the feature was made 'somewhere else'. (that's why I also think >> > we could have QA before or after signoff, that's 2 independant things. >> > But I don't see how to achieve that with bugzilla, so I never suggested >> > the idea) >> > >> Hmm I always thought the first sign off was just testing the patch >> works, QA would test for code quality, regressions, etc. At least >> that's what I expected when I was doing RM. It sounds like it changed >> a bit while Paul was RM, and that is fine after all it was his >> responsibility to decide how he wanted to run his releases. >> We probably need to await Jared awaking, and clarifying exactly what >> he expects from QA for the 3.12 release, since that's what we elected >> him for :) >> > > From my point of view, the reason we elected the six people we did for the > QA team is that we know that those six people understand the big picture of > Koha better than other developers, and would be able to identify places > where regressions are likely. Code quality is important, but less important > than the end user experience, which would be much more marred by the > presence of a regression than the presence of a backtick. So it is my > expectation that when QAing patches our QA team is doing at least some > testing (for the most part I believe this has been done throughout the 3.12 > cycle; Marcel, an example of what I'm looking for can be found on > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8206 where you > spotted a number of problems in the course of QA). So I don't see that this > requirement adds a significant burden on the QA team. After all, you're > already applying the patch. On the other hand, the presence of the > Signed-off-by line from the QA team *greatly* reduces the burden on me, and > since I have had to push 114 patches (plus merges) *by myself* since > October 30 (and reviewed a fair number more), I think the tradeoff is worth > it. As an example of what I'm talking about, there was one bug where the > author repeatedly marked it "Passed QA" himself, without anyone else > looking at the code or testing it. In order to figure out what happened, I > had to wade through 67 comments on the bug and several pages worth of > history, just to find that no, I hadn't missed the QA team's approval, in > fact the patches never passed QA. There can be no question that I am the > bottleneck for code getting into Koha, and the day that bug wasted was > taken from my review of bug 7067, which probably would have applied had I > been able to use that time to review it. > > Regards, > Jared > > -- > Jared Camins-Esakov > Bibliographer, C & P Bibliography Services, LLC > (phone) +1 (917) 727-3445 > (e-mail) [email protected] > (web) http://www.cpbibliography.com/ > > > _______________________________________________ > Koha-devel mailing list > [email protected] > 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 [email protected] 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/
