[Koha-devel] ping Koha (developers) community

[Jonathan Druart]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131209/8ced11af/attachment-0001.html>