Hi, I will speak of the next releases. My opinion, as 2.0.0 release manager is that the next release should be called 2.0.0, without anything else. It's used in 6 libraries in France, and some others around the world. It's not perfect, but everything works. The DB has not been modified (except for indexes) since a long time. That proves, imho, that Koha 2.0.0 is stable. Except for z3950 client. But i've a customer that pays me to install Koha with a working z3950 client, so i'll work on it until it works fine (hoping it won't need 2 years :-D ) What's next ??? A lot of features are asked, here in France. Some of them may/should have funders in the next few months. Some of them require only a few hours (like the bookshelf improvement i've commited today : done yesterday in the TGV between Paris & Lyon). The french mailing list is quite active since 2 weeks : users ask for improvements. I'll write a summary of their needs next week, probably. I'll put an english version on the wiki. So, what should we put in 2.0.0 and what in 2.2.0 (HEAD branch of CVS) My opinion is : * bugfixes are put in rel_2_0 cvs branch. New releases occurs when an important bugfix is done, or some minors. * Any new translation (chinese, german, spanish...) can be put in 2.0.0. A new release occurs when a new translation is published. * everything new is put in HEAD. * CODE cleaning is done in HEAD, to avoid side effect on buggy clean. I'll begin to clean some things soon i think. BUT : * MINOR improvement, that don't need DB changes, or a really minor one, *can* be backported to rel_2_0 if the 2.0.0 maintainer want to do it. * MAJOR improvements are done in HEAD, for 2.1.x unstable and 2.2.x stable. WHO-DO-WHAT. We have a useless 2.0.0 Release Manager, as the 2.0.0 is stable. We need : * a 2.0.0 Release Maintainer * a 2.2.0 Release Manager. I don't apply as Release Maintainer. Do we have a volunteer around ? I apply as Release Manager for 2.2.0 if other ppl here like this idea. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
On 2004-02-19 15:33:48 +0000 paul POULAIN <paul.poulain@free.fr> wrote:
I don't apply as Release Maintainer. Do we have a volunteer around ?
After repeated prompting, I'll go for this. If you make me 2.0.0 RM, I will:- 1. Only allow bugfixes into the main tree and try to avoid DB structure changes; 2. Aim for every new 2.0 bug squashed within a week of report, time permitting; 3. Ask the 2.2 team to port 2.0 bugfixes or note they don't apply (= no 2.0 bug gets closed without it) for at least the first 3 months; 4. Make a new release after fixing a blocker or critical bug; 5. Make a new release at most 6 weeks after fixing a bug, with at least 2 prereleases; 6. Introduce an alternative to the z3950daemon; 7. Help to update the koha manuals.
I apply as Release Manager for 2.2.0 if other ppl here like this idea.
Before deciding what I think on that, I would like to hear how and when you plan to reach 2.2.0 - when will 2.1 series releases and freeze happen? (I'd prefer to see 2.2 before late October...) What are the first set of new features to go into main? -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/
MJ Ray wrote:
On 2004-02-19 15:33:48 +0000 paul POULAIN <paul.poulain@free.fr> wrote:
I don't apply as Release Maintainer. Do we have a volunteer around ?
After repeated prompting, I'll go for this. If you make me 2.0.0 RM, I will:-
1. Only allow bugfixes into the main tree and try to avoid DB structure changes;
I agree
2. Aim for every new 2.0 bug squashed within a week of report, time permitting;
I agree.
3. Ask the 2.2 team to port 2.0 bugfixes or note they don't apply (= no 2.0 bug gets closed without it) for at least the first 3 months;
I will look closely to rel_2_0 CVS modifs if I become the 2.2 RM. & it i'm not 2.2 RM, i'll look closely anyway ;-)
4. Make a new release after fixing a blocker or critical bug;
I agree
5. Make a new release at most 6 weeks after fixing a bug, with at least 2 prereleases;
If the 2.0.x is bugfixes only, i don't think new releases needs pre-releases.
6. Introduce an alternative to the z3950daemon;
I think i don't agree here : the 2.0.x series should only be bugfixes & minor improvements. And I'm afraid the z3950 daemon alternative is something too important for this branch.
7. Help to update the koha manuals.
I congratulate you, and wish you a lot of happiness with this. NOTE : i've recieved a mail from someone that asked me "what involves being Release Maintainer". It's a good news : * if we have 2 candidates, it means we will have only 1 RM, but more that 1 M !!! (& i think we should decide who is "elected" RM on a "time-avaible-for-koha" basis. But that's my personal opinion) * If we don't need more than 1M in the far future, we may ask 1M to go to HEAD and help here. So, in any way, it's a good news ;-)
I apply as Release Manager for 2.2.0 if other ppl here like this idea.
Before deciding what I think on that, I would like to hear how and when you plan to reach 2.2.0 - when will 2.1 series releases and freeze happen? (I'd prefer to see 2.2 before late October...) What are the first set of new features to go into main?
I'll write something more complete in a week or 2, but you can already add : * Serials module * up to 5 differents kinds of MARC editor definition (for monography, serial, multimedia, ...) * Borrowers suggestions in OPAC * Rewritted & improved search. With the possibility to order the results by author / title / LC / ... * In OPAC, possibility to see the biblio in default / MARC / ISBD / XML view. * temporary baskets in OPAC : the user can add a biblio in the basket, then ask for them on his mail adress (in one of the previous 4 view) * improve thesaurus management, by having "see also" support (that does not exist yet) * LOT of code & DB cleaning in CVS * CSS-based librarian interface, to : 1-lower html size, 2- have a more versatile look, 3- have more readable code. The roadmap ? mmm... good question... It will depend on the number of volunteers, developpers, funders. I think i'll fix release dates and then see what we put in the release. September seems to be a good date for a 1st 2.2 release. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
Hi Paul, I'm glad that you agree with most of my plans. I'll just explain the one you don't agree with: On 2004-02-20 08:47:22 +0000 paul POULAIN <paul.poulain@free.fr> wrote:
6. Introduce an alternative to the z3950daemon; I think i don't agree here : the 2.0.x series should only be bugfixes & minor improvements. And I'm afraid the z3950 daemon alternative is something too important for this branch.
z39.50 is a "killer feature" for most potential koha adopters who I talk to. As you said yourself, the z3950daemon isn't easy to use at the moment, and we see a lot of questions about it on the list. Indeed, even I've not got a stable installation yet. I see that as a critical bug. I am not planning to remove it and I hope that it can be stabilised by the 2.2 team, but if an alternative 80% solution to this serious bug is possible, I would include it in 2.0. -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/
participants (2)
-
MJ Ray -
paul POULAIN