Re: [Koha-devel] Release Manager 3.6
On Wed, May 11, 2011 at 2:01 PM, Chris Cormack wrote: > Hi All > > Recently I have been having a crisis of confidence. I have, I hope, > always tried to do what I think is best for the project. Often I do > make mistakes, a notable one happened in 2007, which I hope I in part > was rectified in 2008. But my underlying motivation with Koha has > always been to do the best for the users of the software. > In my role as Release Manager for 3.4 (and again for 3.6) what I felt > was best for the software users was a stable and well tested release. > This is something I made clear in my proposal, and which I had assumed > was understood (but you know what they say about assumptions ;)). With > the huge amount of work put in by over 80 people, I think we managed > to achieve some measure of success with that with 3.4.0 and that the > stability of the 3.2.x releases is something we can all be proud of. > > Over the last couple of weeks, comments and mails both on and off list > have made me think that maybe I am out of step with what the community > desires. For 3.6 quality was still the major goal, but perhaps I have > misjudged what others want. This has resulted in sleepless nights and > quite a large amount of self doubt. First of all, Chris++ for the hard and good work he is doing every day. For a noob like me its leadership has been really inspiring and I'm comfortable with the current workflow which I think . As a 'small' (+30 libraries/koha deploys) contributor University, we've faced several times this problem Paul brought into discussion last year about BibLibre's difficulties to make community development roadmap/process fit their own's, and its' business model. Even if we are a small non-profit contributor we 'felt the same' [1]. I think it is not easy to avoid this problem: the tension between community established roadmap and the needs of a third party's business. Companies like BibLibre have made Koha the great piece of software it is now (the same goes for LibLime and other companies), so it is not just BibLibre's problem. Community and third parties roadmaps diverge easily. As Paul said, perhaps forking is the only solution for a business model if we don't find a proper solution. I'd like to see an approach that provided a proper semi-formal way to make strategic decisions on the future of the project, so that third parties can propose the community a "big feature" or a "big change", and the core developers can plan on how the integration will be done. If it fits the business model (i.e. secrecy is not a need for it), maybe even make external core devs have access to relevant information on the inside development process: develop on the open. I'd like to elaborate a bit more on the need for a strategic decision taking mechanism, but i've been busy with other project for which i'll fly to europe tomorrow. Maybe I get some more time to spend in koha in a few weeks. Thanks for all the hard work and good will put into this discussion. To+ [1] We even stopped developing some features our librarians asked for until we could understand and fit into the dev community and the process itself. WE DON'T WANT TO FORK. Several times we had the feeling we could have spent our money/time in a more feature-providing way, but where confident that we could make our voice into the dev community. Day suspension fines is a feature we proposed to develop ourselves with some core-developer guidance but only got this answer: "liblime has developed that, wait for them to merge their branch". We are currently working with a small, harmless fork we can maintain updated. ___ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
Re: [Koha-devel] Release Manager 3.6
On 13/05/11 15:05, Tomas Cohen Arazi wrote: > [1] We even stopped developing some features our librarians asked for > until we could understand and fit into the dev community and the > process itself. WE DON'T WANT TO FORK. Several times we had the > feeling we could have spent our money/time in a more feature-providing > way, but where confident that we could make our voice into the dev > community. Day suspension fines is a feature we proposed to develop > ourselves with some core-developer guidance but only got this answer: > "liblime has developed that, wait for them to merge their branch". We > are currently working with a small, harmless fork we can maintain > updated. I think there is a problem with the process that rfc's stake out areas out areas of development then people wait around until the original proposer delivers putting things on hold. If it doesn't get delivered, delivered when expected or as expected then everyone loses out. Really until you show some code its all wishful thinking. ( I have a number of projects that will solve the world's ills but I've not released any code yet ). We should not be fearful of forking, the license we use could be seen as encouraging it but insisting that having forked you preserve the rights to the code you have just taken advantage of. With regular scheduled releases its easier to keep the fork in touch with the main branch which also makes it easier to fold it back in to the main line of development, because even if your fork has features that others may not want, you want all the good stuff that is in the main branch. As a community we are very good at implementing the middle range features (and don't belittle them they are what most of are users cherish in the system ). We're a bit less good at the big chunks of functionality but I'm sure thats fixable, (and Chris's successful shifting to TT for 3.4 shows big things can be done). We're also a bit behind the curve on the plumber like code maintenance tasks ( we are going to have use warnings in all scripts oneday, right?) that have less visible user impact but aid future development and avoid introducing bugs. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campb...@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com ___ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
[Koha-devel] Z3950 UNIMARC
Hie, For the first time, I have enabled the SRU on Zebra server by editing koha-conf.xml : tcp:@: > > /var/lib/zebradb/biblios > /etc/koha/zebradb/zebra-biblios.cfg > /etc/koha/zebradb/pqf.properties > > > > > > > /etc/koha/zebradb/ccl.properties > > > > I Koha administration, I added this Z3950 server. It works well but : I have installed everything in UNIMARC and SRU only works when : - I configure the server Z3950 with USMARC/MARC21. - I configure retrieval syntax="usmarc" instead of "unimarc" Does that mean that Zebra internal database is always in USMARC ? Thanks for your help. -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.som...@gmail.com ___ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
Re: [Koha-devel] Z3950 UNIMARC
Le 13/05/2011 18:33, Fridolyn SOMERS a écrit : > Hie, > > For the first time, I have enabled the SRU on Zebra server by editing > koha-conf.xml : > > tcp:@: > > /var/lib/zebradb/biblios > /etc/koha/zebradb/zebra-biblios.cfg > /etc/koha/zebradb/pqf.properties > > > > > > > /etc/koha/zebradb/ccl.properties > > > > > > I Koha administration, I added this Z3950 server. > > It works well but : > I have installed everything in UNIMARC and SRU only works when : > - I configure the server Z3950 with USMARC/MARC21. > - I configure retrieval syntax="usmarc" instead of "unimarc" > > Does that mean that Zebra internal database is always in USMARC ? > > Thanks for your help. Well, it means that internally, zebra thinks that data is always usmarc and exposes data as such. Consider that as a bug or not, that could be changed but would require some deep changes both in Koha Code and zebra configuration. And require reindexation. I think that some users in France had it right on their configuration... But I could mislead myself. Hope that helps. -- Henri-Damien LAURENT ___ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
Re: [Koha-devel] Z3950 UNIMARC
Old story: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3087 http://www.mail-archive.com/koha-patches@lists.koha.org/msg01881.html -- Frédéric DEMIANS http://www.tamil.fr/u/fdemians.html ___ Koha-devel mailing list Koha-devel@lists.koha-community.org 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/
Re: [Koha-devel] Release Manager 3.6
On Fri, May 13, 2011 at 12:37 PM, Colin Campbell
wrote:
> On 13/05/11 15:05, Tomas Cohen Arazi wrote:
>
>> [1] We even stopped developing some features our librarians asked for
>> until we could understand and fit into the dev community and the
>> process itself. WE DON'T WANT TO FORK. Several times we had the
>> feeling we could have spent our money/time in a more feature-providing
>> way, but where confident that we could make our voice into the dev
>> community. Day suspension fines is a feature we proposed to develop
>> ourselves with some core-developer guidance but only got this answer:
>> "liblime has developed that, wait for them to merge their branch". We
>> are currently working with a small, harmless fork we can maintain
>> updated.
FTR: I'm in no way blaming LibLime in the example I provided. It
should be read as self-criticism, probably because we feared having to
fork (we cannot afford to do it, i'm the only dev maintaining all this
stuff here) and wanted to do it "the right way" (from our perspective
as a public university this means that if we invested some hours of
human labour they should be applied to make koha better for everyone,
specially spanish-speaking/latin-american users that, as Paul said,
have interests in features NZ and US libraries don't even think about
in their daily workflow ("who is interested in signing BZ6328 i just
submitted ?": me)).
I agree with the concepts you provided.
Regards
To+ (with a parenthesis nightmare)
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/
