[Koha-devel] 3.0 stable & improvements (for comments)

[Paul POULAIN]

Hi folks,

Look at commit : 
http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commit;h=64ba3ffe8309da1e109bbbae49b6c567b6f9d49f

The commit notes write :
> Refine "Patrons statistics" report, fix highlight, remove CGI::scrolling_lists.
> 
> At client request, I added code for a rowtitle_display and coltitle_display.  This
> allows the script to substitute human-readable lables into the table instead of just
> the literal hashkeys.  For this client with dozens of numerical patron categorycodes
> having a row titled "29" was not very useful.

I wanted to point the "at client request I added code..."

1st thought : it's an improvement, so it should not be here, as we are 
supposed to have only bugfixes
2nd thought : it's really minor, harmless & usefull, so it's good to 
have it anyway.

So...
once 3.0 is released, how will we deal with those cases ? Will our 
Release Maintainer (Joshua) decide which patches to cherry pick from 
head to have minor improvements ? Do we accept some improvements (I 
think we will have to do that : when a client request something, it's a 
problem to say "ok, it's minor, it's done, but it will be only available 
in 3.2, that will be released in X months" + if it's a sponsored 
feature, we (BibLibre or LibLime or anyone else probably won't be paid 
until the feature is available for the client)

Another solution would be to have an official trunk & local versions for 
local clients. if I don't mind, LL don't want to do this, and BibLibre 
either.

ideas / thought / welcomed...

experience feedback :
when I was RM for 2.x, I used to add minor features. What guided me :
- is the improvement changing something in the DB ? if yes and very 
minor (like the add of a timestamp in virtualshelves table for example 
;-) ), then continue investigating. If yes and not minor (adding 
contraints, foreign keys, indexes, "core fields", some tables...) , 
don't do it now.
- if the improvement is changing nothing in the DB (or yes & very 
minor), does it change something in the API ? If yes => delay the 
improvement. I prefered to add some silly code to circumvent an API 
limit than change the API. That's the price for stability I think. If no 
API change => continue investigating.
- will the improvement change the user experience (I don't mean improve 
something, but change the way Koha works). if Yes => delay the 
improvement. If no => continue investigating.
- is the improvement correctly coded & do I feel it's OK ? Yes => OK, 
add it.

To summarize, there can be 3 filters : DB change, API change, user 
experience change.

Maybe not perfect + the # of devs was from far not as much as what we 
have now, but, at least, that was the way I tried to handle that problem.
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
NOUVEAU TELEPHONE : 04 91 81 35 08
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha.org
http://lists.koha.org/mailman/listinfo/koha-devel