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

[Joshua Ferraro]

On Wed, Jul 23, 2008 at 5:22 AM, Paul POULAIN <paul.poulain at free.fr> 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
jmf at liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha.org
http://lists.koha.org/mailman/listinfo/koha-devel