[Koha-devel] FW: Code simplicity document

Wed May 11 17:56:27 CEST 2011

Paul,

I agree that having 140 patches needing signoff is way too many; I'd like to
see all them signed off and ready for QA.  Lots of good stuff out there, and
if it's not being integrated, we're losing out.

However, the workflow is a good one from a quality assurance point of view.
Someone writes the code, someone else confirms it applies and seems to solve
the bug, then QA checks for integration with all other aspects of Koha (so
adding something new doesn't break something else), and finally the RM
pushes it.

As an internal measure, we at ByWater started signing off on all our
out-going patches before putting them on the list.  The idea here was just
make sure we were putting out code free of typos, silly errors and the like
(I've been known to make such mistakes, and loved having another set of eyes
in the company check things before I publicly released them).  We found that
for Koha 3.4, that was often enough of a sign-off to get things committed.
I was concerned that since it was "in company", the signoff would be less,
and for larger, deeper devs, perhaps it is, but for many of the bugfixes it
was sufficient.  So, code that one of the BibLibre team has written could be
signed off on by any other member of the company, and that would advance the
status.

Anything that's in the SIGNED_OFF state is in my queue for QA.  The signoffs
can come from anyone, even within a company; I'll still be doing rigourous
testing.  I'll factor in the sign-offs, especially for things like CAS that
I don't have the services to test with right now, but I don't want to do any
blind signing off, or pushing things that need followup patches to complete
them (because what if THOSE never get their signoff, and we reach release
time?).

Once the SIGNED_OFF list is exhausted, I'll start selecting from the
NEEDS_SIGNOFF pool, and putting those through QA, as time permits.
SIGNED_OFF will take priority, but this will provide a way to keep things
flowing if folks aren't doing signoffs as fast as I'm doing QA.

I hope this helps elucidate where I'm looking to go with this workflow and
how we can work to get it flowing along.

Cheers,

-Ian

On Wed, May 11, 2011 at 11:22 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> 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
>
> _______________________________________________
> 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/
>

-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
ALA Booth 732
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110511/c723c3f2/attachment.htm>