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 _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
