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. Yes, I agree, it does add some functionality, but it also solves a UI
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) My strong preference is the latter: unless something resolves a security issue, a bug, or a major usability issue, I'd prefer it just be included in 3.2, and leave 3.0 alone (that's my opinion if I were to be 3.0 maintainer). So something like
On Wed, Jul 23, 2008 at 5:22 AM, Paul POULAIN <paul.poulain@free.fr> wrote: problem with the data, where the value rather than the description for an authorized value was displaying; this may be fine for things like location codes where everyone knows what each library's code is, but in some cases like categorycodes, it's more useful to have the description. this example, the customer would have to wait for 3.2, or I would manage that customer as branch until 3.2 were ready if they really needed to have the feature immediately. Since we don't have a 3.2 branch yet, I didn't want to leave this patch 'stranded' and it really didn't do any harm to 3.0 itself, so I approved it.
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. Yes, we try to avoid this as much as possible for the obvious reason that it lessens the incentive for us to work on the public releases.
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. I like this approach, I think it would work for future releases as well; others have comments, thoughts?
Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel