On 11/12/2013 3:08 am, "Marcel de Rooy" <M.de.Rooy@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@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/