[Koha-devel] [QA] QA process

[Marcel de Rooy]

Nice to see that QA gets so much attention these days :)

I think that Katrin's proposal on itself is a valid one. We never wrote it out in our workflow document on the wiki. That document (that apparently has community consensus) says only:

"Preferably, patch writer and patch signer should not be from the same company or institution."

But just adding the clause that if patch writer and signer are from the same company, the QAer should be (preferably) independent, is in the same line of thought, just a logical extrapolation. IMO we could add what Katrin stated to this workflow document, and keep situations where writer, signer and QAer are in the same company to an absolute minimum (very close to zero). 

Just noting also that Paul's numbers relate to Needs Signoff and not to Signed off. The oldest patch waiting for QA from Biblibre are four from October 19. QA should indeed now pick them up first. Before I have QAed several patches already that were written and signed Biblibre only. I do not think that QAing Biblibre patches is really an issue now. 

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: donderdag 29 november 2012 9:52
To: koha-devel at lists.koha-community.org
Onderwerp: Re: [Koha-devel] [QA] QA process

Le 28/11/2012 22:34, Katrin Fischer a écrit :
> Hi all,
Hi QAM,

> We already agreed some time ago that the patch writer and the patch sign
> offer should not be from the same company/library/party. I would really
> like to extend that rule to also apply for patch writer and QA team
> member. For 3.12 we got a big QA team, which is great, because with all
> the ongoing work we are going to need it. And it also gives us more
> options and flexibility when it comes to these kinds of questions.
>
> I would like to get your opinions on this, can we agree on this new rule?

Am I right if I say that BibLibre will be the company mostly concerned
impacted by this rule ? Checking numbers.
Some numbers: there are 131 patches waiting for signoff or QA. 52 are
from BibLibre (40%)

Displaying by "date of last change" (ie= there's been no activity on
this bug since...)
* August= 9 patches: 5 BibLibre,  1 OSSlab, 1 ByWater, 3 others
* September = 8 patches: 4 BibLibre, 3 ByWater, 1 other
* October = 27 patches: 14 BibLibre, 3 ACPL, 6 ByWater, 4 others
(All of them are Enhancements or New Feature)

At the end, my opinion is that it's a little bit unfair (and I restart a
long-standing discussion/complain...) BibLibre does a huge of effort to
submit all his development, and be quick when there is feedback.

The very bad side effect of delays is that we loose a lot of energy in
rebasing, just because there's no feedback from anyone, and when someone
step-in the patch does not apply any more.

We fully accept the rule for not self-signing the patch, because,
functionally speaking, I agree that it's good to have an external eye.
(and that's more important with large features)

But the QA is a *technical* check of the code. If something is wrong (ie
don't respect our guidelines, has a bad side effect, ...), as QAer, I'll
do *exactly* the same thing whoever the patch come from.

If I were suspicious, I could even say that you imply that, when
Jonathan or me QA a patch from BibLibre, we're biased, and I could be
upset by your suspicion (I'm not, I'm just very sad that this discussion
started again, while I thought it was solved)

I never "promote" BibLibre patches, I always QA by date of last change,
ie: I QA the older patch without activity. Yesterday, I QAed something
like 10 patches, iirc, 2 from BibLibre failed QA (including one just
because there was some PODDOC missing !)

Chris-es are proposing what could be a fair rule imo = "if no one step
up". What could be considered as "no one step up" being the next question...

--
Paul POULAIN - BibLibre
http://www.biblibre.com
Free & Open Source Softwares for libraries
Koha, Drupal, Piwik, Jasper

_______________________________________________
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/