[Koha] Koha releases

[Lori Bowen Ayre]

I think this gets at the crux of the problem that the community has been
dealing with for some time.  As I understand it, Liblime's customer insisted
on development somewhat off the grid so they were sure to get *their*
deliverable.  So the farther away their development got from the community
version (and no one in the community had any way of knowing what was in that
other version), the bigger the hurdle has become for integration.  One
*could* blame the situation on the customer...

I hope that after KohaCon, a clear procedure is established that guides
developers and people who contract with developers to ensure that
development contracts include re-integration of the contracted code into the
community version.This "development in the dark" approach has resulted in
lots of good enhancements AND new features that are based on very old code
making them nearly impossible to integrate into the community version.  And
there are conflicts between features because the 'has been dumped at the
door of the rest of the community to resolve.This in turns slows down
everything else. Part of the reason 3.2 has been delayed has to do with this
very issue....trying to integrate as much of the Liblime/PTFS code that was
based on an older version of Koha.

I believe it should be the job of the developer to ensure their code is
based on the current version of the product and not leave it to the rest of
the community's developers to wrestle with.  If it is the job of the
developer to do that, they will ensure that this process is written into
contracts with customers.  Then, when customers insist on developing huge
blocks of code (multiple new features), they will know what that means --- a
much bigger cost to them because of the gargantuan effort involved in
getting their final product back into the community version.

The customer must also be made to understand that the "code in the dark and
don't share 'til it's all done" approach -- that takes months, if not years
-- is not only more expensive (assuming we expect the customer to pay for
the ultimate re-integration of the code) but it is likely that they will not
get the same product in the end because of the inevitable conflicts.  I
doubt that the client WANTS to stand alone on their own unique version of
Koha.  I doubt those conflicting features were so important that they were
worth not having access to the rest of the community's contributions?  I
suspect if the features had been developed as Paul described (in the RFC
light of day) they would have resulted in conflicts.

In other words, if the process hadn't been in the dark, the client probably
could have had their cake and eat it too.  Maybe even eating it right now.

Lori Ayre

On Fri, Jul 2, 2010 at 6:33 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Le 02/07/2010 09:46, Stacy Pober a écrit :
> > 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.
> >
> BibLibre devs are fully & always available.
> I have recently explained on koha-dev mailing list that we face big
> problems to merge our code into main repo.
>
> I can't imagine it will be possible to merge after : time to develop +
> time to validate by the sponsoring org + 6 months ...
> (not counting features that will have been developed in // by the
> community version, just speaking of the technical pain !)
>
> --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
>
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.katipo.co.nz/pipermail/koha/attachments/20100702/9986960e/attachment-0001.htm