Proposal for RM 3 14 gmcharlt

Overview

I propose to serve as Release Manager for Koha 3.14.0.  My primary goals, if elected, are:

• Continuing our tradition of solid, well-tested releases.
• Experimenting with the structure of the release team to spread the work and knowledge around.
• Dealing with and finalizing long-outstanding patches and feature requests
• Broadening Koha's appeal and making it ready for a post-MARC world.

I have the support of my employer to commit significant time to this role.

Organization of the release team

The Koha Release Manager has traditionally been the sole individual (at any given point in time) authorized to push patches to the master branch.  This has given us some advantages: it allows for a unity of architectural vision, it gives us an additional level of patch review after the sign-off and QA process, and empowers to RM to push back on patches that are not quite ready for prime time.  I also think that giving the RM a personal stake in the success and quality of a particular release provides good motivation.

However, the unitary RM model also has some disadvantages.  Having only one RM can contribute to a backlog of patches.  It puts a lot of work and responsiblity on one person, leading to the distinct possibility of RM burnout.  And given the breadth of Koha's functionality, it's increasingly unlikely that any one individual can be equipped to personally test in depth each and every patch.

To lay the groundwork for spreading the release work around, I intend to try the following experiments during my tenure as RM:

1. Naming module maintainers.  By module maintainer, I mean somebody who is an expert in an area of functionatlity (e.g., reports) and who agrees to actively maintain a Git tree of vetted patches related to that module.  If a module maintainer does a good job, it opens up the possiblity of the RM being able to pull it a group of branches from the maintainer's tree in one fell swoop, confident that the module maintainer has thoroughly tested it.  Over time, it might be possible that a trusted module maintainer would get authorization to push patches for their module directly to master.
2. Naming master branch committers.  These would be folks who share in the day-to-day work of reviewing QAed patches and pushing them to master.  Committers would be expected to use their best judgment when applying patches, but also to follow guidelines discussed by the current RM and the Koha development community as whole.  In time, this model might evolve to one where the release manager is just a named "first among equals" among the master branch committers whose primary responsibility is to be a final decision-maker in the case of dispute.

These experiements may or may not work, but with any luck during 3.14 we will succeed in laying some groundwork for the release management load to be shared.

If any folks are interested in becoming a module maintainer, please let me know.

Major architectural and feature goals

My primary goal for 3.14 will be to significantly reduce the backlog of patches that has accumulated over the past few years.  However, I also have some specific architectural goals:

1. Improve sharing of code with other projects.  In particular, I'd like fold Koha's custom fork of SIPServer back into the standalone SIPServer project, and work with packages to have SIPServer become available as a stand-alone package.  Another project I'd like to at least start is folding in the MFHD-handling code from Evergreen and spinning that out of as an indepdent Perl module.
2. Building on the Solr and Zebra DOM work and efforts to rewrite the search-subsystem, with the goal of having true pluggable search backend support in 3.14.0.
3. Adding support for non-MARC metadata.

Communication

I will continue to practice of a writing a monthly RM newsletter to be sent out via email to the mailing lists.  I will also do a (roughly) weekly RM summary blog.

To help encourage the spread of knowledge about the mechanics of performing the RM and RMaint roles, I also intend to do targeted blog posts and/or videos going into some depth.  Examples of topics I might present include:

1. How to resolve a merge conflict.
2. Techniques for managing large topic branches.
3. A video showing the mechanics of cutting a release tarball.

Timeline

I propose the following general timeline:

• 23 May 2013: we start (blearily) the push to 3.14.0
• 30 August 2013: release of pre-pre-alpha 3.14 - after this point, major architectural changes will be discouraged
• 25 September 2013: feature slush
• 3 October 2013: feature freeze
• 31 October 2013: string freeze
• 21 November 2013: release of 3.14.0