Hi Stacy On 2 July 2010 19:46, Stacy Pober <stacy.pober@manhattan.edu> wrote:
Owen Leonard <oleonard@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