September 2011 - Koha-devel - lists.koha-community.org

Why is it so cold in here? Oh the features are all frozen
by Chris Cormack 23 Sep '11

23 Sep '11

Hi All That's right, we are in feature freeze leading up to next months release of 3.6.0. No new features submitted will be considered for that release. Anything that is already in the needs-signoff queue is still ok though. But get testing, signing off etc. The next deadline is string freeze, coming up in 2 more weeks, the more you get signed off by then, the better. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand

1 0

bug 6328 signed off, patch stopped (spam ?)
by Zeno Tajoli 23 Sep '11

23 Sep '11

Hi to all, I have signed-off the patch for bug 6328. I have done little changes on files installer/data/mysql/kohastructure.sql and installer/data/mysql/updatedatabase.pl I have send the patch to koha-patches(a)lists.koha-community.org this morning (time of Rome) but I don't see the message yet in mailng-list. I think the message si blocked by anti-spam of the mailing-list Bye Zeno Tajoli -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer

1 0

Call for News for the September Newsletter
by Daniel Grobani 21 Sep '11

21 Sep '11

Hi, I'm gathering news for the September newsletter. Please send me by the 24th anything you think the community might like to know about. "News" can be as short as a sentence or as long as a paper. I especially encourage you to send me a line or two about what you're currently working on for publication in the gossip/society column. And if you know of a go-live not announced on the list, please be sure to let me know about it. Many thanks, Daniel Grobani

1 0

Restructuring C4
by Ian Walls 21 Sep '11

21 Sep '11

Fellow Developers, Last night, I stayed up late running circ/circulation.pl through NYTProf, to get an idea where we may be able to optimize circulation for speed. After much frustration (darn session IDs...), I was able to get a report. The results were... not exactly what I expected. It seems that much of the time spent running circ/circulation.pl is spent BEGINing the various C4 modules, multiple times. C4::Items, for example, is BEGuN 14 times in the execution of circ/circulation.pl. More stats: C4::Accounts - 8 BEGINs C4::Acquisition - 14 BEGINs C4::Auth - 14 BEGINs C4::Biblio - 14 BEGINs C4::Branch - 5 BEGINs C4::Circulation - 22 BEGINs C4::Context - 18 BEGINs C4::Dates - 12 BEGINs ... and so on. Even modules like C4::XSLT, C4::SMS, C4::Suggestions, and C4::Search::PazPar2 are BEGuN several times, without any calls to any of their subroutines. Some modules, it seems, don't have an END at the end... I was also able to get a Graphviz file out, showing all the package calls (folks may remember my keen interest in such things from KohaCon). Running it through sccmap to detect cycles, I found a very long one between several of the modules. About 8 packages long. All this indicate to me that we REALLY need to start thinking about imposing some kind of structure on C4. I'm thinking something with two-levels: Level 1 : Calls to the database, other direct interaction with stored data Level 2: Calls to Level 1 functions to manipulate data all our scripts would then be modified to call only Level 2, which would take care of talking to Level 1. At the worst, a particular Level 1 package would be BEGuN as many times as there were Level 2 packages BEGuN in the script (and we could certainly do better). It would eliminate all the cycles, as well. I can provide access to my report for anyone who needs it, or more details about how I obtained it. Whatever any of you need to keep this conversation going. This is a big deal, in my opinion, and we need to start detangling our code before too much long, or we're going to get seriously bogged down. Cheers, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls(a)bywatersolutions.com Twitter: @sekjal

11 25

unsuscribed
by Suzanne Bellande 21 Sep '11

21 Sep '11

Please unsuscribed me. sincerely, Suzanne Bellande -- Suzanne Bellande, Bibliothécaire Chargée de mission réinformatisation Coordinatrice UBIB pour l'ULR Bibliothèque universitaire Université de La Rochelle 2 parvis Fernand Braudel 17042 La Rochelle cedex 1 Tél. 05 46 45 68 92 Fax 05.46.50.59.92 http://www.univ-larochelle.fr/-Bibliotheque-.html

2 1

incomplete list in install_misc/debian.packages
by Zeno Tajoli 21 Sep '11

21 Sep '11

Hi to all, I see that the file install_misc/debian.packages is quite incomplete. I think it is a bug, many modules that are avaible with apt in debian squeeze are not listed. So I send a bug about it. But I have same question: 1)In the list do I insert also packages that are dependeces of others ? For example libbusiness-isbn-perl wants to install also libbusiness-isbn-data-perl. Do I list only libbusiness-isbn-perl ? 2)I don't list modules about Memcached. Is it OK ? 3)The module Gravatar::URL in debian squeeze package is at version 1.02. The veesion request in C4::Installer::PerlDependencies.pm is version 1.03, so I don't list it. Is it OK ? Bye Zeno Tajoli -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer

2 3

Re: [Koha-devel] tt style point
by Mason James 20 Sep '11

20 Sep '11

On 2011-09-19, at 8:09 PM, LAURENT Henri-Damien wrote: > Le 19/09/2011 04:06, Mason James a écrit : >> i too, sure would love to get an agreement on a consistent, mechanised formatting style for perl code in Koha >> fyi: Koha's current .perltidyrc was never agreed upon, it was simply submitted and accepted > As far as I know, it has never been enforced though. yes, its never been agreed upon or enforced - it was just a thoughtful suggestion from Andrew > And enforcing that globally would make it a pain in the neck for all > developpers and maintainers rebasing their features. i'm not suggesting existing code will be rejected if its not formatted to the new perltidy style, thats too painful!! i simply suggest we start the process by agreeing on a standard, and go from there... > Unless it is > planned, announced widely, and done when every ppl agree, I think that > perltidyrc would be just an idle file. the current perltidyrc file *is* just an idle file, because it was never agreed upon... lets agree on a formatting style, and make the spec official. then it wont be just an idle file :) > I once did that on our repository. It made it much harder to port > features and code back into the trunk. So I would love that. again... i'm not suggesting that we force people to perltidy their old code > Maybe it could be discussed and done just before splitting branches for > stable branch. Therefore, the maintainer and the new master would have > the same "coding standard" > It could also THEN be invoked as a git hook on edited files so that they > would not loose their tidyness. yep, those are both great ideas :) i'm strongly against having old code 'perltidy-fied' in huge commits, because i know the problems that causes with tools like 'git-blame', etc so i suggest we slowly and gently correct small blocks of existing code - as we work on it and the formatting in new Koha releases will start to become more consistent i personally don't mind *what* that standard is... i just want an agreed upon standard but hey... --PBP get my vote by a mile! cheers, Mason

1 0

Feature Freeze September 22nd
by Chris Cormack 19 Sep '11

19 Sep '11

Hi All As previously mentioned a few times, the 22nd of September is one month out from the 3.6.0 release. Which makes it the feature freeze date also. No new features submitted after this will be in consideration for 3.6.0. It is strongly recommended that you submit patches as soon as possible and find people to sign those patches off for you. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand

1 0

Re: [Koha-devel] tt style point
by Paul 16 Sep '11

16 Sep '11

At 08:33 AM 9/16/2011 -0400, Ian Walls wrote: >Colin, > > >I made the decision to require parentheses around the variables for the >sake of consistency.Â All the other template in Koha do it that way, >right or not.Â I'm certainly open to it dropping the parentheses; they >don't seem to follow standard practice, and while I'm sure no >complications are introduced by them, it does add extra keystrokes and one >more "little Koha nuance" to any patch submitted. > >We have not revisited the Coding Style Guidelines for Koha since switching >to Template Toolkit, and I think this should certainly be one of the >issues we address when we do.Â Until then, I recommend we maintain a >consistent style in this, even if we're eventually going to drop it. > >What does the rest of the community think?Â Is it worth being picky about >such a thing until we can decide for sure one way or the other?Â Or, more >pragmatically, should such a thing impede QA? My two cents -- as I had noticed this, but hadn't bothered to look into it as "if it ain't broke, don't fix it". However, I do have a question: is there any case where a () *must* be used within a [% IF .* %] construct? If not, then surely a one time grep -E, or perl -i could revert matters to documented standards? If something is not in the Koha Coding Style Guidelines wiki, then surely we should be able to rely on the standards set by the original coders? Ian, I really do not mean to say you're wrong, just that I think that Colin is on a good track. After nearly a year dealing with Koha, learning a lot, having some fun, and supplying a working system to our staff, volunteers and members/visitors, the one "negative" factor about Koha that stands out to me (personal opinion only) is the untidiness rather than complexity of the coding, all leading to a general sluggishness of the system and an increase in setup, update, modification and maintenance time. As to your last question, QA is an absolute to ensure proper functionality (security, etc) and intrinsically should not worry about *style*; however, when QA is a team responsibility I have always found that lack of clarity, including normalized practices, is counterproductive. Best - Paul tired old sys-admin >Cheers, > > >-Ian > >On Fri, Sep 16, 2011 at 8:13 AM, Colin Campbell ><colin.campbell(a)ptfs-europe.com> wrote: >Hi >Â I noticed that in QA someone is changing tt constructs from >[% IF variable %] >to >[% IF (variable) %] >as style issues > >I think this is very bad style for the following reasons: >You'll not see it in any of the documentation for tt either the perldoc, >on the tt site or in the badger book. (and I've never seen it on any tt >using project). >It adds nothing (we hope) syntactically. >My initial response is that as we are not using normal tt syntax, >something "clever" or magic is going on here rather than a usual [% IF %] >It detracts from readability. (ok slightly subjective but the >environment already makes full use of the top row of the keyboard.) >Whats its relation with the legitimate use of brackets e.g. to call >vmethods in regexps [% IF variable1( variable2 ) %] >The authors didn't require brackets around more complex boolean >expressions [% IF variable == 0 %] why bring em back in for simple >variables. >Could it have unforeseen side effects (don't know but I don't want to >spend time researching it) >It confuses the reader of the code and the writer of subsequent code - >'should I use () no? when? why? >It strikes me as weird (!!) > >In short I'm arguing for clarity... > >I realise that Chris bracketed things in the great template conversion >but I think that was defensive programming when he couldn't rely on >variable always being one. And we shouldn't be encouraging or enforcing >others to use a peculiar idiolect rather than standard practice. > >Colin > > >-- >Colin Campbell >Chief Software Engineer, >PTFS Europe Limited >Content Management and Library Solutions >+44 (0) 845 557 5634Â (phone) >+44 (0) 7759 633626 Â (mobile) >colin.campbell(a)ptfs-europe.com >skype: colin_campbell2 > >http://www.ptfs-europe.com >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)lists.koha-community.org >http://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/ > > > > >-- >Ian Walls >Lead Development Specialist >ByWater Solutions >Phone # (888) 900-8944 >http://bywatersolutions.com >ian.walls(a)bywatersolutions.com >Twitter: @sekjal >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)lists.koha-community.org >http://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/

1 0

3.4.x String Freeze
by Chris Nighswonger 16 Sep '11

16 Sep '11

Ok everybody... 3.4.x is presently in a string freeze. The only string affecting patches that will be accepted at this point are blocker and security related bugs. Other patches will be pushed up to the release date. Kind Regards, Chris

1 1