On Wed, Jul 23, 2008 at 5:22 AM, Paul POULAIN <[EMAIL PROTECTED]> wrote: > 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. Yes, I agree, it does add some functionality, but it also solves a UI 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.
> 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 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 [EMAIL PROTECTED] |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
