[Koha-devel] [QA] QA process

Jared Camins-Esakov jcamins at cpbibliography.com
Thu Nov 29 16:59:35 CET 2012


Paul,

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%)
>

Yes, because I already informed Elliott that under no circumstances would I
accept him QAing a patch by ByWater.


> 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...


Agreed. At some point there may be no choice. I'm pretty sure we have had a
backlog in the Signed Off queue for a long time, possibly since always
(Chris has a nice graph somewhere, but I don't know where). In light of
that, I think two months would be reasonable.

Also, it's worth pointing out that we have a QA *team*. If there's a
BibLibre patch that's been signed off that isn't getting QAed, it is
absolutely reasonable for you to e-mail the koha-devel list a message
something like: "[QA] Does anyone have time to review poor benighted bug
XXXX?" There's no guarantee someone will, but a list of forty bugs
clamoring for attention is daunting, and with no particular reason for
choosing one over the other, the chance of another QAA choosing to review
your particular bug is very slight. On the other hand, if you ask, someone
just might. I've been known to repeatedly overlook patches that provide
functionality that I want when looking for a patch to sign off, either
because the list is just too long or because I don't recognize what the
patch does from the description (for example, at one point I was going to
try testing the non-linear updates, but thought it was already signed off
because I didn't see the patch in the "Needs Signoff" list... and that went
on for months; it was only when chris_n signed off on the patch that I
realized the bug was called "updatedatabase improvements" and not
"non-linear updates" or the like).

Regards,
Jared

-- 
Jared Camins-Esakov
Bibliographer, C & P Bibliography Services, LLC
(phone) +1 (917) 727-3445
(e-mail) jcamins at cpbibliography.com
(web) http://www.cpbibliography.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20121129/d8810baa/attachment-0001.html>


More information about the Koha-devel mailing list