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

[Chris Cormack]

On 22 June 2010 22:01, MJ Ray <mjr at phonecoop.coop> wrote:
> 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.
>
Mantis is their Bug tracker, so I dont think Paul was saying the
private data is in the code, more that it is in their bug tracker.
Which seems fine.

But just in case they do mean in git. Here is a good tutorial on
removing sensitive data.
http://help.github.com/removing-sensitive-data/
It isn't actually that bad (no flame intended :)).

> 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".
>
I don't think there is a need for a fork in this case, once the
patches are rebased on master, and pushed into their own branch, we
can divide them up, test and merge. But in the meantime once that
branch is based on master, and rebased regularly, it's very simple for
people to merge that into a branch in their own repository, until its
all in master.

Chris