Estimates This is a topic which I fully understand what is happening with the versions, and what I personally favor is changing URL and the business sense behind that there Koha, Koha we adopt in our University and thanks to community and (http://koha-community.org/) achieves important objectives.
I do not think there is another alternative as this community that we are the programmers who love freedom. Never fails KOHA (http://koha-community.org/) from Bolivia. Thanks. Christian Jhonny Calle Jahuira TUTOR ELEARNING - UMSA Consultor Sistemas de Informacion de Bibliotecas de la UMSA Email: [email protected] Cel: 73017301 On Tue, 7 Jun 2011 13:34:25 -0700, Clay Fouts <[email protected]> wrote: > Hello, Paul. > > What you describe here is an insightful analysis followed up with a > perfectly valid decision that embodies that priorities you've set for > your business in order to benefit your customers. There is a value in > seeking to keep in sync with the git.koha-community.org [1] repo, and > there is value in diverging from it. It's a matter of personal and > business priorities which path to take, and I respect everyone to make > that decision for themselves. > > Cheers, > Clay > > On Tue, Jun 7, 2011 at 6:38 AM, Paul Poulain wrote: > Le 06/06/2011 18:05, Clay Fouts a écrit : > >> Each vendor has their own (sometimes very large) customizations > that > > they may or may not port back into community code. The community > RM > > may or may not accept these back ports even if effort is made to > > rebase them. Please point to the line distinguishing "Koha" from > "not > > Koha". > Well, I think we are mixing 2 things : > * local & specific customizations > * fork > > a local and specific customization: it occur very often. For > example, > one of our customer has very long barcodes, and the barcode length > in > the database is not enough for them. it's specific to the customer, > and > has nothing to do with a public version. Sometimes, it's not that > small > (even if it's local). For example, for Aix-Marseille universities, > we > changed the circulation (check-out) workflow to query a NFC reader& > database. The NFC card & database is responsible to say if a card is > valid and fill the members table in Koha database. This is > OpenSource > (GPL), available on our public git repo, but won't be submitted to > the > community, it's useless unless you've this exact technology. I agree > it > can be worth for a library using the same NFC technology and we > could > have announced what we made more widely. Our fault, nobody's perfect > (announcement : if you've a 'horoquartz' NFC technology, you can > drop me > a mail ;-) ) > > a fork. Do we have a fork ? Frankly, yes, but 1- we didn't wanted > this > to happen, 2- we do all what we can to fix this (yes we consider > it's a > "bug"). Reminder about the history : Koha 3.2 has been delayed due > to > events we all know here (for newbies, see : > http://lists.katipo.co.nz/pipermail/koha/2011-February/027657.html > [3]), > thus many feature we have developed have needed too much time to > reach > master (and had to be splitted/merged/...) > > I'm on my way to write a mail on our blog to detail how it happens, > why > we consider it a bug (and want to fix it), and what's the strategy > to > avoid it to happen again. > In a few word: > * we deploy only community version > * if you sponsor a feature 2 options : you sponsor and use it live > when > it's in master, you sponsor, go live immediately. BUT if it's not > included in master, then you'll have either to choose to switch back > to > community version (and forget you stuff), wait until it's in master, > sign a specific contract for support from BibLibre (or someone else) > to > have your nice-feature-not-in-master rebased regularly vs master. > * there are only a few things in "3.2 biblibre" that are not in 3.4, > and > everything will be in 3.6. > > > Is BibLibre's fork Koha? They have substantial, potentially > > irreconcilable differences that appear not to be destined for the > > community base and their extremely patient efforts to point this > out > > and seek solution are met with little more than a dismissive that > > "well, that's your problem." Who is or isn't cooperating this > case? > Well, you're not completely wrong. I'm sometimes quite upset by > "community". And I'm sure "community" is sometimes upset by me too > ;-) . > But I still think it's better to have strong discussions and > arguments > than doing our way without "the community". > > Hope that explains > > -- > Paul POULAIN > http://www.biblibre.com [4] > Expert en Logiciels Libres pour l'info-doc > Tel : (33) 4 91 81 35 08 > > _______________________________________________ > Koha-devel mailing list > [email protected] [5] > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > [6] > website : http://www.koha-community.org/ [7] > git : http://git.koha-community.org/ [8] > bugs : http://bugs.koha-community.org/ [9] > > > > Links: > ------ > [1] http://git.koha-community.org > [2] mailto:[email protected] > [3] > http://lists.katipo.co.nz/pipermail/koha/2011-February/027657.html > [4] http://www.biblibre.com > [5] mailto:[email protected] > [6] > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > [7] http://www.koha-community.org/ > [8] http://git.koha-community.org/ > [9] http://bugs.koha-community.org/ -- Atte -- Christian Jhonny Calle Jahuira TUTOR ELEARNING - UMSA Consultor Sistemas de Informacion de Bibliotecas de la UMSA Email: [email protected] Cel: 73017301 _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
