[Koha-devel] QAing patches [was Re: Signing-off a patch for a customer]

[Ian Walls]

Points:


1.  Yes, I believe it's okay for someone to do the action of sign off for
someone who is not technically inclined or does not have access to Git,
provided the person doing the signoff has verifiable permission from the
person who's name it is they are using.  It would primarily be on the
person who's name is being used to raise an alarm if their rights are being
infringed, but if anyone in the community feels this is the case, they are
welcome to question the proxy-signoffer (hopefully in a tactful, respectful
manner).

2.  Checking code to see if it breaks anything requires a keen eye and
plenty of experience with Koha, as the codebase is very complex, having
grown organically over time.  The longer you've been involved with the
code, the better the chance you have encountered some of the various
idiosyncrasies before.  There are a number of folks who fit this bill, and
we're very luck to having them writing, testing and signing off.

I think, however, we need to keep the QA team as elected.  The election of
folks to QAM and QAA is the community's way of showing faith and trust in
those people.  Appointing people, or opening the position to take all
comers, will erode some of the distinct value that QA provides, reducing it
in many ways to a second signoff.

I believe (and I think the statistics would back me up, if they could be
generated) that having had QA for the two previous releases, and this
current one, has reduced the number of regressions and bugs slipping in
from release to release.  I would be very interested in seeing hard numbers
on that, though.

Cheers,


-Ian

On Wed, Jul 4, 2012 at 8:32 AM, Chris Cormack <chris at bigballofwax.co.nz>wrote:

>
> On Jul 5, 2012 12:25 AM, "Marcel de Rooy" <M.de.Rooy at rijksmuseum.nl>
> wrote:
> >
> > Hi Paul, all
> >
> > > Seeing if it can break something requires a lot of experience with
> Koha code source. When I QA code from BibLibre, I'm not biaised because it
> comes from BibLibre.
> > Are you sure? Just looking at your statement from outside BibLibre, I
> would say that there could be conflicting interests here.. (With all due
> respect !)
> >
>
> Neutral is always to be preferred imho.
>
> > > Should we, then, give a grant to some specific, experienced &
> trustable ppl to QA ?
> > Isn't that already the case? Or do you feel that we should extend the QA
> team? If we dissolve it on the other hand and grant a new QA privilege to
> say 15 developers, it may just be a little too optional/non-committal.
> Would that really be more productive?
> >
> I thought it was already the case too, and that's what we had nominations
> and elections for. I'd hate to replace that system with a cartel like
> appointed system.
>
> Chris
>
> > > For example, the eclipse foundation has "contributors" and
> "committers".
> > From first glance, I suspect that we compare two non-similar workflows.
> >
> > Marcel
> > _______________________________________________
> > 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/
>
> _______________________________________________
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120706/23f2e5fa/attachment-0001.htm>