[Koha] Koha releases - Clarification/correction

david at lang.hm david at lang.hm
Wed Jul 7 19:09:17 NZST 2010


On Wed, 7 Jul 2010, Chris Cormack wrote:

> From: Chris Cormack <chris at bigballofwax.co.nz>
> 
> 2010/7/7  <david at lang.hm>:
>> On Fri, 2 Jul 2010, vtl at scls.lib.wi.us wrote:
>>
>>> From: "vtl at scls.lib.wi.us" <vtl at scls.lib.wi.us>
>>>
>>>> What seems clear from this exchange is that PTFS/Liblime believes that
>>>> it is the responsibility of others to integrate their code into Koha
>>>> rather than something that is inherent to the process of working on an
>>>> open source project. If this is the case, then LEK and Harley are not
>>>> trunks. They're forks.
>>>>
>>>
>>> Owen--how is that clear?  When did anyone say that PTFS/LibLime believes
>>> that it is not their responsibility to integrate the code?  I was at the
>>> very same meeting.  LEK is a fork that PTFS inherited, yet I understood
>>> from
>>> the meeting that they are committed to contributing it to Koha, difficult
>>> as
>>> that may be.
>>>
>>> Nothing that they said about Harley led me to believe that they think it
>>> is
>>> the community's responsibility to integrate the code.  I believe that
>>> there
>>> are several people at PTFS/LibLime who understand the process and they
>>> have
>>> already put a lot of work into Koha.
>>
>> both sides will need to work to integrate this functionality (or re-write it
>> if that ends up being easier)
>>
>> having either side take the attitude that it's all up to the other side will
>> only make the problem drag out longer. It's very unfurtunant that this
>> problem is here, but the entities that decided not to merge the code earlier
>> are no longer around, and it's far better to assume good intent on the part
>> of their replacements than it is to punish the reaplacements for the bad
>> actions of their predesessors.
>>
>
> Hi David
>
> I don't think anyone is punishing the replacements for their
> predecessors, at least I am not. What I am reacting to is the policy
> that came out at the liblime users group meeting at ALA. Which states
> that code will be developed in isolation by PTFS, it will then go
> through a testing phase, and then liblime customers will get it for a
> period of 6 months. At that point it will then be placed in a public
> repository for the rest of the world.

part of what I was responding to was in a message that I appear to have 
deleted where someone worded it as if the work to be done needed to be 
done entirely by PTFS. The point I was trying to make is that that 
attitude is also damaging (or at the very least it can significantly 
prolong the existing damage)

> At no point in that plan is there any consideration for integration,
> or is there any recognition of the fact that for the code to have any
> value at all to the wider koha community that it would need to have
> been rebased off master at regular intervals.
> As in illustration, in the last 6 months of koha development, there
> have been over 1000 patches added to Koha.
>
> 2010-07	019
> 2010-06	103
> 2010-05	203
> 2010-04	120
> 2010-03	146
> 2010-02	305
> 2010-01	154
>
> So let alone the time it takes to develop factored in, code based on
> Koha as it was 6 months ago, needs a significant amount of work to
> bring it up to a point we could even begin to merge it.

I fully recognise this fact. I'm used to thinking in terms of kernel 
development cycles (much higher rate of change, but also a bigger code 
base to have changes in)

> What I am is concerned about is that PTFS are repeating the mistakes
> of their predecessors. There is still no commitment to send patches
> for the code in a form that can actually be applied. That sounds to me
> exactly like Owen describes.

that is a very valid concern, I'm in no way objecting to it.

> There is a rumour that a document describing the Liblime development
> procedure has been sent to the Liblime list, it would be wonderful if
> that could be made public so that our fears could either be allayed or
> confirmed.
>
> I would like nothing better than for PTFS to begin sending patches, or
> making feature set branches available in a usable form for the
> community to integrate, after all we have over 114 developers in the
> history of Koha, they seem to have managed to be able to do it.

agreed on both points

David Lang


More information about the Koha mailing list