Paul POULAIN <[EMAIL PROTECTED]> wrote: > 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. [...] > once 3.0 is released, how will we deal with those cases ?
We should split the patch. The bugfix goes into 3.0, the rest into 3.1. Every change during a stable release has two risks: first, that a change gets omitted from 3.1; second, that it introduces an unforseen bug. That risk only seems worth it if it's fixing some other bug. [...] > 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. I don't think software.coop can work without local trees. [EMAIL PROTECTED] just isn't processed quickly enough to react to customer requests. The process on one recent patch (BUGFIX opac-serial-issues.pl template) has been: email, wait, check the HEAD, check the list archive, wait, ask kados on IRC if he ever got the patch, ask if he wants resubmission, no answer... I need to check whether it's in yet, but our clients would be screaming if we didn't have our local trees. Regards, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
