[Koha-devel] "freezing" koha 3.0

[Paul POULAIN]

Hello,

I begin to be really troubled by all those new features added in the 
main trunk...

I think we really should stop hacking koha that much & work only on 
stabilizing things. And by stabilizing I mean "stop adding anything new, 
strictly, really strictly, just fix things that have to be fixed"


just some examples of the side effects/problems with this activity :
1- the french translation was 100% done. I just updated the .po file : 
192 fuzzy (chain changes) and 45 untranslated strings. And I keep the 
translation update really often. I'm afraid other translators will have 
a very bad surprise, seeing 20 or 25% of the stuff they already did has 
to be redone, because each change in the template will result in

2- I see some new features like patron images, tagging, serialsadditem 
at subscription level[1], move to yui 2.5.1 (from 2.31.), new sysprefs 
by dozens, important changes in the DB structure (the great new 
permission/sub permission, the old_issues table). Important code 
refactoring/cleaning. All those great. Undoubtfully. But the risk to 
introduce some unexpected bugs where things were working previously is 
really BIG. Just 2 examples : one patch of me troubled kados, because he 
broke something in another page : the problem was directly introduced by 
a change in API (C4::Dates.pm). I was not wrong with my patch, I just 
discovered a larger problem (that atz has fixed iirc). the patch to add 
a new way to introduce issuing rules resulted in the unexpected bug #2000.
                           [1] yes, I know, this patch is mine. but with 
the release being so delayed, I was tired to delay this patch & have 
decided to send it.

3- I see some gui changes, done by owen, that are great. but such 
changes can be done forever, things will never be perfect (and one will 
find something awful when someone else will say it's great :-\ ).

4- Joshua, you've announced the alpha for jan, 4. beta for feb, 1st and 
stable for march, 1st. We are almost may 1st, and still no stable 
version released. I would be interested to know how many commits were 
related to true "bugfixes" and how many were related to 
"improvement/cleaning/new features". I would say it's 30% / 70% (numbers 
not calculated scientifically ;-) )

In french we says "better is sometimes enemy of good". I think we are 
facing this situation : "better" is now our biggest enemy.

So, I request/propose the following decision to be taken :
- we didn't have had an irc meeting for a long time, it's time to plan one.
- no changes in the code, except true bugfixes. "imperfection" fixes 
will be for later.
- no more changes in templates except true spelling problems (or true 
bugfixes, of course), to let time to i18n teams to do their job.
- create a branch, as soon as possible,  to have ppl doing improvements 
on the dev branch, and bugfixes on the 3.0 branch. That's how we did for 
2.0 and 2.2. I released a version once every 3 month or something like 
that. I agree we didn't had a company like LibLime doing 125/130 commits 
every month. 
(http://git.koha.org/gitstat/chart.php?chart_parameter1=3&chart_parameter_ver=R_2-2-9&submit=1&chart_parameter2_year=2008&chart_parameter2_month=4&submit=1&showcount=10), 
but 3.0 will never be ready if we continue like that. And with git, it 
should be "easy" for ppl wanting to have an hacked version of 3.0, with 
a backported improvement from the dev branch to be done. I'm sure, 
because I have some patches for some of our customers, that we haven't 
commited to the main repo (some of them will never be, some of them will 
be for 3.2, probably)

Joshua, you probably have a different opinion than mine, as RM. But as 
previous RM, I had to write my thoughts. I hope you'll understand my 
opinion and agree on most of it.

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : 04 91 31 45 19