Proposal paul p RM38

Release Management Application

Summary

I've already served as Release Manager for Koha version 2.0 and 2.2. Since then, i've founded BibLibre, that is now 15, and support more than 100 libraries running Koha (including 6 french universities and some large public library networks)

When 2.2 Release Manager, I had to also do sales and install/migrations/... For this RM 3.8 application, we have organised BibLibre to be able to have me dedicating half of my time to Release Management tasks.

We changed the first version number from 1 to 2 when MARC support was added. We changed from 2 to 3 when zebra support was added. It's time to move to version 4.0, by :

• refactoring the code to adopt modern Perl tools
• refactoring the search engine part of Koha to be able to use another search engine, solR

My main goal with this RM position is to move Koha to version 4.0. I don't think achieving all of this will be possible in just 6 months. That's why I apply directly for the RM position for 2 versions: 3.8 and 4.0.

I have written many times on koha-devel mailing list my concerns about our development workflow. My goal will be to achieve both stability and fluidity. It can be summarized by "no patch should stay pending for more than 3 weeks"

Time line

I've promoted the "Time-based release", so I won't change anything on this matter : one major version every 6 monts. The version 3.8 will be written over the 3.6 codebase. The 4.0 will be started "immediatly" from the 3.6 too, so that will be a "1 year project", but still a 6 months release.

Version 3.8

This version will be a continuation of the 3.6, so won't contain major structural change. New features that applies on 3.8 will also be applied on 4.0. (we will have to deal with feature submitted for 3.8 and not applying for 4.0, it's something to be discussed, see below)

Version 4.0

This version will be a major update of Koha. It will probably contain some functionnal improvements that I can't imagine yet, but more than this, it will be a "internal/technical changes release"

Organisational guidance

My main goal is to animate and motivate people willing to help by lowering the barriers of participating (you can look at http://www.codesimplicity.com/post/open-source-community-simplified/ that is a document I really liked about that)

To help motivate ppl testing / signing-off / commenting, I plan to:

• have sandboxes of Koha, that contains a demo database, updated very frequently (the goal would be to have one sandbox for each patch, automated)
• communicate a lot on mailing lists about :
  • what is expected to arrive soon (Enhancements). It will require a lot of communication between "feature providers", that will be a major part of my RM role (I already have spoken of this with ByWaterSolution, another major "Feature provider" for Koha)
  • what is to sign-off / test / ... I plan to send a mail every week, or 2 weeks to koha-devel & koha user mailing lists.

My overall idea (with sandboxes), is to lower the step for librarians without any technical (git) skill to test

I also want to lower the barrier for ppl that want to submit patches :

• The goal will be to have no bug pending for more than 3 weeks. This is the best way to motivate people submitting patches and lower the number of "does not apply" patches.
• I propose to divide the 6 months for 3.8 in 2 differents period :
  • the 1st period (3 months ?) will be dedicated to submitting features. During this period, the workflow for including Enhancements will be lightened (how exactly, TBD)
  • the 2nd period (3 months ?) will de dedicated to enforcing stability. During this period, the workflow for including Enhancements will be hardened (how exactly, TBD)

As 4.0 has the goal to be a major rewrite, I also plan to organize working groups on various modules / parts of Koha, to speak of code design. The idea to launch 4.0 immediatly is to have some time (3 months ?) to define which technical path we want to choose. Those 3 months (that will overlap with the first 3 months of 3.8 Release) will be followed by 6 months of technical work to implement as much as possible of what we decided. A large part, and probably the trickiest one !, will be to organize "teams", to know who is working on what, and avoid redundant or incompatible work.

Technical guidance

The technical options for Koha 4.0 will be discussed during the first 3 months of the "one year projet" for this version. Here are some of the ideas we can/will discuss of:

• persistency => Plack? which steps?
• Database Abstraction => DBIx::Class;? which steps?
• C4::Search => As chris said in his 3.4 application: "For the most part this module does it job, but it is overly complicated and hard to maintain and change. Refactoring this a major goal. ". He couldn't achieve this goal, we will, and add solR support
• clean code => remove circular references, identify and remove dead code, identify and fix misnamed & misplaced code (for example, in misc, there are script that should be somewhere else)
• update online help (list what is outdated, link with the documentation,...)
• authentification stack in Koha: the C4/Auth is good, but not flexible
• automated tests = we wanted to have automated tests, we have some, but it represents only a small coverage of all what should/could be done.

Any idea will be welcomed and discussed in this 3 month period. The idea is to have a clear and strong roadmap.