[Koha] Commentary on Paul's Koha 3.8 Release Manager proposal

[Ian Walls]

Everyone,


Enclosed is my response to Paul Poulain's proposal for Koha 3.8 Release
Manager.  The details of his document can be found here:
http://wiki.koha-community.org/wiki/Proposal_paul_p_RM38

I thoroughly agree that the time has come to start thinking beyond the next
stable release, and on to Koha 4.0.  Those of you who have seen either my
presentation at KohaCon 2010's hackfest or KUDOScon 2011 know I'm very
excited about the possibilities of where we can take Koha in it's next major
iteration.  However, I disagree with a couple of the details of Paul's
proposal.

The major disagreement is with the timeline.  The proposal as it stands is
to start working on Koha 3.8 and Koha 4.0 in parallel, with Koha 3.8
releasing April 2012, and Koha 4.0 releasing Oct. 2012.  I feel that going
from Koha 3.8 directly to 4.0 is unwarranted.  To my mind, there are many
possible releases between 3.8 and 4.0, like 3.10, 3.12, 3.14 and so forth.
This is supported by the actual database version numbers in Koha: the
current release is actually 3.04.04; the zeros are squashed out for
convenience.

I would counter that, while we should continue releasing new features every
6 months on the 3.X line, Koha 4.0 should be defined by it's features.
Paul's proposal calls several features to be key, including Solr
integration, database abstraction, updated online help, improved
authentication stack and automated tests.  I agree that all these things are
important and should be worked towards, but I'm not convinced they should be
the sum total of the changes that define Koha 4.0

I would like to see the following in Koha 4.0:

   - arbitrary metadata formats (beyond MARC)
   - arbitrary biblio relationships
   - full support for authority records, including uploading through the
   GUI, automatic linking, "explode" searching and more
   - improvements to the borrower data structure (fewer pre-defined data
   fields, more flexibility)
   - separation of "receiving" and "payment" in acquisitions
   - serials import and export (MFHD, prediction patterns, etc)
   - many, many more things

I think that the community should meet and discuss what features are both
desirable and reasonably likely to be completed in the next few years (is
there interest by libraries to sponsor these developments, or from
developers to code it "for fun"?).

Once a feature set is agreed on to "define" Koha 4.0, the developers of
these features would meet to hash out what underlying structural changes
would be required to make them happen.  Hopefully commonalities could be
found, so that the underlying structure could be developed in a way that
accommodates multiple developments at once.  Identifying these prerequisite
changes early on would reduce the difficulties of rebasing developments,
since we'd all be working off a similar set of base assumptions.  It would
also provide a reasonable basis for excluding or delaying developments that
don't fit into the overall plan.

Once the features were chosen and a framework for their development agreed
upon, it would be time to code.  The development and submission process
would be the same as it is now (basing patches off master and submitting to
the patches listserv and Bugzilla).  As new features become ready, they
would be incorporated into the time-based 3.X releases by the release
manager for that particular cycle.  This way, what works is made available,
and what needs more time continues to be tested until it's stable for
production use.  Once all the agreed upon features were ready, it would be
time to release Koha 4.0.  Hopefully, that would be with 1-2 years, but
there would be flexibility here.

One of my other issues with the proposal was the "lightening" of Quality
Assurance standards for the first 3 months of the 3.8 release cycle.  If
operating under the 1 year time frame for Koha 4.0 as outlined in Paul's
proposal, this would seem necessary in order to get everything included in
time.  Unfortunately, while the next 3 months would be dedicated to clean up
of features rolled in, there is never any guarantee of bug fixes being
generated in a timely fashion.  You cannot force people to write or sign off
on bug fixes; we're all free agents here.  So code that has not been
rigourously tested could get in and stay in for a long time, long after 4.0
would release, because no one knows how to test it or fix it.

However, if we operate under my proposed model, all code could continue to
operate under the same quality assurance standards, and nothing that is
broken or otherwise incomplete would make it in until it was ready.
Releases would still come out every 6 months, even if a major development
was inoperable, until that development could be completed.

This has been a long email, so let me sum up.  I think:

   - we should continue to release Koha 3.8, 3.10, 3.12 etc on 6 month
   cycles using the current community practices for feature inclusion
   - we should, as a community, meet and decide what features we want to
   define Koha 4.0
   - the developers of those features should get together and come up with a
   unified plan for accomplishing them all, in a way that requires minimal
   rebasing
   - as new features become stable and tested, they should be folded into
   the 3.X line until all the features defined as "Koha 4.0" are ready
   - Once all the agreed upon features are complete, Koha 4.0 is then
   released.

I've already gotten some feedback on this in today's Koha IRC meeting, but
I'd very much like to hear what the rest of the community thinks about this,
particular in relation to Paul's proposal for 3.8 Release Manager.  Our time
is limited for discussion, as the election time draws near, but hopefully
I've made my thoughts clear enough for a dialogue to get started.  Please
let me know if I've been at all unclear.

Cheers,


-Ian

-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katipo.co.nz/pipermail/koha/attachments/20110907/fe571397/attachment.html>