Le 04/07/2012 14:25, Marcel de Rooy a écrit :
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 !) mmm... maybe I'm using a wrong word here. What I wanted to say is I QA BibLibre patch exactly the same way as a non-BibLibre patch : if I think it should not be pushed, I won't push it, BibLibre or not BibLibre. The question "does it break something" is related to my long-standing experience on Koha, that let me find/know caveats. Not that I'm always right, I made mistakes, but I think there's no difference between BibLibre and non BibLibre patches.
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? Well, my feeling is that we could officially add Katrin to the QA team, because she make a lot of very good QA comments. But that's another topic ;-)
What I wanted to say here is that the community could recognize the fact that I'm trustable/wise/experienced enough to QA any patch. I wouldn't object if chris_c had the same possibility for catalyst patches -and wanted to join QA team-. (Maybe the problem here is that, atm, I'm the only one who is in a position where this specific permission is applicable/useful/needed)
For example, the eclipse foundation has "contributors" and "committers". From first glance, I suspect that we compare two non-similar workflows. agreed. It was not to use the same workflow, just an example. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08