March 2016 - Koha-devel - lists.koha-community.org

Proposal - Deal with modules versioning ($VERSION)
by Jonathan Druart 09 Mar '16

09 Mar '16

Hi devs, During the last dev meeting [1] we talked about how we should manage the $VERSION var of our Koha modules. (a)The first idea was to remove it: it is stuck to an old version and it does not make sense to keep it as it. Another idea would be to keep it and use it (i.e. update it). This idea has already been discussed on bug 7941 [2], but never been set up. In this second approach, there are different ways to do, either we update all of our modules to the Koha::version or update them individually, when they change. Based on 2 blog entries [3, 4] and the Perl Best Practices (Chap 17: Modules, Version Numbers), the way to do would be to use a three-part version numbers ('1.0.3') using the version module (`use version; our $VERSION = qv('1.0.3');`). But there are no specific guidelines to manage the different modules inside a project. I have checked several perl projects and they don't assign a version to each modules (Dancer, DBIx::Class, Mail-SpamAssassin). (b)Set the same $VERSION variable to all our modules does not seem very useful (unless making `perlcritic -2` happy). (c)On the contrary it would make sense to version them individually, following the Koha::version: when a module is modified, the minor version is increased. That would be easy to do for stable releases: the version is updated when releasing. But for master we could have a module version > Koha::version (indeed the Koha::version is only updated when a DB entry is added). To avoid that we could decide not to update the version during the development process (master). (d)Another way to do would be to initially set the version to 1.0.0 (or 3.0.0 or whatever) to all the modules and increase the version when they are modified, but the version numbers would not make sense and won't be helpful: some unchanged modules will have 1.0.1 and others 1.2.34. I think (c) makes sense: for instance if C4::Budgets is not modified between 3.22.x and 3.24.x, its version will stick to 3.22.x. Looking at this version we would know if this module has been updated recently or not. Concretely, we would set all of our modules to 3.24.00.000 (not that does not respect the 3-digit and 3-part version numbers "conventions") when releasing 3.24 (scripts will provided to automate everything), 3.25 will come and won't update the module versions until 3.26. 3.24 RMaint will update the versions of the modified modules when releasing 3.24.01.000 3.26 RM will update the versions of the modified modules when releasing 3.26.00.000 Note that we could "back-versioning" the modules of all our stable branches (3.18, 3.20 and 3.22). What are your thoughts? Are you more a, b, c, d or ... e? Cheers, Jonathan [1] http://meetings.koha-community.org/2016/development_irc_meeting_1_march_201… at 15:40:52 [2] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7941#c2 [3] http://www.modernperlbooks.com/mt/2009/07/version-confusion.html [4] http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/

5 8

General IRC meeting 9 March 2016 at 20:00 UTC
by Brendan Gallagher 08 Mar '16

08 Mar '16

Hello - Just a reminder that there is a General IRC Meeting tomorrow. Here is the link to the agenda. https://wiki.koha-community.org/wiki/General_IRC_meeting_9_March_2016 You'll also find a time converter in the wiki link so you can adjust to your local time. Thanks, Brendan -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO

1 0

More qa test tool patches
by Mark Tompsett 08 Mar '16

08 Mar '16

Greetings, Seems like bug 15870 has motivated me to work on patches for Koha’s QA test tool. I just wrote a nicer counter/complimentary patch for 16003 (either or both, I don’t care), and now that “fatal” warning will clear up nicely with bug 16008. GPML, Mark Tompsett

1 0

Fwd: Packing needs - status to add to bugzilla and the dashboard?
by Brendan Gallagher 08 Mar '16

08 Mar '16

Thanks Liz. ---------- Forwarded message ---------- From: Liz Rea <liz(a)catalyst.net.nz> Date: Tue, Mar 8, 2016 at 12:37 PM Subject: Re: [Koha-devel] Packing needs - status to add to bugzilla and the dashboard? To: Brendan Gallagher <info(a)bywatersolutions.com> Robin wrote a couple of quite good wiki pages on this subject: https://wiki.koha-community.org/wiki/Building_Debian_Dependencies https://wiki.koha-community.org/wiki/Building_Debian_Dependencies/Dependenc… On 09/03/16 06:50, Brendan Gallagher wrote: Yup all good points. Not to put it all on the PM - but I think a way to track this in BZ is needed. A better workflow - perhaps based on Chris's point - a "failed QA - needs package" status (or some worded status)? Do we have a defined role description of responsibility of the Packaging Manager? (I've only read Robin's posts to the mailing list before - is that it?) On Tue, Mar 8, 2016 at 9:37 AM, Galen Charlton <gmc(a)esilibrary.com> <gmc(a)esilibrary.com> wrote: Hi, On Tue, Mar 8, 2016 at 12:30 PM, Chris Cormack <chrisc(a)catalyst.net.nz> <chrisc(a)catalyst.net.nz> wrote: I don't think it's fair to push this all on the package manager. If a dev introduces new dependencies that need packaging, it should be their responsibility to make sure this is done. Indeed. I am willing to build *some* packages (and submit them to Debian), but that willingness is decidedly not infinite. The first question that somebody who proposes to add a new dependency should ask themselves is this: is there a way to accomplish the task at hand without adding a new dependency? If not, can the task at hand be accomplished using packages that are already in Debian stable? If not, does the dependency at least have an active third-party ITP (intent to package) in the Debian bug tracker? Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / Open Your Library email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org &http://evergreen-ils.org _______________________________________________ Koha-devel mailing listKoha-devel@lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- -- Liz Rea Catalyst.Net Limited Level 6, Catalyst House, 150 Willis Street, Wellington. P.O Box 11053, Manners Street, Wellington 6142 GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7 -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Santa Barbara, CA - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info(a)bywatersolutions.com

2 1

ARG! It really is isnt. It is not a typo.
by Mark Tompsett 08 Mar '16

08 Mar '16

Greetings, $ koha-qa.pl –v 2 –c 4 ... FAIL t/db_dependent/Filter_MARC_ViewPolicy.t OK critic OK forbidden patterns OK pod FAIL spelling isnt ==> isn't OK valid ... $ grep isnt t/db_dependent/Filter_MARC_ViewPolicy.t isnt( $unfiltered_record->field('020'), undef, isnt( $unfiltered_record->field('008'), undef, isnt( $filtered_record->field('020'), undef, isnt( $unfiltered_record->field('020'), undef, isnt( $filtered_record->field('008'), undef, isnt( $unfiltered_record->field('008'), undef, Spelling checks should exclude “isnt(“, right? GPML, Mark Tompsett

3 3

Accidental ban from bugzilla
by Remi MP 08 Mar '16

08 Mar '16

Hi, Here at inLibro we are developping a perl script that will allow us to automatically test bugs for conflicts when their statuses are "New", "Needs Signoff","Signed Off" and also "In Discussion". The script will change the bugs' statuses to "patch doesn't apply" and notify the people involved. My issue right now is that when I started testing my put requests on a bug I created on my own, my account got banned until 15:30 this afternoon because of too many login attempts : Your IP (127.0.0.1) has been locked out of this account until 2016-03-04 15:28 UTC, as you have exceeded the maximum number of login attempts. Is there a way I could get unbanned? I will install bugzilla locally to continue testing, but still I need to be able to access bugzilla today. Thank you!

9 11

Working on Koha interface guidelines
by Owen Leonard 08 Mar '16

08 Mar '16

A while ago I started a page on the wiki for describing common interface patterns in Koha. I've made some additions to it over the last couple of weeks, and I hope to continue to expand it. https://wiki.koha-community.org/wiki/Interface_patterns As you can see it has been long enough since I started that the first screenshots look out of date. Updating them is on my to-do list. However I think the guidelines are still accurate. To a certain extent, this document is both a catalog of how we generally do things in the staff client template and an explanation of my understanding of /why/ we do some things the way we do. If anyone has any questions or suggestions I would love to hear them. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

2 2

New "renew" shortcut conflicts with previous use of the accesskey attribute
by Owen Leonard 06 Mar '16

06 Mar '16

The staff client uses (albeit inconsistently) the "accesskey" attribute in some dialogs where a Yes/No choice is offered: Yes, delete (Y) / No, don't delete (N) I've just seen that the addition of the renew tab in the header search form assigned "Alt-y" to the renew form. These two shortcuts can't coexist. I personally use the accesskey option when it is available (and when it works), but I imagine not many people do. Is it not worth keeping? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

2 1

Wiki - Delete/disable user Xdbmsx
by David Nind 04 Mar '16

04 Mar '16

Hi. I accidentally approved a new wiki user last night (I thought I had rejected it, but must have approved it :-( ). Could someone who has permission disable/block the user Xdbmsx as I don't have permissions to do this. The user has also created several pages that need to be deleted. Apologies for this.... David Nind | david.nind(a)gmail.com PO Box 12367, Thorndon, Wellington, New Zealand 6144 m. +64 21 0537 847 | w. +64 4 8906 098

3 3

Patron searching change 'start_wtih' / 'contain' Bug 15252 / 15930
by Nick Clemens 04 Mar '16

04 Mar '16

Hello all, In bug 15252 a change was introduced to fix the problem of too many / irrelevant results when searching for patrons with multi-part names e.g. 'jean paul' 'mac beth' 'le guelec' This change now defaults many searches to 'start_with' and does not split terms for a 'start_with' search. This does not affect members-home.pl, but many other patrons searches request.pl, common/patron_search.tt ... A side effect of this change is that searching for a patrons full name i.e. 'Henry Acevedo' or 'Edna Acosta' returns no results as it is searching for [firstname like 'edna acosta%'] it also prevents searches like 'Ed aco' from finding results. The searches above returned results through 3.18, but 15252 is in 3.20.8 and 3.22.2 and master As we are seeing libraries upgrade to the newer versions we are hearing complaints as this is a big behaviour change from their viewpoint. Jonathan and I have been discussing on Bug 15930 and the options we have so far are: 1/ add a special case to search on firstname and surname (if start_with) 2/ add a pref to default on contains or start_with 3/ let the libraries who want a different behavior modify the default with some JS code 4/ add phrase searching with quotes and split terms otherwise Ideally we want to allow for ease in finding multi part names, but not introduce a change for single part names Thoughts?

2 1