[Koha-devel] Proposal to be RM for 3.14

Paul Poulain paul.poulain at biblibre.com
Wed Mar 13 18:38:39 CET 2013


Le 13/03/2013 13:28, Marcel de Rooy a écrit :
>> 2. Experimenting with the structure of the release team to spread the work and knowledge around.
> I would not favor too much experimenting here for continuity.. We should not change workflow every other release (or new RM).
well, OTOH, we're a small community, so it's good to refine the workflow
from time to time.
I think it hasn't been changed since 3.4, except for the "RM can QA"
that had been decided when I was RM, I used it a lot, and I think Jared
didn't.
Jared also added the rule "QA must sign-off the patch on bugzilla",
which is not a big change.

> Instead of forming a new group of master branch committers, 
> I think that the RM should only push patches. But he should be allowed
to delegate his responsibility
> of checking a patch to a module maintainer. A second signoff from the module maintainer could lighten 
> the load for QA and RM.  If some module maintainers would be part of
the QA team, that would be even
> better. Note that the workload for QA was made higher during the last
release, proven by a growing signed-off-queue.

My main comment here is that a patch validated must be very quickly
pushed, otherwise, before pushing, it's always required to test it.
Because there can be some nasty side effect added by another patch that
has been pushed in the meantime.

That's why I like the idea of branch commiters. Of course there should
not be such commiters on core features (like circulation), but for
things like tools, reports, admin or maybe even patron management, I
think it's a good idea : it would reduce the load of the RM, that could
concentrate on other things.

HTH

-- 
Paul POULAIN - Associé-gérant
Tel : (33) 4 91 81 35 08
http://www.biblibre.com
Logiciels Libres pour les bibliothèques et les centres de documentation


More information about the Koha-devel mailing list