[Koha] Koha releases

Chris Cormack chris at bigballofwax.co.nz
Fri Jul 2 20:10:54 NZST 2010


Hi Stacy

On 2 July 2010 19:46, Stacy Pober <stacy.pober at manhattan.edu> wrote:
> Owen Leonard <oleonard at myacpl.org> wrote:
>>I certainly hope PTFS will not
>> release an update to Harley. I would hope their efforts are being put
>> into integrating it into the real Koha instead.
>
> A few days ago, at the Liblime Users Group meeting held at the ALA
> conference, customers  were told that LibLime plans to merge Harley
> and LEK (Liblime Enterprise Koha) at some point in the future.   I
> don't recall hearing any specific timeline for that.
>
> Liblime also displayed a policy document regarding code release of
> their software.  I think they said it was on their website, but I
> can't find it right now.  I just emailed them for a link or copy of
> it, but for now I'll give you a summary based on my memory of what was
> shown..  AIR, the policy says that sponsored software featureswill go
> through a testing cycle with the sponsoring organization, then will be
> released to other Liblime customers for six months.  After that, the
> code will be released to the larger Koha world.
>
> As I understand it, most of the enhancements sponsored by one of the
> customer groups (the group sponsoring most of LEK features, I think)
> are currently contractually defined as a single project rather than
> individual enhancements.  So until the full "bundle" of enhancements
> goes through the full process of testing and deployment to the other
> LEK customers, no part of it will be released.  After the "Phase I"
> project is finished, which is scheduled for the end of 2010, then
> those enhancements will be released to other LEK users, so if there is
> a release of that code, it is unlikely to be prior to the middle or
> end of 2011.   That date assumes that the project finishes on time. I
> believe the original date for the end of Phase one was summer, 2009,
> so this schedule may be overly optimistic.
>
> Since the "phase I" includes a large number of features, I asked in
> the meeting  how long they thought it would take for those  to be
> integrated into the official community version of Koha.  The estimate
> I was given was  four to five years.
>
> I must admit I don't really fully understand the process in which
> sponsored enhancements are integrated into the official Koha software.
>  Is an evaluation done for sponsored features before they are
> integrated into the software?  I would think the programmers involved
> in each release would want to evaluate them to see whether they in
> fact are improvements over the either the current software or whether
> another feature supplied by a different support vendor may accomplish
> the same functionality in a better way.   If such evaluation is done,
> who does it?

One quick bit, almost every single bit of Koha has been paid for by
some client along the way, there is very little that isn't sponsored,
so this isn't some new thing.

How it had worked for the 9 year previous to the LEK fork, and how it
still works for everyone else is that features or bugfixes are sent as
patches when they are ready. And it is the Release Managers job, often
in consultation with others to decide whether the patches are accepted
and pushed up. Before the work is done, a bug is logged in bugzilla
and if it is a feature an RFC (request for comments) document is put
up on the wiki for others to comment on. This usually stops duplicated
effort.

The community elects a release manager after each release, for the 3.4
release, I was elected Release Manager. Colin Campbell from PTFS
Europe was elected QA Manager, his job is to check for code quality
and whether the code adheres to the coding guidelines. Chris
Nighswonger was elected release maintainer, he will be looking after
3.2.x making 3.2.1, 3.2.2 releases etc as they are needed. We then
have Calyx,Jesse Weaver and Henri Damien being bug wrangler, keeping
an eye on bugzilla closing bugs, making sure patches aren't missed
etc.

Everything is done in public on mailing lists or publicly logged irc
channels and all the developers bar PTFS/Liblime develop publicly
also, so even if the patches aren't ready to be sent their public
repositories are there for anyone to look at/test.
Developments from most vendors are sent as patches as they are
completed, this stops the need for spending huge amounts of time
integrating code that is based on something that existed 5 years ago
instead of something that exists now.

Integration is made much easier and less error prone if people keep
their repositories up to date with the master branch and don't let
patches get out of date. Certainly if no help is forthcoming from the
developers who wrote the code when it is finally made public
integration is made much harder.

The theme we have for the developer conference after Kohacon10 this
year is distributed development, and how to maximise the benefits of
this for all. I hope PTFS will send some developers, we have
developers from France, Norway, Germany, Taiwan, Australia, NZ and the
US coming along.

>
> We have had at least one instance when we were told that a feature of
> official Koha would have to be sacrificed in order for a LEK feature
> to work correctly.  I don't know whether that is going to be a common
> issue, but I assume that within the official Koha project, there  is
> some decision-making protocol for deciding whether a new feature is
> worth  more than the existing feature that it disables or worth
> integrating at all if there is an existing feature developed elsewhere
> that adds the same functionality.
>
A feature that broke an existing feature would not be accepted, the
developers submitting it would be asked to fix it so that it didn't.

Chris


More information about the Koha mailing list