RE: [Koha-devel] RM for 2.4 [news from france]
-----Original Message----- From: koha-devel-admin@lists.sourceforge.net [mailto:koha-devel-admin@lists.sourceforge.net] On Behalf Of Stephen Hedges Sent: Thursday, May 05, 2005 4:23 AM To: Paul POULAIN Cc: koha-devel@lists.sourceforge.net; François-Laurent Contenay Subject: Re: [Koha-devel] RM for 2.4 [news from france]
Frankly, I am a little nervous about INEO being too deeply involved with Koha too quickly. It is a large company, with lots of resources (it's part of a much, much larger company), but that can be both good and bad.
Having been burned by our experience with Cherry Hill, I'd also prefer to err on the side of caution. I' glad to see INEO is interested and willing to help, but I think waiting for them to take on the RM until they've spent some time working with Koha is the right way to go.
So, the next question is : who, from Joshua or Ineo would be the best RM ?
I think both -- but Joshua first (2.4), then INEO (2.6 -- or even 3.0, if SAN-Ouest Provence proposes some really BIG changes) in about six months. That would give INEO time to become part of the Koha community and get very familiar with the code (and decide if they want to continue with Koha). And perhaps Chris' idea of having INEO do the QA would be a very good way to accomplish that.
I'm leaning the same way. -pate
Stephen
-- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com
------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/k> oha-devel
Hi everyone, I've put together an informal proposal outlining Koha 2.4 development should I be selected as release manager. It's available on LibLime's wiki: http://wiki.liblime.com The selections for things to do are based on: 1. features/bug fixes that NPL needs/wants 2. features/bug fixes that potential LibLime clients have asked about 3. things I've thought about or the community's talked about I still have content to add and some of the content will need to be expanded by the community (such as the roles section), but I thought I'd get it out there for folks to look at. Let me know what you think. Joshua On Thu, May 05, 2005 at 07:55:27AM -0700, Eyler, Patrick wrote:
-----Original Message----- From: koha-devel-admin@lists.sourceforge.net [mailto:koha-devel-admin@lists.sourceforge.net] On Behalf Of Stephen Hedges Sent: Thursday, May 05, 2005 4:23 AM To: Paul POULAIN Cc: koha-devel@lists.sourceforge.net; François-Laurent Contenay Subject: Re: [Koha-devel] RM for 2.4 [news from france]
Frankly, I am a little nervous about INEO being too deeply involved with Koha too quickly. It is a large company, with lots of resources (it's part of a much, much larger company), but that can be both good and bad.
Having been burned by our experience with Cherry Hill, I'd also prefer to err on the side of caution. I' glad to see INEO is interested and willing to help, but I think waiting for them to take on the RM until they've spent some time working with Koha is the right way to go.
So, the next question is : who, from Joshua or Ineo would be the best RM ?
I think both -- but Joshua first (2.4), then INEO (2.6 -- or even 3.0, if SAN-Ouest Provence proposes some really BIG changes) in about six months. That would give INEO time to become part of the Koha community and get very familiar with the code (and decide if they want to continue with Koha). And perhaps Chris' idea of having INEO do the QA would be a very good way to accomplish that.
I'm leaning the same way.
-pate
Stephen
-- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com
------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/k> oha-devel
------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
Joshua wrote:
I've put together an informal proposal outlining Koha 2.4 development should I be selected as release manager. It's available on LibLime's wiki: http://wiki.liblime.com
Please don't top-post/whole-quote. :-( I'd support: - Joshua as 2.4 RM (sorry for not posting before - I've been away) - Marking the 2.4 proposal items as SHOULD and MUST/WILL (but maybe we should say that anyone marking MUST or WILL must be prepared to help do the work?) - Moving koha24rmnotes to a wiki with the original TextFormattingRules (as I am in a maze of wikis, all slightly different... and there is a red teapot in the corner of the room.) I don't know how much say I have or should have. When's the next "koha town hall" IRC or telephone meeting? -- Thanks, MJR/slef http://www.ttllp.co.uk/koha/
Joshua: I'm browsing your proposal. I'm not a core developer but this are my two cents: As we're diving into the code we find many repeated code. On the other hand I think that Koha will gain a lot if it get rid of the non marc database. About speed: We have gained a lot with mod_perl. I encourage others to test it and make improvments. We're currently developing extensions and bug fixes needed by our library. Many of ths extension might colide with the Argentinian developed code, but we couldn't wait till they decide to let others access to their code. It's a pity, since we have similar requirments and we're very near from Buenos Aires and La Plata in Argentina (We're based in Montevideo, a few hours by sea from both cityes). Andres Joshua Ferraro wrote:
Hi everyone,
I've put together an informal proposal outlining Koha 2.4 development should I be selected as release manager. It's available on LibLime's wiki: http://wiki.liblime.com
The selections for things to do are based on: 1. features/bug fixes that NPL needs/wants 2. features/bug fixes that potential LibLime clients have asked about 3. things I've thought about or the community's talked about
I still have content to add and some of the content will need to be expanded by the community (such as the roles section), but I thought I'd get it out there for folks to look at.
Let me know what you think.
Joshua
Andrés Tarallo a écrit :
Joshua:
I'm browsing your proposal. I'm not a core developer but this are my two cents: As we're diving into the code we find many repeated code.
That problem is hard to avoid with source developped by many people. It can partially be solved with a solid API & API documentation (which we have only partially, I agree)
On the other hand I think that Koha will gain a lot if it get rid of the non marc database.
I'm not sure at all. You must remember Koha is multi-MARC, so, a "title" may be in different places. It is very CPU consuming to search everytime "where is the title ?". It's better to store it definetly during biblio adding process.
About speed: We have gained a lot with mod_perl. I encourage others to test it and make improvments.
could'nt give it a try. But still expect to be able to one day...
We're currently developing extensions and bug fixes needed by our library. Many of ths extension might colide with the Argentinian developed code, but we couldn't wait till they decide to let others access to their code. It's a pity, since we have similar requirments and we're very near from Buenos Aires and La Plata in Argentina (We're based in Montevideo, a few hours by sea from both cityes).
Everybody agrees on this, hélas... -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
Paul POULAIN wrote:
That problem is hard to avoid with source developped by many people. It can partially be solved with a solid API & API documentation (which we have only partially, I agree)
It can be avoided :). We should work to enhace the API.
On the other hand I think that Koha will gain a lot if it get rid of the non marc database.
I'm not sure at all. You must remember Koha is multi-MARC, so, a "title" may be in different places. It is very CPU consuming to search everytime "where is the title ?". It's better to store it definetly during biblio adding process.
In the same way we "cache" some tables in C4::Context this can be done with "translations" between the marc field number and its meaning. Some databases supprt "in memory" tables, this could speed up searches in tables and working in the way I'm proposing.
About speed: We have gained a lot with mod_perl. I encourage others to test it and make improvments.
could'nt give it a try. But still expect to be able to one day...
It works, we will have in a near future our ssystem in production. Another enhacement to performance can be done writing some modules in C with bindings to PERL. Andres
Paul POULAIN wrote:
Hi,
In french, we usually write surnames in capitals (POULAIN) and firstnames with 1st letter in capitals (Paul)
Is it a behaviour that is international or french specific ?
My mom writes people's names this way (here in the U.S.). I haven't seen any other American people do it. Lots of the Japanese people on the ruby-talk mailing list put their surnames in all capitals; this is particularly important because Japanese custom is that your surname comes first. So if you write to a mailing list with English-speaking people on it, you might switch around your names, or you might not. But if you capitalize your family name, everyone knows. (d'oh, sorry for the doublepost rachel, gmail replying woes)
participants (6)
-
Andrés Tarallo -
Eyler, Patrick -
Jared Jennings -
Joshua Ferraro -
MJ Ray -
Paul POULAIN