[Koha-devel] Proposal to be RM for 3.14

[Galen Charlton]

Hi,

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

1. Continuing our tradition of solid, well-tested releases.
2. Experimenting with the structure of the release team to spread the
work and knowledge around.
3. Dealing with and finalizing long-outstanding patches and feature requests
4. 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 responsibility 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 functionality (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
possibility 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 experiments 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:

* How to resolve a merge conflict.
* Techniques for managing large topic branches.
* 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

Regards,

Galen
--
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org