[Koha-devel] BibLibre strategy for Koha 3.4 and next versions

[MJ Ray]

Paul Poulain wrote:
> Le 21/06/2010 21:48, Chris Cormack a écrit :
> > We simply can't merge 450 patches now and not expect to make our lives
> > much much harder in the future. I'm willing to work on making smaller
> > feature sets, it will help a lot if the commit messages relate to bugs
> > in bugzilla, that will make making them much easier, if not I will be
> > asking Biblibre lots of questions.

A small thing to flag up: software.coop is in a similar position.  We
have had a fork since LibLime pushed new features into HEAD which
didn't work yet on platforms we were contracted to support.  So, we
had a similar fork-or-fail choice to BibLibre and reached the same
unhappy decision.

I've been trying to tidy+push changes and move us towards merging, but
that work has slowed this year because something was up with email
pull requests and I had some large urgent paid projects.  It's also
been complicated by conflicting changes from LibLime being submitted
as part of Harley.  And merging gets no easier as more time passes.
I'm sure BibLibre will appreciate this: it sounds like it's hard
enough for them merging a fork after some months - ours has existed
almost two years or so now :-(

It's a double whammy: it means we're not testing and fixing the next
Koha release.  If big players like BibLibre are also in a similar
situation, how much of the Koha 3.2 slip has this caused?

> There is a "good" news I forget to speak of yesterday (it was 10PM, &
> i'm very busy, so very tired, those days) :
> Most (if not all) commits are related to a BibLibre mantis entry.
> Features and bugfixes.
> 
> The bad news : it's all in french.

I don't care.  Submit the French.  Then either us franglais speakers
can translate on demand, or people can use machine translation to get
the gist of it.  It's far better than having a cryptic "MT" reference
to something most of us can't read.

> The good news :
> 1- it should help seeing what is related to what
> 2- we could open our mantis repository to some of you. Note it contains
> a lot of private informations (about data migrations, comments,...), but
> we have sub-projects for every curstomer & split migration / feature
> devs, so we should be able to open only what needs to be open.

Aha!  So BibLibre made the same mistake we did with private
information polluting our koha development work!  I'm sure I remember
being flamed about how simple it was to avoid or clean that.  It's not.

Nevertheless, it's good to see BibLibre following in our footsteps.
I hope we can find some better solution than either the unhappy
forker doing all the clean-up, or the confusing competing-release
approach of PTFS Harley which leaves the community doing all the work
as well as answering questions from users about the new Koha "release".

Regards,
-- 
MJ Ray (slef)  Webmaster and LMS developer at     | software
www.software.coop http://mjr.towers.org.uk        |  .... co
IMO only: see http://mjr.towers.org.uk/email.html |  .... op