[Koha-devel] FW: Code simplicity document

[Paul Poulain]

Le 11/05/2011 16:22, Chris Cormack a écrit :
> On 12 May 2011 00:19, Marcel de Rooy <M.de.Rooy at rijksmuseum.nl> wrote:
>> Liked that article!
>> As relative new member of the community, I am wondering if the current signoff/passed_qa procedure really encourages new members to keep sending patches.
>> It could happen easily now that a patch does not get any attention. What makes someone now select a patch for signoff? Coincidence, contacts, application feature?
> Unfortunately that has always been the case since we moved to the
> workflow of having patches. The new statuses and reports showing bugs
> waiting for sign off have I think made it less likely. For 3.4.0 for
> example there were over 1000 patches, from 66 different people in 6
> months that made it in. So I think we are slowly improving all the
> time, and should strive to continue to do so.
>
> Currently now the best way of getting a patch signed off, is asking
> someone to look at it.
Jumping in the discussion: the workflow is great, in theory.
But when no-one find time to sign-off a patch, it results in patches
being lost in limbo. And when someone suddenly takes care, unfortunatly,
the patch does not apply anymore, so the patch writter has to rebase,...
It not a good method to motivate ppl to contribute, obviously !

At the moment, we have 140 patches waiting for sign-off. Some including
critical bugs.

Just picking one of them: 5995 = It requires a CAS server to be tested,
and I fear no-one has one.

I can guarantee that the problem has been reported by a library using
Koha. I can guarantee this is the patch we've applied, and the library
has closed the bug on our internal platform. I can guarantee that this
is exactly the patch we've made. And I can guarantee the library will
never sign-off anything. So ... we're waiting for someone to sign-off
this patch. And I feel we'll wait for a long time.

Another example: 3652 (XSS vulnerabilities)


I could add that many features we've submitted still have not made their
way into Koha master, and it's not because of our efforts, it's because
of this too strong workflow.
They're too complex to apply/test/sign for someone not able to dedicate
a full day to this task. But, once again, those features are working
well for our customers, but they'll never sign-off anything !

Chris, I know we disagree here. But the workflow would be a good one if
we had a long list of developers available, and we don't have.

What's the solution ?
I already have proposed, at the beginning of 3.4, to have pending
features merged "immediatly", to let ppl (including librarians) time to
do QA. You rejected this idea.

I make it again : I think we should have a small time of, say, 2 months,
where new features will be included easily. With a sandbox setup for
anyone to test them (i'm definetly sure I could motivate french
librarians to test. I'll never succeed to make them sign-off !).
And during the 4 remaining months, 1- fix bugs on merged features (and
even revert some if needed, like no feedback from the dev and big
problems), 2- add features after a strong patch workflow.

To summarize :
T+0 - T+60 = any feature/patch that applies and is sent cleanly by a
contributor that can promize he will take care of problems on the
feature are merged
T+60- T+150 = features/patches added only after a standard QA/signoff
(i'm not sure i'm happy with a 1signoff+1QA barrier, I fear it's too
high, but...)
T+150 - T+180 = features & string freeze


Without this, I think/feel that the "140" patches waiting for signoff
will never be lowered. 15 persons worked for one full week during
hackfest, and after 1 months, we're back to a number I consider as huge.


PS : challenge: who is interested in signing BZ6328 i just submitted ? I
feel no-one, as it's related to fines in days, and it seems it's
something strange to US/NZ and many countries.

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08