Hi everybody, I have been working on Koha code for 3 years now. And for the last 2 years, I have been implied in the rebase of the BibLibre's patches and in the QA team. Many things have changed during this time. Koha is widely used throughout the world, and some great improvement have been made in the community workflow. However, I feel the need to share with you today my feelings and my frustration about our work methods. As I said, great improvements have been made in the patch integration workflow. Our process of validation and integration of the patches has lead to an improvement of the code. The respect of the basic coding rules - e.g. the indentation - makes the code easier to read and to understand, and then easier to modify. The unit test coverage has been expanded and we can now add new tests easily. It is also more secure to modify a core routine. All of these points are very positive to me: I enjoy developing in these conditions. But in parallel, I encounter difficulties with my patches queue. I try to spend time on every patch, to follow the coding guidelines and to produce clean and readable code, with unit tests. I try to write incremental patches, and understandable test plans (as far as my English level allows me to do...). I also try to QA as soon as I have spare time, and to rebase my patches as fast as possible not to block the signoffers. Concretely, the steps of the integration of a feature from my point of view as developer are: the customer orders a development. I start the development on the master branch (or a previous stable version). After several iterations, the customer agrees on the feature. I rebase the patch on a fresh master branch and I submit the patch in Bugzilla. I iterate with the signoffer and rebase the patch. At this time, the customer expects the feature to be in his production server. I then rebase the feature against his branch. The patch is finally signed after several months and several rebases against the master branch. This will usually need rebase and adjustment for the QA and/or the RM steps. When the customer version will be upgraded to the next release, I will once again adapt the feature - it may have differed from the initial feature. Sorry for this massive paragraph but the workflow is really as heavy as described (and this is the simple version...). The excessive duration of this integration process leads to several problems: - The developer is frustrated by these multiple rebases (trust me, it is really tiresome). - Regressions may be introduced following a badly fixed conflict - The development may need to be fully rewritten. - This is a lost of time not only for the developer, but also for the signoffer and the QAer. - Libraries and librarians may become frustrated too. I do not know how to fix these problems, but I would like to raise some points. 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. 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. Galen, can you explain why there are patches that stay for months in a Passed QA status (26 patches are in passed QA since more than one month, without any activity)? I really would like to see activity on theses patches. I guess it is not always easy to make a decision about some patches - invaliding/rejecting them instead of pushing them. But I think it is better to go ahead or to reject a patch, rather than blocking it without explaining why. Does it mean that you would need help? Module maintainers have been elected for the 3.16 release: what will be exactly their roles? In your 3.14 proposal, you suggest naming master branch committers. Is this idea still topical or did you abandon it? I also have the feeling that the features have been pushed toward the end of the release cycle. Wouldn't it be more secure to push them at the beginning of the cycle, so they are more tested? 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. In my opinion, it is not by limiting the amount of pushed patches that we will reach the stability of Koha. Many "actives" patches - i.e. more than currently 600 patches with SO, need SO, Passed QA, in discussion and does not apply status - could fix problems or improve the code. Moreover, some of the submitted features refactor the code and add UT. These features are susceptible to improve the maintenance and the stability of Koha. In my opinion, the main problem is that there are too few active members in the community. The sandboxes have not been used as expected, judging by the low amount of signed patches from sandboxes. Currently most of the testers are not Koha users but rather developers. In France, some universities start to use sandboxes to signoff patches but do not have enough time to do it on a regular basis. Are there such initiatives in the other countries - for example India, Northern African countries, USA,.... ? 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. I would like to know if this feeling is shared with other Koha developers or if I am the only one. How do you see the close future of Koha? Would you have any idea on how to improve the workflow? Do you have any idea to lead Koha users to be more implied in the testing process? Freely, Jonathan