3.0 stable & improvements (for comments)

[Paul POULAIN-2]

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.

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 : [phone]
_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha.org/mailman/listinfo/koha-devel

[Paul POULAIN-2]

Just let me give you an example of a request I had : "when you're on the
member details page, you can't see it's reading history"

The solution would be fairly easy to code :
- add a link on the left tabs buttons "reading history"
- write a page like opac-readingrecord.pl. Oups, the script already
exist (members/readingrec.pl), we just lack the link.

so :
Q1 : the lack of link is a bug, isn't it ?
Q2 : if the script were not written, what about adding it after a 3.0
release ? would it be "yes" or "no" according to you.

I agree it's a minor thing, but it's a good example imho.
--
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
NOUVEAU TELEPHONE : [phone]
_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha.org/mailman/listinfo/koha-devel

[Joshua Ferraro-3]

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

[Joshua Ferraro-3]

On Wed, Jul 23, 2008 at 5:55 AM, Paul POULAIN <paul.poulain@...> wrote:

> Just let me give you an example of a request I had : "when you're on the
> member details page, you can't see it's reading history"
>
> The solution would be fairly easy to code :
> - add a link on the left tabs buttons "reading history"
> - write a page like opac-readingrecord.pl. Oups, the script already
> exist (members/readingrec.pl), we just lack the link.
>
> so :
> Q1 : the lack of link is a bug, isn't it ?
> Q2 : if the script were not written, what about adding it after a 3.0
> release ? would it be "yes" or "no" according to you.

Probably NO in this case, it should be moved to 3.2, and presumably, 3.2
would be within arm's reach, two to three months max.

Cheers,

--
Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE
CEO migration, training, maintenance, support
LibLime Featuring Koha Open-Source ILS
jmf@... |Full Demos at http://liblime.com/koha |1(888)KohaILS
_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha.org/mailman/listinfo/koha-devel

[Paul POULAIN-2]

Joshua Ferraro a écrit :
> and presumably, 3.2
> would be within arm's reach, two to three months max.

??? You really think we will be able to release 3.2 in 2 or 3 months ? I
can't believe that timeline will be respected.
- there is still no git 3.2 branch
- the RFC are not declared complete & commented
- the translation process is quite long
- the migration process must be heavily tested.
- how many time did we need to bugfix 3.0 ? I agree there was a lot of
changes btw 2.2 and 3.0, but i'm 100% sure that 3.2 bugfixing will
require some months (including checking/validating various parameters,
as we have zillions)

so I can't believe 2 or 3 months...
or I misunderstand "be withing arm's reach"

--
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
NOUVEAU TELEPHONE : [phone]
_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha.org/mailman/listinfo/koha-devel

[Joshua Ferraro-3]

On Wed, Jul 23, 2008 at 8:18 AM, Paul POULAIN <paul.poulain@...> wrote:

> Joshua Ferraro a écrit :
>> and presumably, 3.2
>> would be within arm's reach, two to three months max.
>
> ??? You really think we will be able to release 3.2 in 2 or 3 months ? I
> can't believe that timeline will be respected.
> - there is still no git 3.2 branch
> - the RFC are not declared complete & commented
> - the translation process is quite long
> - the migration process must be heavily tested.
> - how many time did we need to bugfix 3.0 ? I agree there was a lot of
> changes btw 2.2 and 3.0, but i'm 100% sure that 3.2 bugfixing will
> require some months (including checking/validating various parameters,
> as we have zillions)
>
> so I can't believe 2 or 3 months...
> or I misunderstand "be withing arm's reach"

I was speaking in the hypothetical time when a feature like the one you
mentioned might be added (new link), and assuming we had already
made significant progress on the next release (in arm's reach). It's up to
the 3.2 RM as well as the efforts of the developers to say just how long
it will take before we can release 3.2 :-).

Cheers,

--
Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE
CEO migration, training, maintenance, support
LibLime Featuring Koha Open-Source ILS
jmf@... |Full Demos at http://liblime.com/koha |1(888)KohaILS
_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha.org/mailman/listinfo/koha-devel

[Paul POULAIN-2]

Joshua Ferraro a écrit :
>> Q2 : if the script were not written, what about adding it after a 3.0
>> release ? would it be "yes" or "no" according to you.
> Probably NO in this case, it should be moved to 3.2, and presumably, 3.2
> would be within arm's reach, two to three months max.

(from the patches reaching my mailbox during the night)

And what about : ENHANCEMENT: SearchMember() uses "cardnumber%" wildcard
- if other search-types fail ?

following my path :
- DB changes => none
- API change => none
- user experience change => none
+ the patch is small & add a small feature => no side effect possible
(the '%' at the end has no consequences on indexed search, so on speed
search, I don't see any other problem to double-check) I would have
added it in 3.0.1


What about : [PATCH] bug 2386: adding newline between items in overdue
notices ? (randomly choosen)

following my path : same conclusion, patch accepted.

I couldn't find a patch that I wouldn't apply in a 3.0 stable (maybe :
[PATCH] bug 1953 [2/2]: whitespace and documentation changes), as it's
useless, but it's also harmless, so I think I had accepted it anyway, to
avoid some rebase problem later.

imo, accepting such patches would result in lot of small improvements in
Koha, without any stability reducing, and without having to wait for 3.1
release. With the idea of releasing a new version once every quarter or
every 2 months.
--
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
NOUVEAU TELEPHONE : [phone]
_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha.org/mailman/listinfo/koha-devel

[MJ Ray-2]

Paul POULAIN <paul.poulain@...> 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. patches@koha
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:[phone]
_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha.org/mailman/listinfo/koha-devel