Le 29/05/2012 17:12, Ian Walls a écrit :
I strongly believe that having a 'neutral party' to do the QA work is essential to keeping our codebase strong and healthy. We need the fresh set of eyes, the different perspective, the alternate use case. We need someone asking "what does it break?", and I don't think the folks who've been asking the question "does it work?" are the best suited to that task. Reviving this thread...
I think this thread became 2: - signing-of a patch in the name of a customer => this proposition seems to be globally accepted (yes = marc_b, nicole, dobrica, kyle, Marcel. jared also said yes I think (From - Mon May 28 17:50:13 2012) no = I can't find anyone saying 'no': chris_n and katrin expressed some concerns, but they were related to having a company writing & signing-off a patch, which is not what I requested). Is there anyone wanting to say a "no", and argue why ? - QAing a patch => I think this topic need more discussion= who could/should QA a patch, how should it be done ? I think it's not a matter of 'neutral party', but more a matter of 'experienced and trust-able party'. 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. Because if it introduces silently something that could break another thing even if it works under certain circumstances, passing QA would be a short-term vision. My goal (and all QA team goal) is to manage Koha improvement(s) on the long term. Should we, then, give a grant to some specific, experienced & trustable ppl to QA ? this has my preference, I throw it now. That it's how some Open-Source communities are working. For example, the eclipse foundation has "contributors" and "committers". I see committers as a rough equivalent or our QA team (http://www.eclipse.org/projects/dev_process/development_process_2011.php#4_7...) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08