[Koha-devel] ping Koha (developers) community

[Chris Cormack]

On 11/12/2013 3:08 am, "Marcel de Rooy" <M.de.Rooy at rijksmuseum.nl> wrote:
>
> Hi Jonathan
>
>
>
> > The number of patches waiting for QA has decreased. This could be
explained by the efforts of the QA team, but
>
> > also by the decrease of SO patches - and thus by the decrease of
patches going into the QA queue. The stack of
>
> > patches waiting for SO is closed to 200, and my feeling is that the
amount of weekly SO has never been so low.
>
> > 2/3 of theses NSO are enhancements and 60 have been opened prior to
2013. This bottleneck will delay the
>
> > development of future features.
>
> I would suspect that these numbers will always fluctuate. In one or two
weeks we might just have 150 in NSO and 100 in SO.
>
>
>
> > One of the more frustrating thing is to see passed QA patches regress
to the does not apply status, because they
>
> > have been queuing too long at the RM step. It regularly blocks me: I
cannot make features for the customers
>
> > when there are too many dependencies waiting to get pushed to the
master branch.
>
>
>
> I can understand that Galen does not always have the time to examine each
patch when it enters PQA. But I would really like to see here more-or-less
FIFO (first in, first out). First out could of course mean Failed QA or
Discussion, but at least a change of state with some comments. The current
situation, leaving them in PQA for long without any visible activity, does
not motivate developers. (The FIFO rule would be fair also for the QA team,
and even for signing off (bug wranglers !).. ) A FIFO rule should perhaps
lower rebasing time too? When I joined the QA team, I did more or less
adhere to FIFO when QAing, but the current workflow made me leave that
approach.. If I have the idea that a patch set will probably go to sleep in
PQA (without obvious reasons for failing it), I will not start QA on it
either.
>

In theory this sounds good, with the caveat bug severity can override it
too.

Of course we can make tons of suggestions, but it is really up to the RM
how they use their time and we should be seeking to support them in what
ultimately is a thankless role.

Speaking from my experience of RMing (4 releases I think) almost all you
ever get is complaints.

Chris
>
> > I spend most of my time rebasing patches, instead of developing new
ones or QAing others patches. I worked 40
>
> > days in 2013 for the community rebase. This includes the resolution of
conflicts and the submission of followups.
>
> > My time could have been better used.
> > I have tried regularly to spend personal time to develop improvements
for Koha - such as rewriting the
>
> > authorised values (new module),  adding a logging module and rewriting
the updatedatabase way. But after
>
> > respectively 6 months, 1 year and 2 years of rebase, discussion, etc.
Nothing happens anymore. My conclusion is
>
> > sadly that it is not worth anymore investing my free time in Koha.
>
> Your conclusion is very familiar (recognizable). More than once or twice
I wrote patches that did not receive much attention; after rebasing a few
times I now usually abandon them. A mechanism that would push us to sign
off less-popular patches could perhaps help.
>
> Note that I still think that your investment of (free) time in Koha is
worth it! Unfortunately do not assume that every patch will make it, but
lots of them will ..
>
>
>
> Marcel
>
>
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131211/cbc897d4/attachment.html>