Hi folks, Look at commit : http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commit;h=64ba3ffe8309da1e109... 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@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel