Jcamins Proposal for RM-3.12

Overview

Version 3.10 promises to be the best Koha release yet, deprecating GRS-1 in favor of DOM indexing for Zebra and integrating Solr support into Koha, as well as offering FastCGI (via Plack) for both the OPAC and Intranet. We have also made a start on replacing the old, cluttered C4:: namespace with a new Koha:: namespace which will be developed with MVC design principles in mind from the beginning.

Moreover, in the last year we have smoothed out many of our processes as a community, greatly improved the quality of code that is going into Koha, and reduced the barrier for entry to new developers (as of 8 July 2012, there have been 25 new developers to Koha since the release of 3.6.0, and there have been at least 20 developers active in 11 of the last 12 months). The sandboxes that Paul pioneered for the 3.8 release cycle have made it much easier to sign off on patches, and have enabled non-developers to participate more fully in the Koha development cycle.

I propose to spend the 3.12 release cycle focusing on stability and -- in addition to developing the awesome features that we're all planning -- continue cleaning up and refactoring some of the messier parts of the Koha codebase, building on the work that has been underway for the last year.

Targets

C4::Search. 3.12 is the perfect opportunity to rewrite the Zebra search code (and the generic search code) to enable us to take greater advantage of the search engines we have, as well as fixing some of our most hated bugs and inelegant code in C4::Search. This is also a good opportunity to officially deprecate GRS-1 and remove NoZebra (which has not worked for a long time, and has acquired no champions).

Caching. We have new CHI-based caching for 3.10 that we are (at the moment) hardly taking advantage of. During the 3.12 release cycle, I'd like to spend some time figuring out how we can most effectively use caches.

Database agnosticism. It has long been a goal to get Koha running on both MySQL and Postgres. During 3.12 I hope we will continue work on this, and find a solution that enables us to support not just MySQL and Postgres, but also any other databases that may show up in the future (ideally even SQLite, for testing purposes).

Code cleaning and persistance. We've seen big wins here in 3.8 and 3.10, but by continuing the process we can further reduce memory leaks, improve performance, and lower the barrier to entry for new developers.

Release procedures

My mantra as Release Manager will be "automate, automate, automate." As Release Maintainer for 3.6.x this past release cycle, my emphasis has been on shifting as much of the mechanics of the job onto automated scripts as possible, and I plan to kick that up a notch as Release Manager. Before pushing patches to the community git repository, I propose to enforce the following:

The patch must not cause the test suite (including automated regression tests, see below) to fail
The patch must not break the package build/package installation process
The patch must not break the tarball installation process

Transparency

Paul has initiated a monthly "RM newsletter" to keep the community informed about the release process. I intend to continue this, and also make sure a complete list of new features in the Master branch is kept up to date (automatically!) so that people who want to understand where 3.12 is going can follow.

Automated testing

We have been increasing our test coverage steadily (Jenkins now runs more than 10,000 tests!), and with it the stability of our releases. I think we can continue the trend by doing the following:

Requiring that all routines added to C4 and Koha come with a unit test
Adding more QA-oriented tests to ensure that the code meets the Koha coding standards to the extent that this can be automatically tested
Encouraging the development of regression tests using WWW::Mechanize or Selenium (potentially using them to compare the behavior of known-good versions of Koha and Master)

Encouraging involvement

One of the major issues that Paul has faced these past two release cycles has been encouraging involvement in the testing process. Paul developed the Sandboxes which make it easier for librarians and other non-developers to test and sign off on code, but there are more patches than ever awaiting signoff, in large part thanks to the community's open and welcoming attitude toward new contributors. Unfortunately, 50% of non-RM signoffs are still coming from just three or four developers. I believe that part of this is the sense that some people have that signing off "doesn't count" as a contribution. In order to make it clear that we as a community do value signoffs every bit as much as we value patch submissions, I propose to include the list of individuals who signed off on patches in a given release cycle in the release notes and on the about page.

Timeline

There has been some confusion about what a feature freeze is, versus a string freeze, and when they go into effect. I propose the following timeline for the six month release cycle:

Immediately after 3.10.x is branched -- We start work on 3.12, but bugfixes relevant to 3.10.x will receive priority
After 3.10 is released -- We celebrate! Any features that were delayed due to the emphasis on bug fixes will be pushed
2 months before release -- Feature freeze (no new features will be pushed)
3 weeks before release -- String freeze (no string changes will be pushed, to allow the translation teams time to finish translating)