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. > 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 [email protected] 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/
