From magnus at enger.priv.no  Thu Sep  1 12:25:35 2011
From: magnus at enger.priv.no (Magnus Enger)
Date: Thu, 1 Sep 2011 12:25:35 +0200
Subject: [Koha-devel] 2011-09-02 Global bug squashing day #4 - It's on! Join
	the fun!
Message-ID: <CABg6UYEpSyxu0MteVso0-K-Tk_q6+EmJ1+KU=vZcsWowTzDHuw@mail.gmail.com>

Dear Community!

Just a gentle reminder that GBSD#4 started about half an hour ago, in
Kiribati. If Friday September 2nd is inconvenient for you in your
timezone you might want to consider diving in now, to get a head
start! ;-)

For those watching at home, a lot of the changes on Bugzilla will be
tweeted here:
http://twitter.com/#!/KohaGBSD

Best regards,
Magnus Enger


---------- Forwarded message ----------
From: Magnus Enger <magnus at enger.priv.no>
Date: 30 August 2011 08:35
Subject: 2011-09-02 Global bug squashing day #4
To: Koha list <koha at lists.katipo.co.nz>, koha-devel at lists.koha-community.org


Dear Community!

Just a gentle reminder that GBSD#4 is approaching fast:
http://wiki.koha-community.org/wiki/2011-09-02_Global_bug_squashing_day

Please bear in mind that the Release Manager has declared the following dates:
* Feature freeze ? 22 September 23:59 UTC ? From this point on, no new
features will be considered for inclusion into 3.6.0
* String freeze ? 8 October 23:59 UTC ? no bugs that change templates
accepted after this point. This allows the translators to translate
without things changing on them
http://koha-community.org/key-dates-3-6-0/

That means we have about 3 weeks for getting any new features in! And
there are (at the moment) 83 (!) bugs/patches waiting to be signed
off:
http://bugs.koha-community.org/bugzilla3/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=cf_patch_status&query_format=advanced&type0-0-0=equals&value0-0-0=needs%20signoff&order=bug_id&list_id=10641

See one in there that you would like to make sure makes it into Koha
3.6? YOU can help it along by signing off on it!
http://wiki.koha-community.org/wiki/Sign_off_on_patches

Of course, we should take every opportunity to sign off patches in the
coming weeks, but why not make a concerted effort on Friday September
2nd 2011 (in your timezone) and see how far we can get, as a team?
Could we cut the queue in half?

Happy hunting!
Magnus Enger

PS
And you don't have to be a developer to help either!

From barry at oslo.ie  Thu Sep  1 13:58:31 2011
From: barry at oslo.ie (Barry Cannon)
Date: Thu, 1 Sep 2011 12:58:31 +0100
Subject: [Koha-devel] RFC - Admin Dashboard
Message-ID: <CAOmVZJ-T9yabrDTbf2vqq=P4mfaLf3t9Lz4YShfEnTTLvjiqzQ@mail.gmail.com>

Hello,
          I have added an RFC and bug (6828) for the addition of a new
feature in 3.6. The enhancement will provide an admin/staff user the ability
to view a library Dashboard once logged in. The dashboard will display
various library/branch specific information.


Comment and suggestions much appreciated.

Regards
Barry at oslo.ie
http://www.oslo.ie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110901/4dcee673/attachment.htm>

From paul.poulain at biblibre.com  Thu Sep  1 14:11:01 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 01 Sep 2011 14:11:01 +0200
Subject: [Koha-devel] RFC - Admin Dashboard
In-Reply-To: <CAOmVZJ-T9yabrDTbf2vqq=P4mfaLf3t9Lz4YShfEnTTLvjiqzQ@mail.gmail.com>
References: <CAOmVZJ-T9yabrDTbf2vqq=P4mfaLf3t9Lz4YShfEnTTLvjiqzQ@mail.gmail.com>
Message-ID: <4E5F7655.7010403@biblibre.com>

Le 01/09/2011 13:58, Barry Cannon a ?crit :
> Hello,
>           I have added an RFC and bug (6828) for the addition of a new
> feature in 3.6. The enhancement will provide an admin/staff user the
> ability to view a library Dashboard once logged in. The dashboard will
> display various library/branch specific information.
>
>
> Comment and suggestions much appreciated.

barry++ for warning here ! i'll add comment on bugzilla.

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08


From paul.poulain at biblibre.com  Thu Sep  1 17:55:28 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 01 Sep 2011 17:55:28 +0200
Subject: [Koha-devel] Roles for Koha 3.8
Message-ID: <4E5FAAF0.5020208@biblibre.com>

Hello,

A reminder:
Everyone that plan to volunteer for a position in next Koha 3.8 version
is welcomed to file his/her name on the wiki page:
http://wiki.koha-community.org/wiki/Roles_for_3.8
The following positions are (desperately) empty:

    * Translation Manager
    * Documentation Manager
    * Documentation of DB
    * QA Manager
    * Specific Module maintainers
    * Release Maintainer
    * Packaging Manager

2nd reminder: on july IRC meeting, we decided:

   1. /AGREED/: Express interest via the mailing list for Nominations by
      22 September. Elections in October

(see
http://librarypolice.com/koha-meetings/2011/koha.2011-08-02-02.00.html )

so, you still have 21 days left...

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08


From paul.poulain at biblibre.com  Fri Sep  2 10:15:32 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 02 Sep 2011 10:15:32 +0200
Subject: [Koha-devel] Idea for patch header (1st line)
Message-ID: <4E6090A4.4050905@biblibre.com>

Hello all,

I'm following through RSS what is pushed, and I would be interested in
having a specific marker for patches that are related to Enhancements.
Something like
Bug XXXX blabla => it's a bugfix
Enh XXXX blabla => it's an enhancement

I try to track pushed enhancements, I think doc writters & translators
would be highly interested by this difference as well.

Your opinion ?

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08


From chris at bigballofwax.co.nz  Fri Sep  2 10:24:17 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Fri, 2 Sep 2011 20:24:17 +1200
Subject: [Koha-devel] Idea for patch header (1st line)
In-Reply-To: <4E6090A4.4050905@biblibre.com>
References: <4E6090A4.4050905@biblibre.com>
Message-ID: <CA+95qVRipWfK_3=5ukTG+p7vGsenHEC4TP0zPKXfPuDtaNjkmw@mail.gmail.com>

On 2 September 2011 20:15, Paul Poulain <paul.poulain at biblibre.com> wrote:
> Hello all,
>
> I'm following through RSS what is pushed, and I would be interested in
> having a specific marker for patches that are related to Enhancements.
> Something like
> Bug XXXX blabla => it's a bugfix
> Enh XXXX blabla => it's an enhancement
>
> I try to track pushed enhancements, I think doc writters & translators
> would be highly interested by this difference as well.
>
In the meantime you can track the enhancements and bugs here

http://koha-releasemanagement.branchable.com/posts/Work_for_3.6.x/

Or in git
enhancements are always pushed under an enh/ branch like
new/enh/bug_6692

Chris

From fridolyn.somers at gmail.com  Fri Sep  2 10:49:57 2011
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Fri, 2 Sep 2011 10:49:57 +0200
Subject: [Koha-devel] koha 4.0 / solR / Zebra : A working group is born ?
In-Reply-To: <4E5E5221.1040606@biblibre.com>
References: <4E5E3F88.1070508@biblibre.com>
	<809BE39CD64BFD4EB9036172EBCCFA3132701C@S-MAIL-1B.rijksmuseum.intra>
	<4E5E5221.1040606@biblibre.com>
Message-ID: <CAN6cLAXOgT8c_xxKJzVBbLxR3jyWyV4eK1RTJoLnnkTTPB5yLA@mail.gmail.com>

Hie,

I have looked at Solr/Lucene tutorial and code.
In my opinion, this is the most powerful and flexible search engine and it
is not that heavy.
Just what Koha needs to expose a user-friendly search interface.
Librarians said to us that many users uses OPAC only for search and in a
Google-like mode.

As a Java developer, I will be pleased to help with Solr customization on
Java side.

Keep me in touch.

PS : note that Solr provides a very large language-specific modules, which
is needed for Koha international community.

Best regards,

-- 
Fridolyn SOMERS
ICT engineer
PROGILONE - Lyon - France
fridolyn.somers at gmail.com

On Wed, Aug 31, 2011 at 5:24 PM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Le 31/08/2011 16:55, Marcel de Rooy a ?crit :
> > What is the status of SRU support with solR at this time?
> I don't have the answer to this question, but, before someone else rise
> the z3950 one => we have developped the z3950 layer for solR.
>
> --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20110902/221b4439/attachment.htm>

From paul.poulain at biblibre.com  Fri Sep  2 11:04:16 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 02 Sep 2011 11:04:16 +0200
Subject: [Koha-devel] Strange encoding problems that sometimes happens
Message-ID: <4E609C10.8070401@biblibre.com>

Hello,

English natives will less concerned by this problem probably, but there
are/were some places where strange encoding problems occurs. We have a
fix for them (use utf8 decode function), but I was wondering what was
the origin of this problem.

I think Fr?d?rick Capovilla has a good explanation that I share with you
(it's a copy/paste of but 6479)
> It's been a while since I created that patch but here is what I understand :
>
> I remember that in the NewIssue subroutine of Serials.pm, The content of 
> $serialseq is concatenated with a variable fetched from a SQL query and that's
> where the problem happen.
>
> I did some tests to check the utf-8 flag on those two variables
> $serialseq = variable from the form (is_utf8 = false)
> $recievedlist = variable from SQL (is_utf8 = true)
>
> The encoding of the data fetched from SQL differs from the encoding of the data
> received from the form. If two string with a different encoding gets
> concatenated together, the encoding of one of the string is automatically
> changed, and we get an encoding problem on one half of the string.
>
> Using decode on $serialseq adds the utf-8 flag, so we don't get an encoding
> problem when we concatenate.
>
>
> We don't get this encoding problem when the first item is added in
> $recievedlist because $recievedlist is empty and doesn't automatically get the
> utf-8 flag. I'm guessing Perl DBI automatically addes the utf-8 flag if it
> finds utf-8 characters in a string returned from a SELECT.
If there are remaining places where this problem occurs, we know why &
how to fix it then !

PS: This explanation sounds highly logical to me. But if someone
disagree or has another explanation, feel free to drop a comment on the
bug or continue this thread !

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08


From paul.poulain at biblibre.com  Fri Sep  2 12:22:01 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 02 Sep 2011 12:22:01 +0200
Subject: [Koha-devel] call for help = BZ6328
Message-ID: <4E60AE49.7070800@biblibre.com>

Hello all,

Koha 3.6 will be released in less than two months, and there is a very
important patch that I just rebased a few minuts ago (& squashed)
It's the BZ 6328, and is related to fine in days. For french libraries
it's a must-have, 99% of french libraries set fines in days of debarment
instead of money. This feature had been integrated in 3.4, but it was
not functionnal, some important things were missing (it works on
biblibre/master, the problem was, as many times we've already seen, we
had everything in a single branch).

So i'd like to see this patch taken into account. So if you want to have
a look (yes, you...), feel free !

Thanks

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08


From colin.campbell at ptfs-europe.com  Fri Sep  2 13:20:03 2011
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Fri, 02 Sep 2011 12:20:03 +0100
Subject: [Koha-devel] Strange encoding problems that sometimes happens
In-Reply-To: <4E609C10.8070401@biblibre.com>
References: <4E609C10.8070401@biblibre.com>
Message-ID: <4E60BBE3.9030304@ptfs-europe.com>

On 02/09/11 10:04, Paul Poulain wrote:
> Hello,
> 
> English natives will less concerned by this problem probably, but there
> are/were some places where strange encoding problems occurs. We have a
> fix for them (use utf8 decode function), but I was wondering what was
> the origin of this problem.
> 
> I think Fr?d?rick Capovilla has a good explanation that I share with you
> (it's a copy/paste of but 6479)
>> It's been a while since I created that patch but here is what I understand :
>>
>> I remember that in the NewIssue subroutine of Serials.pm, The content of 
>> $serialseq is concatenated with a variable fetched from a SQL query and that's
>> where the problem happen.
>>
>> I did some tests to check the utf-8 flag on those two variables
>> $serialseq = variable from the form (is_utf8 = false)
>> $recievedlist = variable from SQL (is_utf8 = true)
>>
>> The encoding of the data fetched from SQL differs from the encoding of the data
>> received from the form. If two string with a different encoding gets
>> concatenated together, the encoding of one of the string is automatically
>> changed, and we get an encoding problem on one half of the string.
>>
>> Using decode on $serialseq adds the utf-8 flag, so we don't get an encoding
>> problem when we concatenate.
>>
>>
>> We don't get this encoding problem when the first item is added in
>> $recievedlist because $recievedlist is empty and doesn't automatically get the
>> utf-8 flag. I'm guessing Perl DBI automatically addes the utf-8 flag if it
>> finds utf-8 characters in a string returned from a SELECT.
> If there are remaining places where this problem occurs, we know why &
> how to fix it then !
> 
> PS: This explanation sounds highly logical to me. But if someone
> disagree or has another explanation, feel free to drop a comment on the
> bug or continue this thread !
> 
The perldoc for CGI.pm recommends using decode on input you need to be
in utf-8.
C.

-- 
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 at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com

From julian.maurice at biblibre.com  Fri Sep  2 13:37:09 2011
From: julian.maurice at biblibre.com (Julian Maurice)
Date: Fri, 02 Sep 2011 13:37:09 +0200
Subject: [Koha-devel] jquery plugin
In-Reply-To: <4E4A475A.7030605@biblibre.com>
References: <4E424EA2.1020403@biblibre.com>	<CAN-W4We-jBoaMkYUqsNdGtB02aEbuv5DMR3GQp3sjogkYt3+8A@mail.gmail.com>	<CAP3yOoke5FENUkJJCJkKCpYXpZbN88-9mu_p2Vaz4pHuYQ6_Pw@mail.gmail.com>
	<4E4A475A.7030605@biblibre.com>
Message-ID: <4E60BFE5.5030700@biblibre.com>

Le 16/08/2011 12:32, LAURENT Henri-Damien a ?crit :
> Le 10/08/2011 15:06, Chris Nighswonger a ?crit :
>> On Wed, Aug 10, 2011 at 5:51 AM, Reed Wade<reedwade at gmail.com
>> <mailto:reedwade at gmail.com>>  wrote:
>>
>>      Have you considered--
>>       http://www.datatables.net/
>>      ?
>>
>>      I did a little investigation of jquery table plugins a few months ago
>>      and picked that as my favourite. I ended up not using any as my data
>>      sets were very large and I didn't want to wire in their paging
>>      solution (even though it might have been the right thing to do after
>>      all).
>>
>>
>> +1 for datatables from me. I did some experimental work with this in
>> Koha quite a while back. (Owen may remember working with me a bit on
>> it.) It never went anywhere because I ran out of time.
>>
>> Kind Regards,
>> Chris
> ahem. In fact, as far as BibLibre is concerned, picnet was a first
> attempt, and uitablefilter too (because of ease of implementation and
> lack of time), but limits to those latest solutions prompted us into
> datatables.net which is really better.
> And we now have a quick guide for Koha integration. So that patch might
> be worth rewriting.

I submitted a patch on Bugzilla which includes all the necessary stuff 
to start using DataTables plugin. (Bug 6836)
I will propose another patch for an example on how to use it.

-- 
Julian Maurice <julian.maurice at biblibre.com>
BibLibre

From ian.walls at bywatersolutions.com  Fri Sep  2 15:10:59 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Fri, 2 Sep 2011 09:10:59 -0400
Subject: [Koha-devel] Fwd: [Zebralist] Zebra 2.0.49 available
In-Reply-To: <4E60CF05.4050303@indexdata.dk>
References: <4E60CF05.4050303@indexdata.dk>
Message-ID: <CAE2wdZyEn0MeE_tNwFeHqbuP-w5VHOyoD=r1u6azo9nxPqCj7w@mail.gmail.com>

Everyone,


Just an update.  Apparently "scan" was broken.


-Ian

---------- Forwarded message ----------
From: Adam Dickmeiss <adam at indexdata.dk>
Date: Fri, Sep 2, 2011 at 8:41 AM
Subject: [Zebralist] Zebra 2.0.49 available
To: Zebra Information Server <zebralist at lists.indexdata.dk>


Zebra 2.0.49 is available. Packaged for Debian, Ubuntu , CentOS and Windows
32-bit.

This version includes fixes for scan.


______________________________**_________________
Zebralist mailing list
Zebralist at lists.indexdata.dk
http://lists.indexdata.dk/cgi-**bin/mailman/listinfo/zebralist<http://lists.indexdata.dk/cgi-bin/mailman/listinfo/zebralist>



-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110902/0f7f4134/attachment.htm>

From David.W.Hartman at disney.com  Fri Sep  2 15:12:36 2011
From: David.W.Hartman at disney.com (Hartman, David W. - GBTS Library)
Date: Fri, 2 Sep 2011 09:12:36 -0400
Subject: [Koha-devel] Having difficulty with SMTP
In-Reply-To: <CAE2wdZyEn0MeE_tNwFeHqbuP-w5VHOyoD=r1u6azo9nxPqCj7w@mail.gmail.com>
References: <4E60CF05.4050303@indexdata.dk>
	<CAE2wdZyEn0MeE_tNwFeHqbuP-w5VHOyoD=r1u6azo9nxPqCj7w@mail.gmail.com>
Message-ID: <3E19441498923443B9DBE2FE1C0E70B60443E69E72@SM-FLOR-VXMB04B.wdw.disney.com>

Hello!

  My installer is having difficulty enabling system email.   Is there a good guide for setting up SMTP on Debian LINUX that someone can point me to?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110902/0c4fcd4f/attachment.htm>

From tomascohen at gmail.com  Fri Sep  2 15:37:43 2011
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Fri, 2 Sep 2011 10:37:43 -0300
Subject: [Koha-devel] koha 4.0 / solR / Zebra : A working group is born ?
In-Reply-To: <CAE2wdZzigiFrSp=3sJTLfzXKEKTavWxETCYMEb+DgrpHV559zQ@mail.gmail.com>
References: <4E5E3F88.1070508@biblibre.com>
	<809BE39CD64BFD4EB9036172EBCCFA3132701C@S-MAIL-1B.rijksmuseum.intra>
	<CAE2wdZzigiFrSp=3sJTLfzXKEKTavWxETCYMEb+DgrpHV559zQ@mail.gmail.com>
Message-ID: <CABZfb=UJuCh83XYi5VCiYa54Fp+oXWAe5E8edwWJDMh1uaBcbg@mail.gmail.com>

2011/8/31 Ian Walls <ian.walls at bywatersolutions.com>:
> This project should not cause any regressions in Zebra functionality.? If a
> function is available in Zebra that's not available in solR (or vice versa)
> the reimplemented code should be flexible enough to accommodate that.? The
> various features of each engine should be publicized to the community, and
> then anyone can use that information to pick which engine best meets their
> needs.? Hopefully Zebra and solR can both be grown in a way to bridge the
> gap.

I fully agree and plan to start reading the code this weekend.

Regards
To+

From julian.maurice at biblibre.com  Fri Sep  2 16:55:55 2011
From: julian.maurice at biblibre.com (Julian Maurice)
Date: Fri, 02 Sep 2011 16:55:55 +0200
Subject: [Koha-devel] jquery plugin
In-Reply-To: <4E60BFE5.5030700@biblibre.com>
References: <4E424EA2.1020403@biblibre.com>	<CAN-W4We-jBoaMkYUqsNdGtB02aEbuv5DMR3GQp3sjogkYt3+8A@mail.gmail.com>	<CAP3yOoke5FENUkJJCJkKCpYXpZbN88-9mu_p2Vaz4pHuYQ6_Pw@mail.gmail.com>	<4E4A475A.7030605@biblibre.com>
	<4E60BFE5.5030700@biblibre.com>
Message-ID: <4E60EE7B.6060108@biblibre.com>

Le 02/09/2011 13:37, Julian Maurice a ?crit :
> Le 16/08/2011 12:32, LAURENT Henri-Damien a ?crit :
>> Le 10/08/2011 15:06, Chris Nighswonger a ?crit :
>>> On Wed, Aug 10, 2011 at 5:51 AM, Reed Wade<reedwade at gmail.com
>>> <mailto:reedwade at gmail.com>> wrote:
>>>
>>> Have you considered--
>>> http://www.datatables.net/
>>> ?
>>>
>>> I did a little investigation of jquery table plugins a few months ago
>>> and picked that as my favourite. I ended up not using any as my data
>>> sets were very large and I didn't want to wire in their paging
>>> solution (even though it might have been the right thing to do after
>>> all).
>>>
>>>
>>> +1 for datatables from me. I did some experimental work with this in
>>> Koha quite a while back. (Owen may remember working with me a bit on
>>> it.) It never went anywhere because I ran out of time.
>>>
>>> Kind Regards,
>>> Chris
>> ahem. In fact, as far as BibLibre is concerned, picnet was a first
>> attempt, and uitablefilter too (because of ease of implementation and
>> lack of time), but limits to those latest solutions prompted us into
>> datatables.net which is really better.
>> And we now have a quick guide for Koha integration. So that patch might
>> be worth rewriting.
>
> I submitted a patch on Bugzilla which includes all the necessary stuff
> to start using DataTables plugin. (Bug 6836)
> I will propose another patch for an example on how to use it.
>
An example of datatables usage can now be found in Bug 6838.

-- 
Julian Maurice <julian.maurice at biblibre.com>
BibLibre

From chris at bigballofwax.co.nz  Fri Sep  2 20:54:45 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Sat, 3 Sep 2011 06:54:45 +1200
Subject: [Koha-devel] Idea for patch header (1st line)
In-Reply-To: <CA+95qVRipWfK_3=5ukTG+p7vGsenHEC4TP0zPKXfPuDtaNjkmw@mail.gmail.com>
References: <4E6090A4.4050905@biblibre.com>
	<CA+95qVRipWfK_3=5ukTG+p7vGsenHEC4TP0zPKXfPuDtaNjkmw@mail.gmail.com>
Message-ID: <CA+95qVSiYja7v_DkKvmMgv4R4=zJmTRMTTVZci08SgLBSuoW2g@mail.gmail.com>

On 2 September 2011 20:24, Chris Cormack <chris at bigballofwax.co.nz> wrote:
> On 2 September 2011 20:15, Paul Poulain <paul.poulain at biblibre.com> wrote:
>> Hello all,
>>
>> I'm following through RSS what is pushed, and I would be interested in
>> having a specific marker for patches that are related to Enhancements.
>> Something like
>> Bug XXXX blabla => it's a bugfix
>> Enh XXXX blabla => it's an enhancement
>>
>> I try to track pushed enhancements, I think doc writters & translators
>> would be highly interested by this difference as well.
>>
> In the meantime you can track the enhancements and bugs here
>
> http://koha-releasemanagement.branchable.com/posts/Work_for_3.6.x/
>
> Or in git
> enhancements are always pushed under an enh/ branch like
> new/enh/bug_6692
>
To help Paul (and others out)
I have start amending the commit message before I push to master

Like so
http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=ba78d6a8503d9340797eeabf2f9655efaee6f993

Chris


> Chris
>

From wrobertson1981 at yahoo.co.nz  Sat Sep  3 07:09:32 2011
From: wrobertson1981 at yahoo.co.nz (Waylon Robertson)
Date: Fri, 2 Sep 2011 22:09:32 -0700 (PDT)
Subject: [Koha-devel] koha 4.0 / solR / Zebra : A working group is born ?
In-Reply-To: <4E5E3F88.1070508@biblibre.com>
References: <4E5E3F88.1070508@biblibre.com>
Message-ID: <1315026572.26947.YahooMailNeo@web39415.mail.mud.yahoo.com>

okay, after todays failure of zebra, requiring a reindex, no idea why, i recall Apache Solr... so i do ?a search.. and i find, this.?
http://www.indexdata.com/news/2010/10/yaz-411-available-now-solr-support

in other words, does this give perl solr support, without too much work? or is this the result of work that was described below?


________________________________
From: Paul Poulain <paul.poulain at biblibre.com>
To: "koha-devel at lists.koha-community.org" <koha-devel at lists.koha-community.org>
Sent: Thursday, 1 September 2011 2:04 AM
Subject: [Koha-devel] koha 4.0 / solR / Zebra  : A working group is born ?

Hi,

As you all know, BibLibre has worked hard on integrating solR as search
engine into Koha. The resulting work is live in 2 french libraries, and
we plan to integrate it into Koha 4.0

Our preference went to do a in-depth work. It mean we changed the API a
lot, as well as most of the logic behind the search in Koha. It means we
can't keep zebra working as it is today.
Fortunately, the proposed structure is modularized, so it's possible to
re-implement zebra for those who want to stay with it. It's also
possible to reintegrate NoZebra or any other search engine.

Zeno Tajoli sent us a mail with some starting work about this
re-implementation of zebra. I catched tcohen on IRC today, his boss gave
him some time to investigate too. Claire Hernandez (our development
manager) is also helping.

Unless i'm mistaking, it's a draft of a "search engine working group".
If anyone else is interested, drop me (or claire) a mail, we could
organize an IRC session.

PS: i've submitted a presentation for KohaCon11 about what we did around
solR. But it will be librarian-oriented. We will/could/should probably
have a topic about that during HackFest as well ;-)

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

_______________________________________________
Koha-devel mailing list
Koha-devel at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110902/98bc0a66/attachment-0001.htm>

From paivakil at gmail.com  Sun Sep  4 07:51:12 2011
From: paivakil at gmail.com (Mahesh T Pai)
Date: Sun, 04 Sep 2011 11:21:12 +0530
Subject: [Koha-devel] Having difficulty with SMTP
References: <4E60CF05.4050303@indexdata.dk>
	<CAE2wdZyEn0MeE_tNwFeHqbuP-w5VHOyoD=r1u6azo9nxPqCj7w@mail.gmail.com>
	<3E19441498923443B9DBE2FE1C0E70B60443E69E72@SM-FLOR-VXMB04B.wdw.disney.com>
Message-ID: <87wrdoonxr.fsf@nandini.localhost>

"Hartman, David W. - GBTS Library"
<David.W.Hartman at disney.com> writes:

 > Hello!
>
 >  
>
 > ? My installer is having difficulty enabling system email.?? Is there a good
 > guide for setting up SMTP on Debian LINUX that someone can point me to??


Not quite sure what you mean. 

"Installer" as in Koha's installer? Or the deb package? 

And you are having trouble get up the system's email up and running? 

Or the difficulty is in getting Koha use the system's email which is
already configured and working? 

Debian typically used exim4 as the SMTP agent. For configuring exim4,
please go through #8.4.3 on 

  http://www.debian.org/releases/stable/i386/ch08s05.html.en

You can also see  

  http://wiki.debian.org/GmailAndExim4

You may  need to run "dpkg-reconfigure exim4-config" to change the exim4
settings. If you use an external server to send mail, (like google), you
will need to add the authentication details in /etc/exim4/passwd.client

Once done, you can test whether the kohaadmin on the system can send out
mails. 

Next step will be to make Koha to use the kohaadmin's mail settings to
send out mails. 

There is also a file somewhere in
/usr/share/koha/cronjobs/CONFIGURE.gmail

But I will prefer NOT to use sendmail on debian, since exim4 is default
there.




-- 
Mahesh T. Pai   ||
It's not the software that's free; it's you.


From jcamins at cpbibliography.com  Tue Sep  6 19:23:12 2011
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Tue, 6 Sep 2011 13:23:12 -0400
Subject: [Koha-devel] Koha db schema pecularities
Message-ID: <CALVDfQxB794Wu4aYc5vD-nXXAp_FqfjrhGdWL9FdE43J-EUb9Q@mail.gmail.com>

Hello.

I was looking at the schema that Koha uses for its database, and noticed a
few peculiarities that I wonder if anyone could shed some light on:

The serial table uses VARCHAR(100) for serial.biblionumber and
serial.subscriptionid. Is there any context in which those are not numeric
identifiers? Presumably as a result of that, there are no foreign key
constraints on the serial table. I think there probably should be.

There's a similar situation with the subscription table:
subscription.biblionumber doesn't have a foreign key relation with
biblio.biblionumber, nor, indeed, any index at all. Foreign keys are also
lacking for subscription.aqbooksellerid and subscription.aqbudgetid.

On the subject of foreign keys, should items.itype have a foreign key
linking it to itemtypes?

My understanding of foreign key relationships is that they're a Good Thing
because they provide a means to ensure referential integrity. Am I missing
something in these particular cases (and there are probably others, these
are just the ones I happened to notice), or would people say this was
probably just an oversight?

Regards,
Jared Camins-Esakov

-- 
Jared Camins-Esakov
Bibliographer, C & P Bibliography Services, LLC
(phone) +1 (917) 727-3445
(e-mail) jcamins at cpbibliography.com
(web) http://www.cpbibliography.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110906/2f995541/attachment.htm>

From henridamien.laurent at biblibre.com  Tue Sep  6 21:14:51 2011
From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien)
Date: Tue, 06 Sep 2011 21:14:51 +0200
Subject: [Koha-devel] Koha db schema pecularities
In-Reply-To: <CALVDfQxB794Wu4aYc5vD-nXXAp_FqfjrhGdWL9FdE43J-EUb9Q@mail.gmail.com>
References: <CALVDfQxB794Wu4aYc5vD-nXXAp_FqfjrhGdWL9FdE43J-EUb9Q@mail.gmail.com>
Message-ID: <4E66712B.1040907@biblibre.com>

Le 06/09/2011 19:23, Jared Camins-Esakov a ?crit :
> Hello.
Hi,

> 
> I was looking at the schema that Koha uses for its database, and noticed
> a few peculiarities that I wonder if anyone could shed some light on:
> 
> The serial table uses VARCHAR(100) for serial.biblionumber and
> serial.subscriptionid. 

> Is there any context in which those are not
> numeric identifiers? 
I donot think so.
They should indeed be INT or BIGINT.
> Presumably as a result of that, there are no
> foreign key constraints on the serial table. I think there probably
> should be.
you are right and even, serial.biblionumber should be removed from taht
table since it is in subscription table.

> 
> There's a similar situation with the subscription table:
> subscription.biblionumber doesn't have a foreign key relation with
> biblio.biblionumber, nor, indeed, any index at all.
same here.

> Foreign keys are
> also lacking for subscription.aqbooksellerid and subscription.aqbudgetid.
I think we (BibLibre) have some interesting ongoing work wich copes with
serials acquisitions which could result in getting rid of that data.

> 
> On the subject of foreign keys, should items.itype have a foreign key
> linking it to itemtypes?
Could be discussed. But items.itype was introduced in 3.0 in order to
store itemtype in addition with ccode (circulation/collection code).
I think that items.itype should stick to itemtype. But since it CAN be
NULL sometimes when you donot use itemtypes, then creating a foreign key
would be too much compelling. You surely would not like to see the data
not stored silently because of a FK check fail on that data.
Koha was meant to manage mandatory tags/subfields from the interface and
not at a database level (from what I know of  it).

> 
> My understanding of foreign key relationships is that they're a Good
> Thing because they provide a means to ensure referential integrity. Am I
> missing something in these particular cases (and there are probably
> others, these are just the ones I happened to notice), or would people
> say this was probably just an oversight?
> 
> Regards,
Regards.
-- 
Henri-Damien LAURENT

From tdavis at uttyler.edu  Tue Sep  6 22:35:37 2011
From: tdavis at uttyler.edu (Elliott Davis)
Date: Tue, 6 Sep 2011 15:35:37 -0500
Subject: [Koha-devel] Meeting Times
Message-ID: <8754F6E19960C249BB9C8FFECA6277400153CF4D88@dogbert>

Hi All,

I just wanted to remind everyone about the IRC meeting tomorrow September the 7th at 18:00 UTC.  Also please note this is a nominations meeting.

For those that are interested we will also be having a meeting September the 8th at 18:00 UTC to discuss revamping the notifications system.  Please refer to the wiki for proposed details http://wiki.koha-community.org/wiki/Notifications_RFC

Best Regards,

Elliott Davis
Robert R. Muntz Library
University of Texas at Tyler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110906/eec47765/attachment.htm>

From ian.walls at bywatersolutions.com  Tue Sep  6 22:35:56 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Tue, 6 Sep 2011 16:35:56 -0400
Subject: [Koha-devel] [Zebralist] Zebra 2.0.49 available
In-Reply-To: <CAE2wdZyEn0MeE_tNwFeHqbuP-w5VHOyoD=r1u6azo9nxPqCj7w@mail.gmail.com>
References: <4E60CF05.4050303@indexdata.dk>
	<CAE2wdZyEn0MeE_tNwFeHqbuP-w5VHOyoD=r1u6azo9nxPqCj7w@mail.gmail.com>
Message-ID: <CAE2wdZwAfG41PiWk7DbcxsrH6nWE-xr2tKZmn9xG+sq8m6cgSQ@mail.gmail.com>

Everyone,


I've received some more info from Adam Dickmeiss about the fixes for scan:

Two special cases were not working as they should . In one case, when
scanning backwards it could skip one entry . The other case was a client
asking for 20 entries with preferred position being 22 . Zebra would refuse
doing that. (in the years we have not seen any use case of that .. At most
position would be number of entries + 1).

I'm not sure how this relates to our usage of Zebra scan in Koha, but it
definitely doesn't seem as dire as I may have made it sound.

Cheers,


-Ian

On Fri, Sep 2, 2011 at 9:10 AM, Ian Walls <ian.walls at bywatersolutions.com>wrote:

> Everyone,
>
>
> Just an update.  Apparently "scan" was broken.
>
>
> -Ian
>
>
> ---------- Forwarded message ----------
> From: Adam Dickmeiss <adam at indexdata.dk>
> Date: Fri, Sep 2, 2011 at 8:41 AM
> Subject: [Zebralist] Zebra 2.0.49 available
> To: Zebra Information Server <zebralist at lists.indexdata.dk>
>
>
> Zebra 2.0.49 is available. Packaged for Debian, Ubuntu , CentOS and Windows
> 32-bit.
>
> This version includes fixes for scan.
>
>
> ______________________________**_________________
> Zebralist mailing list
> Zebralist at lists.indexdata.dk
> http://lists.indexdata.dk/cgi-**bin/mailman/listinfo/zebralist<http://lists.indexdata.dk/cgi-bin/mailman/listinfo/zebralist>
>
>
>
> --
> Ian Walls
> Lead Development Specialist
> ByWater Solutions
> Phone # (888) 900-8944
> http://bywatersolutions.com
> ian.walls at bywatersolutions.com
> Twitter: @sekjal
>



-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110906/59d3f37f/attachment.htm>

From nengard at gmail.com  Wed Sep  7 18:34:18 2011
From: nengard at gmail.com (Nicole Engard)
Date: Wed, 7 Sep 2011 12:34:18 -0400
Subject: [Koha-devel] Roles for Koha 3.8
In-Reply-To: <4E5FAAF0.5020208@biblibre.com>
References: <4E5FAAF0.5020208@biblibre.com>
Message-ID: <CAC0K6VER92Np91ktPSOgu00PUct_cUtbRMiEZdLt+7gEGix1XA@mail.gmail.com>

Sorry all, I just didn't add myself to the list, but will continue in
my roles - my name is on there now.

Nicole

On Thu, Sep 1, 2011 at 11:55 AM, Paul Poulain <paul.poulain at biblibre.com> wrote:
> Hello,
>
> A reminder:
> Everyone that plan to volunteer for a position in next Koha 3.8 version
> is welcomed to file his/her name on the wiki page:
> http://wiki.koha-community.org/wiki/Roles_for_3.8
> The following positions are (desperately) empty:
>
> ? ?* Translation Manager
> ? ?* Documentation Manager
> ? ?* Documentation of DB
> ? ?* QA Manager
> ? ?* Specific Module maintainers
> ? ?* Release Maintainer
> ? ?* Packaging Manager
>
> 2nd reminder: on july IRC meeting, we decided:
>
> ? 1. /AGREED/: Express interest via the mailing list for Nominations by
> ? ? ?22 September. Elections in October
>
> (see
> http://librarypolice.com/koha-meetings/2011/koha.2011-08-02-02.00.html )
>
> so, you still have 21 days left...
>
> --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>

From ian.walls at bywatersolutions.com  Wed Sep  7 18:42:43 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Wed, 7 Sep 2011 12:42:43 -0400
Subject: [Koha-devel] Roles for Koha 3.8
In-Reply-To: <CAC0K6VER92Np91ktPSOgu00PUct_cUtbRMiEZdLt+7gEGix1XA@mail.gmail.com>
References: <4E5FAAF0.5020208@biblibre.com>
	<CAC0K6VER92Np91ktPSOgu00PUct_cUtbRMiEZdLt+7gEGix1XA@mail.gmail.com>
Message-ID: <CAE2wdZyrGBH6631ya28yjJYQgpg=PPE8S0e4T888eX3zcS1j3g@mail.gmail.com>

I have also added myself as a candidate for Quality Assurance Manager for
3.8 (continuing my role from 3.6).  We can discuss this further at the
meeting in Koha IRC (in just about 20 minutes!)


-Ian

On Wed, Sep 7, 2011 at 12:34 PM, Nicole Engard <nengard at gmail.com> wrote:

> Sorry all, I just didn't add myself to the list, but will continue in
> my roles - my name is on there now.
>
> Nicole
>
> On Thu, Sep 1, 2011 at 11:55 AM, Paul Poulain <paul.poulain at biblibre.com>
> wrote:
> > Hello,
> >
> > A reminder:
> > Everyone that plan to volunteer for a position in next Koha 3.8 version
> > is welcomed to file his/her name on the wiki page:
> > http://wiki.koha-community.org/wiki/Roles_for_3.8
> > The following positions are (desperately) empty:
> >
> >    * Translation Manager
> >    * Documentation Manager
> >    * Documentation of DB
> >    * QA Manager
> >    * Specific Module maintainers
> >    * Release Maintainer
> >    * Packaging Manager
> >
> > 2nd reminder: on july IRC meeting, we decided:
> >
> >   1. /AGREED/: Express interest via the mailing list for Nominations by
> >      22 September. Elections in October
> >
> > (see
> > http://librarypolice.com/koha-meetings/2011/koha.2011-08-02-02.00.html )
> >
> > so, you still have 21 days left...
> >
> > --
> > Paul POULAIN
> > http://www.biblibre.com
> > Expert en Logiciels Libres pour l'info-doc
> > Tel : (33) 4 91 81 35 08
> >
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at 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/
> >
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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 at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110907/7e9f53cc/attachment.htm>

From ian.walls at bywatersolutions.com  Wed Sep  7 23:58:06 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Wed, 7 Sep 2011 17:58:06 -0400
Subject: [Koha-devel] Commentary on Paul's Koha 3.8 Release Manager proposal
Message-ID: <CAE2wdZwcbYEn+EGr54wJDy00__HEK1Hy6SN=LdXB7hFSv__FRw@mail.gmail.com>

Everyone,


Enclosed is my response to Paul Poulain's proposal for Koha 3.8 Release
Manager.  The details of his document can be found here:
http://wiki.koha-community.org/wiki/Proposal_paul_p_RM38

I thoroughly agree that the time has come to start thinking beyond the next
stable release, and on to Koha 4.0.  Those of you who have seen either my
presentation at KohaCon 2010's hackfest or KUDOScon 2011 know I'm very
excited about the possibilities of where we can take Koha in it's next major
iteration.  However, I disagree with a couple of the details of Paul's
proposal.

The major disagreement is with the timeline.  The proposal as it stands is
to start working on Koha 3.8 and Koha 4.0 in parallel, with Koha 3.8
releasing April 2012, and Koha 4.0 releasing Oct. 2012.  I feel that going
from Koha 3.8 directly to 4.0 is unwarranted.  To my mind, there are many
possible releases between 3.8 and 4.0, like 3.10, 3.12, 3.14 and so forth.
This is supported by the actual database version numbers in Koha: the
current release is actually 3.04.04; the zeros are squashed out for
convenience.

I would counter that, while we should continue releasing new features every
6 months on the 3.X line, Koha 4.0 should be defined by it's features.
Paul's proposal calls several features to be key, including Solr
integration, database abstraction, updated online help, improved
authentication stack and automated tests.  I agree that all these things are
important and should be worked towards, but I'm not convinced they should be
the sum total of the changes that define Koha 4.0

I would like to see the following in Koha 4.0:

   - arbitrary metadata formats (beyond MARC)
   - arbitrary biblio relationships
   - full support for authority records, including uploading through the
   GUI, automatic linking, "explode" searching and more
   - improvements to the borrower data structure (fewer pre-defined data
   fields, more flexibility)
   - separation of "receiving" and "payment" in acquisitions
   - serials import and export (MFHD, prediction patterns, etc)
   - many, many more things

I think that the community should meet and discuss what features are both
desirable and reasonably likely to be completed in the next few years (is
there interest by libraries to sponsor these developments, or from
developers to code it "for fun"?).

Once a feature set is agreed on to "define" Koha 4.0, the developers of
these features would meet to hash out what underlying structural changes
would be required to make them happen.  Hopefully commonalities could be
found, so that the underlying structure could be developed in a way that
accommodates multiple developments at once.  Identifying these prerequisite
changes early on would reduce the difficulties of rebasing developments,
since we'd all be working off a similar set of base assumptions.  It would
also provide a reasonable basis for excluding or delaying developments that
don't fit into the overall plan.

Once the features were chosen and a framework for their development agreed
upon, it would be time to code.  The development and submission process
would be the same as it is now (basing patches off master and submitting to
the patches listserv and Bugzilla).  As new features become ready, they
would be incorporated into the time-based 3.X releases by the release
manager for that particular cycle.  This way, what works is made available,
and what needs more time continues to be tested until it's stable for
production use.  Once all the agreed upon features were ready, it would be
time to release Koha 4.0.  Hopefully, that would be with 1-2 years, but
there would be flexibility here.

One of my other issues with the proposal was the "lightening" of Quality
Assurance standards for the first 3 months of the 3.8 release cycle.  If
operating under the 1 year time frame for Koha 4.0 as outlined in Paul's
proposal, this would seem necessary in order to get everything included in
time.  Unfortunately, while the next 3 months would be dedicated to clean up
of features rolled in, there is never any guarantee of bug fixes being
generated in a timely fashion.  You cannot force people to write or sign off
on bug fixes; we're all free agents here.  So code that has not been
rigourously tested could get in and stay in for a long time, long after 4.0
would release, because no one knows how to test it or fix it.

However, if we operate under my proposed model, all code could continue to
operate under the same quality assurance standards, and nothing that is
broken or otherwise incomplete would make it in until it was ready.
Releases would still come out every 6 months, even if a major development
was inoperable, until that development could be completed.

This has been a long email, so let me sum up.  I think:

   - we should continue to release Koha 3.8, 3.10, 3.12 etc on 6 month
   cycles using the current community practices for feature inclusion
   - we should, as a community, meet and decide what features we want to
   define Koha 4.0
   - the developers of those features should get together and come up with a
   unified plan for accomplishing them all, in a way that requires minimal
   rebasing
   - as new features become stable and tested, they should be folded into
   the 3.X line until all the features defined as "Koha 4.0" are ready
   - Once all the agreed upon features are complete, Koha 4.0 is then
   released.

I've already gotten some feedback on this in today's Koha IRC meeting, but
I'd very much like to hear what the rest of the community thinks about this,
particular in relation to Paul's proposal for 3.8 Release Manager.  Our time
is limited for discussion, as the election time draws near, but hopefully
I've made my thoughts clear enough for a dialogue to get started.  Please
let me know if I've been at all unclear.

Cheers,


-Ian

-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110907/fe571397/attachment.htm>

From M.de.Rooy at rijksmuseum.nl  Thu Sep  8 12:30:48 2011
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 8 Sep 2011 10:30:48 +0000
Subject: [Koha-devel] FW: [Koha] Commentary on Paul's Koha 3.8 Release
	Manager proposal
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3132A709@S-MAIL-1B.rijksmuseum.intra>

I think both proposals (from Paul and Ian) contain very good points, are ambitious and motivating for the community. With people like Ian and Paul in the release team, we will definitely reach a Koha 4.0! 

I would however not favor working in parallel on Koha 3.8 and 4.0 as well as maintaining 3.6.X (and possible even 3.4.X for a while). I think that three or four versions together with lowering quality standards will not result in a better product, but could imply more bugs, rebasing problems and time lost on synchronizing between versions, testing in multiple versions, etc. 
Why not keep it simpler? Develop in master (heading to 4.0 and solR), and keep 3.6.X stable (as soon as 3.6.X is there, declare 3.4.X end-of-life too). Just focus on those two versions.

A long feature list for 4.0 is very nice and Ian's development plan may theoretically be the best way to go, but probably hard to realize in practice. A simpler approach would be: as soon as solR and searching is ready and stable, we reach 4.0. This could be after 3.8, 3.10, .. (Stick to the 6m cycle.) 

We have been growing into a higher QA standard when we came from 3.2. I think it would be a pity if we already lower that standard too quickly. A problem is obviously the longer time between submission and pushing. Probably, we could improve in that area by adding some persons at the QA level (Ian may have two assistants in 3.8?), asking the bug wranglers to test older patches first and let them communicate more about these patches, and doing QA first on these older signed patches. Currently, time does not really rule selection of a patch in signoff or QA, but other factors like author, size, attractive title, etc.  
At the same time we could allow people perhaps to sign the more easy, trivial patches themselves (especially if they have them running in production already somewhere). If QA would disagree, they could lower the patch status back to Needs signoff for getting another external test. We could make a proposal how to change current procedures for this without compromizing quality. 
What we should avoid, is large, very large patches without test plan. These patches did not come through now too. Which is quite understandable. Such patches should be broken up into manageable units with a test plan.

Hope this helps,

Marcel

> Everyone,
> 
> 
> Enclosed is my response to Paul Poulain's proposal for Koha 3.8 Release
> Manager.  The details of his document can be found here:
> http://wiki.koha-community.org/wiki/Proposal_paul_p_RM38
> 
> I thoroughly agree that the time has come to start thinking beyond the
> next stable release, and on to Koha 4.0.  Those of you who have seen
> either my presentation at KohaCon 2010's hackfest or KUDOScon 2011 know
> I'm very excited about the possibilities of where we can take Koha in
> it's next major iteration.  However, I disagree with a couple of the
> details of Paul's proposal.
> 
> The major disagreement is with the timeline.  The proposal as it stands
> is to start working on Koha 3.8 and Koha 4.0 in parallel, with Koha 3.8
> releasing April 2012, and Koha 4.0 releasing Oct. 2012.  I feel that
> going from Koha 3.8 directly to 4.0 is unwarranted.  To my mind, there
> are many possible releases between 3.8 and 4.0, like 3.10, 3.12, 3.14
> and so forth.  This is supported by the actual database version numbers
> in Koha: the current release is actually 3.04.04; the zeros are squashed
> out for convenience.
> 
> I would counter that, while we should continue releasing new features
> every 6 months on the 3.X line, Koha 4.0 should be defined by it's
> features.  Paul's proposal calls several features to be key, including
> Solr integration, database abstraction, updated online help, improved
> authentication stack and automated tests.  I agree that all these things
> are important and should be worked towards, but I'm not convinced they
> should be the sum total of the changes that define Koha 4.0
> 
> I would like to see the following in Koha 4.0:
> 
>     * arbitrary metadata formats (beyond MARC)
>     * arbitrary biblio relationships
>     * full support for authority records, including uploading through
>       the GUI, automatic linking, "explode" searching and more
>     * improvements to the borrower data structure (fewer pre-defined
>       data fields, more flexibility)
>     * separation of "receiving" and "payment" in acquisitions
>     * serials import and export (MFHD, prediction patterns, etc)
>     * many, many more things
> 
> I think that the community should meet and discuss what features are
> both desirable and reasonably likely to be completed in the next few
> years (is there interest by libraries to sponsor these developments, or
> from developers to code it "for fun"?).
> 
> Once a feature set is agreed on to "define" Koha 4.0, the developers of
> these features would meet to hash out what underlying structural changes
> would be required to make them happen.  Hopefully commonalities could be
> found, so that the underlying structure could be developed in a way that
> accommodates multiple developments at once.  Identifying these
> prerequisite changes early on would reduce the difficulties of rebasing
> developments, since we'd all be working off a similar set of base
> assumptions.  It would also provide a reasonable basis for excluding or
> delaying developments that don't fit into the overall plan.
> 
> Once the features were chosen and a framework for their development
> agreed upon, it would be time to code.  The development and submission
> process would be the same as it is now (basing patches off master and
> submitting to the patches listserv and Bugzilla).  As new features
> become ready, they would be incorporated into the time-based 3.X
> releases by the release manager for that particular cycle.  This way,
> what works is made available, and what needs more time continues to be
> tested until it's stable for production use.  Once all the agreed upon
> features were ready, it would be time to release Koha 4.0.  Hopefully,
> that would be with 1-2 years, but there would be flexibility here.
> 
> One of my other issues with the proposal was the "lightening" of Quality
> Assurance standards for the first 3 months of the 3.8 release cycle.  If
> operating under the 1 year time frame for Koha 4.0 as outlined in Paul's
> proposal, this would seem necessary in order to get everything included
> in time.  Unfortunately, while the next 3 months would be dedicated to
> clean up of features rolled in, there is never any guarantee of bug
> fixes being generated in a timely fashion.  You cannot force people to
> write or sign off on bug fixes; we're all free agents here.  So code
> that has not been rigourously tested could get in and stay in for a long
> time, long after 4.0 would release, because no one knows how to test it
> or fix it.
> 
> However, if we operate under my proposed model, all code could continue
> to operate under the same quality assurance standards, and nothing that
> is broken or otherwise incomplete would make it in until it was ready. 
> Releases would still come out every 6 months, even if a major
> development was inoperable, until that development could be completed.
> 
> This has been a long email, so let me sum up.  I think:
> 
>     * we should continue to release Koha 3.8, 3.10, 3.12 etc on 6 month
>       cycles using the current community practices for feature inclusion
>     * we should, as a community, meet and decide what features we want
>       to define Koha 4.0
>     * the developers of those features should get together and come up
>       with a unified plan for accomplishing them all, in a way that
>       requires minimal rebasing
>     * as new features become stable and tested, they should be folded
>       into the 3.X line until all the features defined as "Koha 4.0" are
>       ready
>     * Once all the agreed upon features are complete, Koha 4.0 is then
>       released.
> 
> I've already gotten some feedback on this in today's Koha IRC meeting,
> but I'd very much like to hear what the rest of the community thinks
> about this, particular in relation to Paul's proposal for 3.8 Release
> Manager.  Our time is limited for discussion, as the election time draws
> near, but hopefully I've made my thoughts clear enough for a dialogue to
> get started.  Please let me know if I've been at all unclear.
> 
> Cheers,
> 
> 
> -Ian
> 
> -- 
> Ian Walls
> Lead Development Specialist
> ByWater Solutions
> Phone # (888) 900-8944 <tel:%28888%29%20900-8944>
> http://bywatersolutions.com
> ian.walls at bywatersolutions.com <mailto:ian.walls at bywatersolutions.com>
> Twitter: @sekjal
> 
> 
> 
> _______________________________________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha

_______________________________________________
Koha mailing list  http://koha-community.org
Koha at lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha

From David.W.Hartman at disney.com  Fri Sep  9 22:11:14 2011
From: David.W.Hartman at disney.com (Hartman, David W. - GBTS Library)
Date: Fri, 9 Sep 2011 16:11:14 -0400
Subject: [Koha-devel] FW: User Request for update of Record.
Message-ID: <3E19441498923443B9DBE2FE1C0E70B60443E69FE3@SM-FLOR-VXMB04B.wdw.disney.com>

I am getting this error message when I try to send admin notices.  Can anyone help?

_____________________________________________
From: postmaster at int1.disney.pvt [mailto:postmaster at int1.disney.pvt]
Sent: Friday, September 09, 2011 4:05 PM
To: Hartman, David W. - GBTS Library
Subject: Undeliverable: User Request for update of Record.


Delivery has failed to these recipients or distribution lists:

david.w.hartman at disney.com<mailto:david.w.hartman at disney.com>

NOTE: If you are sending a message to an ESPN employee and using Outlook 2007 on a PC, click the To: field and click on the name in the Global Address List to add it. Then click OK.

The recipient's e-mail address was not found in the recipient's e-mail system. Exchange will not try to redeliver this message for you. Please check the e-mail address and try resending this message, or provide the following diagnostic text to your system administrator.



Diagnostic information for administrators:

Generating server: int1.disney.pvt

david.w.hartman at disney.com
#< #5.1.1> #SMTP#

Original message headers:

Received: from WW-R-ITLWDW1K5M.wdw.disney.com ([ww-r-itlwdw1k5m.wdw.disney.com
 [172.16.190.240]]) by int11.disney.pvt with ESMTP id p89K51ud009424 ;
          Fri, 9 Sep 2011 20:05:01 +0000
Received: from WW-R-ITLWDW1K5M.wdw.disney.com (WW-R-ITLWDW1K5M.wdw.disney.com [127.0.0.1])
        by WW-R-ITLWDW1K5M.wdw.disney.com (Postfix) with ESMTP id B7CF63DAAD
        for <david.w.hartman at disney.com>; Fri,  9 Sep 2011 16:03:34 -0400 (EDT)
Subject: User Request for update of Record.
Date: Fri, 9 Sep 2011 16:03:34 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf8"
To: <david.w.hartman at disney.com>
Content-Transfer-Encoding: quoted-printable
From: <david.w.hartman at disney.com>
Message-ID: <20110909200334.B7CF63DAAD at WW-R-ITLWDW1K5M.wdw.disney.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110909/318110b7/attachment.htm>

From kmkale at anantcorp.com  Mon Sep 12 08:04:40 2011
From: kmkale at anantcorp.com (Koustubha Kale)
Date: Mon, 12 Sep 2011 11:34:40 +0530
Subject: [Koha-devel] kohacon11 : Update..
Message-ID: <CAP=kTZrZbkHC3RcmbBsh0sux6qYqqukKwk6dkHn9jXTNOo8R8Q@mail.gmail.com>

Hi All,
My apologies for missing yet another meeting. I had an accident. Right arm (
my working arm ) bone & elbow broken. Had to be hospitalized and operated
on. I had actually logged in for the meeting with my mobile & left thumb but
I was overwhelmed by the medicines during the 3.4 discussion. Anyway I am
home now with a couple of weeks compulsory rest.

Kohacon11 program as put up by Brooke
here<http://wiki.koha-community.org/wiki/Kohacon2011>(
http://wiki.koha-community.org/wiki/Kohacon2011 ) looks good. All ground
preparations are in hand by VPM authorities. I have requested an additional
hall/classroom may be made available in case we require it  to run parallel
tracks.  I will communicate more details about the planned cultural program
& dinner, planned one day Mumbai trip for 3rd November etc..

So looks like we will have a great Kohacon11. Looking forward to meeting you
all there..

Regards,
Koustubha Kale
Anant Corporation

Contact Details :
Address  : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka,
Thane (w),
                Maharashtra, India, Pin : 400601.
TeleFax  : +91-22-21720108, +91-22-21720109
Mobile     : +919820715876
Website  : http://www.anantcorp.com
Blog : http://www.anantcorp.com/blog/?author=2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110912/a4d0d4d0/attachment.htm>

From fridolyn.somers at gmail.com  Mon Sep 12 11:02:26 2011
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Mon, 12 Sep 2011 11:02:26 +0200
Subject: [Koha-devel] FW: User Request for update of Record.
In-Reply-To: <3E19441498923443B9DBE2FE1C0E70B60443E69FE3@SM-FLOR-VXMB04B.wdw.disney.com>
References: <AcxvK8ubapFAiF8lQ1anh1o5iZ6OkgAAAABqAAAEtoAAACBdQA==>
	<3E19441498923443B9DBE2FE1C0E70B60443E69FE3@SM-FLOR-VXMB04B.wdw.disney.com>
Message-ID: <CAN6cLAX7cwiMqt_76gf5=5igfr2+vK2XaaBwVeyU68JWaP-rpA@mail.gmail.com>

Hie,

Seems to be an MS Exchange protection : "The recipient's e-mail address was
not found in the recipient's e-mail system".
Look in Exchange forums i'd say.

Best regards,

-- 
Fridolyn SOMERS
ICT engineer
PROGILONE - Lyon - France
fridolyn.somers at gmail.com

2011/9/9 Hartman, David W. - GBTS Library <David.W.Hartman at disney.com>

>  I am getting this error message when I try to send admin notices.  Can
> anyone help?
>
> _____________________________________________
> *From:* postmaster at int1.disney.pvt [mailto:postmaster at int1.disney.pvt<postmaster at int1.disney.pvt>]
>
> *Sent:* Friday, September 09, 2011 4:05 PM
> *To:* Hartman, David W. - GBTS Library
> *Subject:* Undeliverable: User Request for update of Record.
>
>
> *Delivery has failed to these recipients or distribution lists:*
>
> *david.w.hartman at disney.com* <david.w.hartman at disney.com>
>
> *NOTE: If you are sending a message to an ESPN employee and using Outlook
> 2007 on a PC, click the To: field and click on the name in the Global
> Address List to add it. Then click OK. *
>
> The recipient's e-mail address was not found in the recipient's e-mail
> system. Exchange will not try to redeliver this message for you. Please
> check the e-mail address and try resending this message, or provide the
> following diagnostic text to your system administrator.
>
>
> *Diagnostic information for administrators:*
>
> Generating server: int1.disney.pvt
>
> david.w.hartman at disney.com
> #< #5.1.1> #SMTP#
>
> Original message headers:
>
> Received: from WW-R-ITLWDW1K5M.wdw.disney.com ([
> ww-r-itlwdw1k5m.wdw.disney.com
>  [172.16.190.240]]) by int11.disney.pvt with ESMTP id p89K51ud009424 ;
>           Fri, 9 Sep 2011 20:05:01 +0000
> Received: from WW-R-ITLWDW1K5M.wdw.disney.com (
> WW-R-ITLWDW1K5M.wdw.disney.com [127.0.0.1])
>         by WW-R-ITLWDW1K5M.wdw.disney.com (Postfix) with ESMTP id
> B7CF63DAAD
>         for <david.w.hartman at disney.com>; Fri,  9 Sep 2011 16:03:34 -0400
> (EDT)
> Subject: User Request for update of Record.
> Date: Fri, 9 Sep 2011 16:03:34 -0400
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf8"
> To: <david.w.hartman at disney.com>
> Content-Transfer-Encoding: quoted-printable
> From: <david.w.hartman at disney.com>
> Message-ID: <20110909200334.B7CF63DAAD at WW-R-ITLWDW1K5M.wdw.disney.com>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20110912/fb994c91/attachment.htm>

From paul.poulain at biblibre.com  Mon Sep 12 11:33:17 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Mon, 12 Sep 2011 11:33:17 +0200
Subject: [Koha-devel] Commentary on Paul's Koha 3.8 Release Manager
	proposal
In-Reply-To: <CAE2wdZwcbYEn+EGr54wJDy00__HEK1Hy6SN=LdXB7hFSv__FRw@mail.gmail.com>
References: <CAE2wdZwcbYEn+EGr54wJDy00__HEK1Hy6SN=LdXB7hFSv__FRw@mail.gmail.com>
Message-ID: <4E6DD1DD.6090302@biblibre.com>

Le 07/09/2011 23:58, Ian Walls a ?crit :
> Everyone,
Hi Ian & everyone,
> The major disagreement is with the timeline.  The proposal as it
> stands is to start working on Koha 3.8 and Koha 4.0 in parallel, with
> Koha 3.8 releasing April 2012, and Koha 4.0 releasing Oct. 2012.  I
> feel that going from Koha 3.8 directly to 4.0 is unwarranted.  To my
> mind, there are many possible releases between 3.8 and 4.0, like 3.10,
> 3.12, 3.14 and so forth.  This is supported by the actual database
> version numbers in Koha: the current release is actually 3.04.04; the
> zeros are squashed out for convenience.
I think our main (only ?) disagreement is based on some
misunderstandings. I'll try to explain more clearly.

Here is the timeline for Koha 3.8 :
* starts 2011-11
* feature freeze 2012-03
* release 2012-04

In my proposal, Koha 4.0 has the following timeline :
* defining the strategy & the roadmap start 2011-11 and end in 2012-01
(3 months)
* hacking starts in 2012-02
* feature freeze start in 2012-09
* release 2012-10

It means there will/can have a real hacking overlap of something like 2
months (feb-march 2012)

According to me, we could even start immediately to list everything
we're dreaming of.
The 2nd step being to evaluate how we can achieve each goal, who can
endorse the needed work, which priority for what.

Maybe another point of disagreement/misunderstanding is that you propose
"a 4.0 with everything we want" while I propose "a 4.0 with everything
that can fit in the 6 months timeline"
We switched from Feature-based release to Time-based release, and I
definitely don't want to change this. This has been a  major good
decision we shouldn't change !

My second rule is "if you change something important in the structure of
Koha, 1st digit get a +1". [ With the change of templating system, we
could have updated the version to 4.0 instead of 3.6, that would not
have been a scandal (frenchism suspected...) ! ]

It means that, for example, we decide that the priorities are (from
biggest to lowest)
1- update indexing engine
2- enable database persistency
3- arbitrary metadata formats (beyond MARC)
Step 1 and 2 have volunteers & code & ... => it will be in 4.0
Step 3 doesn't have a volunteer => it will be in 5.0
After 4.0 there will be a 4.2 or  a 5.0 depending on step 3 being ready.

I like the idea of a roadmap, with the following chapters :
Will be in version XX :
  * feature A already merged
  * feature B already merged
  * ...
Should be in version XX :
  * feature C, patch submitted, being examinated

Could be in version XX :
  * feature D, announced by mail at people.com

Have been submitted but rejected for instance :
  * feature E, patch does not apply
  * feature F, failed QA
  * ...

(doesn't eclipse have such a roadmap ? not sure)

Should I conclude that the version number should be decided/defined when
feature freeze reached ? Maybe, i'm not sure.

About your idea of 3.10, 3.12,... I fear/feel that we can't afford
managing the conflicts that will result :
* "4.0" has database persistency merged, we still lack "indexing engine
changes", so 4.0 has not been released
* a patch to enable "arbitrary biblio relationships" is submitted for
3.x It will be totally incompatible with "4.0 still unreleased" and we
have a problem...
> One of my other issues with the proposal was the "lightening" of
> Quality Assurance standards for the first 3 months of the 3.8 release
> cycle.
You've forgotten to specify i've written "how exactly, To Be Discussed".
This is only a main concern I have expressed before : smoothen things.
The idea of sandboxes to have more ppl testing will be a step in this
direction. I'll also send regular mails to try to motivate ppl to
test/sign-off. Maybe that will be enough. But maybe we could also accept
a derivative workflow like "there are some experienced ppl that can
decide to do sign-off and passed QA at the same time, they're
experienced&wise enough to decide if a patch is small/trivial enough to
be applied without a 2nd eye checking". Or ther(s) rule(s) we could
discuss (I have a lot of suggestions I could/will do). My idea is not to
lower the quality.

Ian, thanks to continue this thread.

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08


From paul.poulain at biblibre.com  Mon Sep 12 14:03:50 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Mon, 12 Sep 2011 14:03:50 +0200
Subject: [Koha-devel] kohacon11 : Update..
In-Reply-To: <CAP=kTZrZbkHC3RcmbBsh0sux6qYqqukKwk6dkHn9jXTNOo8R8Q@mail.gmail.com>
References: <CAP=kTZrZbkHC3RcmbBsh0sux6qYqqukKwk6dkHn9jXTNOo8R8Q@mail.gmail.com>
Message-ID: <4E6DF526.2000504@biblibre.com>

Le 12/09/2011 08:04, Koustubha Kale a ?crit :
> Hi All,
Hi Koustubha,
> My apologies for missing yet another meeting. I had an accident. Right
> arm ( my working arm ) bone & elbow broken. Had to be hospitalized and
> operated on. 
ouch... elbow broken can be a real problem for hand nerves. I hope
you'll recover quickly & fully !
> I had actually logged in for the meeting with my mobile & left thumb
> but I was overwhelmed by the medicines during the 3.4 discussion.
> Anyway I am home now with a couple of weeks compulsory rest.
I wish you the bests !
> Kohacon11 program as put up by Brooke here
> <http://wiki.koha-community.org/wiki/Kohacon2011> (
> http://wiki.koha-community.org/wiki/Kohacon2011 ) looks good. All
> ground preparations are in hand by VPM authorities. I have requested
> an additional hall/classroom may be made available in case we require
> it  to run parallel tracks.  
When will that be decided/organized ?
> I will communicate more details about the planned cultural program &
> dinner, planned one day Mumbai trip for 3rd November etc..
/me impatient to be in october !!!

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08


From ian.walls at bywatersolutions.com  Mon Sep 12 15:37:13 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Mon, 12 Sep 2011 09:37:13 -0400
Subject: [Koha-devel] Commentary on Paul's Koha 3.8 Release Manager
	proposal
In-Reply-To: <4E6DD1DD.6090302@biblibre.com>
References: <CAE2wdZwcbYEn+EGr54wJDy00__HEK1Hy6SN=LdXB7hFSv__FRw@mail.gmail.com>
	<4E6DD1DD.6090302@biblibre.com>
Message-ID: <CAE2wdZxkFj56N1a5=MGnu+4LZm9o=S8TShk4H0HZSCxdvOVk7g@mail.gmail.com>

Paul,


Yes, the main difference in our proposals is primarily one of timing.
You're proposing that we have Koha 4.0 ready in about 1 year, and will
include Solr integration and updated Perl coding practices.  Those are
certainly good things, yes, and they may well be possible in 1 year.  Or
they may not.

I agree that we should continue to do time-based releases; every 6 months
seems to be working well for us.  The difficulty here, though, is that with
time-based releases, you cannot guarantee that any given feature will be
ready in time.  Sure, any one development team can promise they'll have it
coded up to their clients standards and rebased for inclusion, but how will
that interact with other code written by other teams?  Who, outside the
original development team, can be committed to test and sign-off on the
work?

So, when working on time-based releases, you cannot promise features.  This
is why I propose we continue with time-based releases on the 3.X line until
such time as all the agreed-upon features for Koha 4.0 are ready.  If we're
quick, sure, we can jump straight from 3.8 to 4.0.  I think it's much more
likely we'll have a 3.10 in there, but maybe that's just me.

By no longer attempting to set a release date for a feature-based release,
we open ourselves up to more feature possibilities for Koha 4.0.  Solr and
updated Perl pratices are both very developer-centric improvements.  What
are the positive end results for the libraries?  I know with Solr, you can
more easily customize your facets.  Updated Perl coding could result in
faster performance.  I think it's more important to define our goals in
those terms, rather than in how we're going to accomplish them.

HDL pointed out early in the thread that some of the features I was floating
as possible for Koha 4.0 were librarian-centric, and some were
developer-centric.  He's right, I wasn't really clearly differentiating in
that list.  It was mostly meant as an example of what else would could
reasonably accomplish for the next major release of the software.

I don't think there will be nearly as many merge conflicts and rebase issues
as you fear, Paul.  Once we decide on our feature set, any interested
developers would meet to figure out the coding requirements.  This may take
several meetings, but in the end, we'll have a roadmap of what features
depend on what. A couple points of practice will make the development go
more smoothly:

   - Those that can be done first will be, which will then open the door for
   other features, and so on.
   - Developments for each feature are done on frequently-rebased topic
   branches.  Since we'll have identified them as a community, we can put them
   on the main Koha git repo.  We can give keys on a per-branch basis to the
   developers working most heavily on those branches.
   - Small, atomic, easily-tested patches are the key here.  If two features
   can both be developed concurrently, and they happen to tread on each others
   toes, this will keep any merge conflicts small and easily reconciled.

Whatever features are ready by the feature freeze for 3.8 would be what go
into 3.8; this is a matter of distribution and labeling, and won't affect
the developers who are all working on master (or it's closely-based feature
branches).  Release Maintainers will continue their job backporting fixes to
those stable branches we still support.

I really like the idea of having multiple sandboxes set up so that folks can
test the different features more easily.  We should definitely do this.
Having more people doing testing and Quality Assurance is always a good
thing.  Providing test plans, test results and reasons for passing/failing
QA on the bug report will make it much easier to keep track of the history
of any particular fix or feature.

Our end goal is the same:  make Koha the best it can be.  We're mostly
disagreeing over small details.  Whatever the outcome of this discussion, I
know we will all continue to work hard together to improve Koha.

Cheers,


-Ian



On Mon, Sep 12, 2011 at 5:33 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Le 07/09/2011 23:58, Ian Walls a ?crit :
> > Everyone,
> Hi Ian & everyone,
> > The major disagreement is with the timeline.  The proposal as it
> > stands is to start working on Koha 3.8 and Koha 4.0 in parallel, with
> > Koha 3.8 releasing April 2012, and Koha 4.0 releasing Oct. 2012.  I
> > feel that going from Koha 3.8 directly to 4.0 is unwarranted.  To my
> > mind, there are many possible releases between 3.8 and 4.0, like 3.10,
> > 3.12, 3.14 and so forth.  This is supported by the actual database
> > version numbers in Koha: the current release is actually 3.04.04; the
> > zeros are squashed out for convenience.
> I think our main (only ?) disagreement is based on some
> misunderstandings. I'll try to explain more clearly.
>
> Here is the timeline for Koha 3.8 :
> * starts 2011-11
> * feature freeze 2012-03
> * release 2012-04
>
> In my proposal, Koha 4.0 has the following timeline :
> * defining the strategy & the roadmap start 2011-11 and end in 2012-01
> (3 months)
> * hacking starts in 2012-02
> * feature freeze start in 2012-09
> * release 2012-10
>
> It means there will/can have a real hacking overlap of something like 2
> months (feb-march 2012)
>
> According to me, we could even start immediately to list everything
> we're dreaming of.
> The 2nd step being to evaluate how we can achieve each goal, who can
> endorse the needed work, which priority for what.
>
> Maybe another point of disagreement/misunderstanding is that you propose
> "a 4.0 with everything we want" while I propose "a 4.0 with everything
> that can fit in the 6 months timeline"
> We switched from Feature-based release to Time-based release, and I
> definitely don't want to change this. This has been a  major good
> decision we shouldn't change !
>
> My second rule is "if you change something important in the structure of
> Koha, 1st digit get a +1". [ With the change of templating system, we
> could have updated the version to 4.0 instead of 3.6, that would not
> have been a scandal (frenchism suspected...) ! ]
>
> It means that, for example, we decide that the priorities are (from
> biggest to lowest)
> 1- update indexing engine
> 2- enable database persistency
> 3- arbitrary metadata formats (beyond MARC)
> Step 1 and 2 have volunteers & code & ... => it will be in 4.0
> Step 3 doesn't have a volunteer => it will be in 5.0
> After 4.0 there will be a 4.2 or  a 5.0 depending on step 3 being ready.
>
> I like the idea of a roadmap, with the following chapters :
> Will be in version XX :
>  * feature A already merged
>  * feature B already merged
>  * ...
> Should be in version XX :
>  * feature C, patch submitted, being examinated
>
> Could be in version XX :
>  * feature D, announced by mail at people.com
>
> Have been submitted but rejected for instance :
>  * feature E, patch does not apply
>  * feature F, failed QA
>  * ...
>
> (doesn't eclipse have such a roadmap ? not sure)
>
> Should I conclude that the version number should be decided/defined when
> feature freeze reached ? Maybe, i'm not sure.
>
> About your idea of 3.10, 3.12,... I fear/feel that we can't afford
> managing the conflicts that will result :
> * "4.0" has database persistency merged, we still lack "indexing engine
> changes", so 4.0 has not been released
> * a patch to enable "arbitrary biblio relationships" is submitted for
> 3.x It will be totally incompatible with "4.0 still unreleased" and we
> have a problem...
> > One of my other issues with the proposal was the "lightening" of
> > Quality Assurance standards for the first 3 months of the 3.8 release
> > cycle.
> You've forgotten to specify i've written "how exactly, To Be Discussed".
> This is only a main concern I have expressed before : smoothen things.
> The idea of sandboxes to have more ppl testing will be a step in this
> direction. I'll also send regular mails to try to motivate ppl to
> test/sign-off. Maybe that will be enough. But maybe we could also accept
> a derivative workflow like "there are some experienced ppl that can
> decide to do sign-off and passed QA at the same time, they're
> experienced&wise enough to decide if a patch is small/trivial enough to
> be applied without a 2nd eye checking". Or ther(s) rule(s) we could
> discuss (I have a lot of suggestions I could/will do). My idea is not to
> lower the quality.
>
> Ian, thanks to continue this thread.
>
> --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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 at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110912/5f935017/attachment.htm>

From David.W.Hartman at disney.com  Mon Sep 12 19:30:37 2011
From: David.W.Hartman at disney.com (Hartman, David W. - GBTS Library)
Date: Mon, 12 Sep 2011 13:30:37 -0400
Subject: [Koha-devel] KohaAdminEmailAddress FW: User Request for update of
	Record.
In-Reply-To: <CAN6cLAX7cwiMqt_76gf5=5igfr2+vK2XaaBwVeyU68JWaP-rpA@mail.gmail.com>
References: <AcxvK8ubapFAiF8lQ1anh1o5iZ6OkgAAAABqAAAEtoAAACBdQA==>
	<3E19441498923443B9DBE2FE1C0E70B60443E69FE3@SM-FLOR-VXMB04B.wdw.disney.com>
	<CAN6cLAX7cwiMqt_76gf5=5igfr2+vK2XaaBwVeyU68JWaP-rpA@mail.gmail.com>
Message-ID: <3E19441498923443B9DBE2FE1C0E70B60443E6A034@SM-FLOR-VXMB04B.wdw.disney.com>


Thanks for your time .. I do not think this is directly an exchange issue.  I will keep this on the devel listserv.

But the question we need answered from the Koha side is why are both of those fields set to "david.w.hartman at disney.com<mailto:david.w.hartman at disney.com>". We don't see that in any of the configurations. The KohaAdminEmailAddress (like in the instructions below) is set to  a company email account - GBTS.LIBRARY at disney.com<mailto:GBTS.LIBRARY at disney.com> but the error is coming to my email address.   Make sense?

1.1.2.2.3. KohaAdminEmailAddress
This is the default 'From' address for emails unless there is one for the particular branch, and is referred to when an internal error occurs.
Asks: Use ___ as the email address for the administrator of Koha.
Description:

 *   This preference allows one email address to be used in warning messages set to the OPAC. If no email address is set for the branch this address will receive messages from patrons regarding modification requests, purchase suggestions, and questions or information regarding overdue notices. It is recommended that a email address that can be accessed by multiple staff members be used for this purpose so that if one librarian is out the others can address these requests. This email address can be changed when needed.



From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Fridolyn SOMERS
Sent: Monday, September 12, 2011 5:02 AM
To: koha-devel
Subject: Re: [Koha-devel] FW: User Request for update of Record.

Hie,

Seems to be an MS Exchange protection : "The recipient's e-mail address was not found in the recipient's e-mail system".
Look in Exchange forums i'd say.

Best regards,

--
Fridolyn SOMERS
ICT engineer
PROGILONE - Lyon - France
fridolyn.somers at gmail.com<mailto:fridolyn.somers at gmail.com>
2011/9/9 Hartman, David W. - GBTS Library <David.W.Hartman at disney.com<mailto:David.W.Hartman at disney.com>>
I am getting this error message when I try to send admin notices.  Can anyone help?

_____________________________________________
From: postmaster at int1.disney.pvt [mailto:postmaster at int1.disney.pvt]
Sent: Friday, September 09, 2011 4:05 PM
To: Hartman, David W. - GBTS Library
Subject: Undeliverable: User Request for update of Record.


Delivery has failed to these recipients or distribution lists:

david.w.hartman at disney.com<mailto:david.w.hartman at disney.com>

NOTE: If you are sending a message to an ESPN employee and using Outlook 2007 on a PC, click the To: field and click on the name in the Global Address List to add it. Then click OK.

The recipient's e-mail address was not found in the recipient's e-mail system. Exchange will not try to redeliver this message for you. Please check the e-mail address and try resending this message, or provide the following diagnostic text to your system administrator.


Diagnostic information for administrators:

Generating server: int1.disney.pvt

david.w.hartman at disney.com<mailto:david.w.hartman at disney.com>
#< #5.1.1> #SMTP#

Original message headers:

Received: from WW-R-ITLWDW1K5M.wdw.disney.com<http://WW-R-ITLWDW1K5M.wdw.disney.com> ([ww-r-itlwdw1k5m.wdw.disney.com<http://ww-r-itlwdw1k5m.wdw.disney.com>
 [172.16.190.240]]) by int11.disney.pvt with ESMTP id p89K51ud009424 ;
          Fri, 9 Sep 2011 20:05:01 +0000
Received: from WW-R-ITLWDW1K5M.wdw.disney.com<http://WW-R-ITLWDW1K5M.wdw.disney.com> (WW-R-ITLWDW1K5M.wdw.disney.com<http://WW-R-ITLWDW1K5M.wdw.disney.com> [127.0.0.1])
        by WW-R-ITLWDW1K5M.wdw.disney.com<http://WW-R-ITLWDW1K5M.wdw.disney.com> (Postfix) with ESMTP id B7CF63DAAD
        for <david.w.hartman at disney.com<mailto:david.w.hartman at disney.com>>; Fri,  9 Sep 2011 16:03:34 -0400 (EDT)
Subject: User Request for update of Record.
Date: Fri, 9 Sep 2011 16:03:34 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf8"
To: <david.w.hartman at disney.com<mailto:david.w.hartman at disney.com>>
Content-Transfer-Encoding: quoted-printable
From: <david.w.hartman at disney.com<mailto:david.w.hartman at disney.com>>
Message-ID: <20110909200334.B7CF63DAAD at WW-R-ITLWDW1K5M.wdw.disney.com<mailto:20110909200334.B7CF63DAAD at WW-R-ITLWDW1K5M.wdw.disney.com>>


_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org<mailto:Koha-devel at 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/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110912/4ae077c6/attachment-0001.htm>

From David.W.Hartman at disney.com  Mon Sep 12 21:02:05 2011
From: David.W.Hartman at disney.com (Hartman, David W. - GBTS Library)
Date: Mon, 12 Sep 2011 15:02:05 -0400
Subject: [Koha-devel] Recall: KohaAdminEmailAddress FW: User Request for
 update of Record.
Message-ID: <3E19441498923443B9DBE2FE1C0E70B60443E6A049@SM-FLOR-VXMB04B.wdw.disney.com>

Hartman, David W. - GBTS Library would like to recall the message, "KohaAdminEmailAddress   FW: User Request for update of Record.".

From chrisc at catalyst.net.nz  Tue Sep 13 05:05:09 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Tue, 13 Sep 2011 15:05:09 +1200
Subject: [Koha-devel] Database Schema
Message-ID: <20110913030509.GP23576@rorohiko.wgtn.cat-it.co.nz>

Hi All

For everyone who writes reports, or develops on Koha, we have a new
site available to help.

http://schema.koha-community.org/

This, combined with the work Nicole has been doing to add comments
allows for nice information like this
http://schema.koha-community.org/tables/biblio.html

It is up to date with master (what will be 3.6.0 on October 22), and
will continue to track master thereafter.

Thanks to Robin for rediscovering SchemaSpy and to Nicole for adding
comments.

Chris
-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20110913/c00ed3a6/attachment.pgp>

From paul.poulain at biblibre.com  Tue Sep 13 10:16:58 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 13 Sep 2011 10:16:58 +0200
Subject: [Koha-devel] Database Schema
In-Reply-To: <20110913030509.GP23576@rorohiko.wgtn.cat-it.co.nz>
References: <20110913030509.GP23576@rorohiko.wgtn.cat-it.co.nz>
Message-ID: <4E6F117A.9040303@biblibre.com>

Le 13/09/2011 05:05, Chris Cormack a ?crit :
> Hi All
>
> For everyone who writes reports, or develops on Koha, we have a new
> site available to help.
>
> http://schema.koha-community.org/
Wonderful !

I've added the link on the wiki DB schema page
Could we imagine to "freeze" schema on each release ? Thus, a library
with Koha 3.4 could check schema3.4.koha-community.org and a library
with 3.6 could check schema3.6.koha-community.org ? That would be handy
I think.

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08


From chrisc at catalyst.net.nz  Tue Sep 13 10:26:16 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Tue, 13 Sep 2011 20:26:16 +1200
Subject: [Koha-devel] Database Schema
In-Reply-To: <4E6F117A.9040303@biblibre.com>
References: <20110913030509.GP23576@rorohiko.wgtn.cat-it.co.nz>
	<4E6F117A.9040303@biblibre.com>
Message-ID: <20110913082616.GT23576@rorohiko.wgtn.cat-it.co.nz>

* Paul Poulain (paul.poulain at biblibre.com) wrote:
> Le 13/09/2011 05:05, Chris Cormack a ?crit :
> > Hi All
> >
> > For everyone who writes reports, or develops on Koha, we have a new
> > site available to help.
> >
> > http://schema.koha-community.org/
> Wonderful !
> 
> I've added the link on the wiki DB schema page
> Could we imagine to "freeze" schema on each release ? Thus, a library
> with Koha 3.4 could check schema3.4.koha-community.org and a library
> with 3.6 could check schema3.6.koha-community.org ? That would be handy
> I think.
> 
Yep, I could easily generate 
schema.koha-community.org/3.4.x/ 
schema.koha-community.org/3.6.x/
schema.koha-community.org/master/

etc

Currently the comments are only on master, but so from 3.6.0 onwards
the schema will be more useful.

Chris
-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20110913/26ebdad4/attachment.pgp>

From David.W.Hartman at disney.com  Tue Sep 13 22:34:54 2011
From: David.W.Hartman at disney.com (Hartman, David W. - GBTS Library)
Date: Tue, 13 Sep 2011 16:34:54 -0400
Subject: [Koha-devel] KohaAdminEmailAddress error - Koha 3.05
Message-ID: <3E19441498923443B9DBE2FE1C0E70B60443E6A0C2@SM-FLOR-VXMB04B.wdw.disney.com>

For sending emails .... Is there a way to make the To: and From: addresses different in the auto generated messages?   I am getting error messages that we are sending to and from the same address.

It looks like koha is using the admin address (KohaAdminEmailAddress) for both.

I am wondering if there is a configuration setting we are missing.


David W. Hartman
Global Business Technology Strategy Library



-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110913/09501566/attachment.htm>

From lrea at nekls.org  Tue Sep 13 23:57:38 2011
From: lrea at nekls.org (Liz Rea)
Date: Tue, 13 Sep 2011 16:57:38 -0500
Subject: [Koha-devel] KohaAdminEmailAddress error - Koha 3.05
In-Reply-To: <3E19441498923443B9DBE2FE1C0E70B60443E6A0C2@SM-FLOR-VXMB04B.wdw.disney.com>
References: <3E19441498923443B9DBE2FE1C0E70B60443E6A0C2@SM-FLOR-VXMB04B.wdw.disney.com>
Message-ID: <A0A4ABF8-3F4E-4839-B801-506FEAC278A8@nekls.org>

Well, this is just a guess, so sorry if I'm way off here.

Are these messages patron update emails? I wonder if you're testing the patron update notification with an account that has the same email address as your admin user, thus it *looks* like the to and from are the same. What's really happening, I think (totally not sure! At all!) is that it's sending the notice FROM the patron's user entered address, TO the koha admin email, which happen to be the same.

Plausible?

Liz Rea
lrea at nekls.org



On Sep 13, 2011, at 3:34 PM, Hartman, David W. - GBTS Library wrote:

> For sending emails ?. Is there a way to make the To: and From: addresses different in the auto generated messages?   I am getting error messages that we are sending to and from the same address. 
>  
> It looks like koha is using the admin address (KohaAdminEmailAddress) for both.
>  
> I am wondering if there is a configuration setting we are missing.
>  
>  
> David W. Hartman 
> Global Business Technology Strategy Library 
> 
> 
>  
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110913/3abc95af/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: email_signature.jpeg
Type: image/jpeg
Size: 4862 bytes
Desc: not available
URL: </pipermail/koha-devel/attachments/20110913/3abc95af/attachment.jpeg>

From David.W.Hartman at disney.com  Wed Sep 14 00:08:28 2011
From: David.W.Hartman at disney.com (Hartman, David W. - GBTS Library)
Date: Tue, 13 Sep 2011 18:08:28 -0400
Subject: [Koha-devel] KohaAdminEmailAddress error - Koha 3.05
In-Reply-To: <A0A4ABF8-3F4E-4839-B801-506FEAC278A8@nekls.org>
References: <3E19441498923443B9DBE2FE1C0E70B60443E6A0C2@SM-FLOR-VXMB04B.wdw.disney.com>
	<A0A4ABF8-3F4E-4839-B801-506FEAC278A8@nekls.org>
Message-ID: <3610358C-5CCC-4123-B1E8-86CE07026E80@email.disney.com>

Thanks for the reply. :)  i dont think thats it.  The kohaadmin email we are using is a library email address and the user record was a non- library related individual user.

Keep the thoughts coming! This is the last hurdle then I won't be bugging y'all ... And maybe I can help someone!

Sent from my iPhone! Pardon typos, etc.


On Sep 13, 2011, at 5:57 PM, "Liz Rea" <lrea at nekls.org<mailto:lrea at nekls.org>> wrote:

Well, this is just a guess, so sorry if I'm way off here.

Are these messages patron update emails? I wonder if you're testing the patron update notification with an account that has the same email address as your admin user, thus it *looks* like the to and from are the same. What's really happening, I think (totally not sure! At all!) is that it's sending the notice FROM the patron's user entered address, TO the koha admin email, which happen to be the same.

Plausible?

Liz Rea
<mailto:lrea at nekls.org>lrea at nekls.org<mailto:lrea at nekls.org>

<email_signature.jpeg>

On Sep 13, 2011, at 3:34 PM, Hartman, David W. - GBTS Library wrote:

For sending emails ?. Is there a way to make the To: and From: addresses different in the auto generated messages?   I am getting error messages that we are sending to and from the same address.

It looks like koha is using the admin address (KohaAdminEmailAddress) for both.

I am wondering if there is a configuration setting we are missing.


David W. Hartman
Global Business Technology Strategy Library



_______________________________________________
Koha-devel mailing list
<mailto:Koha-devel at lists.koha-community.org>Koha-devel at lists.koha-community.org<mailto:Koha-devel at lists.koha-community.org>
<http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel>http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : <http://www.koha-community.org/> http://www.koha-community.org/
git : <http://git.koha-community.org/> http://git.koha-community.org/
bugs : <http://bugs.koha-community.org/> http://bugs.koha-community.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110913/134ca7fa/attachment-0001.htm>

From paul.poulain at biblibre.com  Wed Sep 14 11:46:12 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 14 Sep 2011 11:46:12 +0200
Subject: [Koha-devel] Restructuring C4
In-Reply-To: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>
Message-ID: <4E7077E4.4000306@biblibre.com>

Le 30/03/2011 16:47, Ian Walls a ?crit :
> Fellow Developers,
>
> It seems that much of the time spent running circ/circulation.pl
> <http://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 <http://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
Ian, where do you see the number of BEGINs and the time spent on it ? I
can't find it on NYTProf report.

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08


From tdavis at uttyler.edu  Wed Sep 14 17:49:53 2011
From: tdavis at uttyler.edu (Elliott Davis)
Date: Wed, 14 Sep 2011 10:49:53 -0500
Subject: [Koha-devel] Notices/Overdues Meeting Reminder
Message-ID: <8754F6E19960C249BB9C8FFECA627740015426E9E5@dogbert>

Hi All,

I'd just like to remind you that there will be an IRC meeting tomorrow September 15, 2011 at 1800 UTC.  Feel free to visit the wiki<http://wiki.koha-community.org/wiki/Notifications_RFC> and see what we have currently laid out.

Best Regards,

Elliott Davis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110914/9422a5b6/attachment.htm>

From lrea at nekls.org  Wed Sep 14 22:27:15 2011
From: lrea at nekls.org (Liz Rea)
Date: Wed, 14 Sep 2011 15:27:15 -0500
Subject: [Koha-devel] KohaAdminEmailAddress error - Koha 3.05
In-Reply-To: <3610358C-5CCC-4123-B1E8-86CE07026E80@email.disney.com>
References: <3E19441498923443B9DBE2FE1C0E70B60443E6A0C2@SM-FLOR-VXMB04B.wdw.disney.com>
	<A0A4ABF8-3F4E-4839-B801-506FEAC278A8@nekls.org>
	<3610358C-5CCC-4123-B1E8-86CE07026E80@email.disney.com>
Message-ID: <4E2494E5-247D-4731-82F0-77D757F82449@nekls.org>

After a bit of back and forth, I believe Mr. Hartman discovered a bug (or at least a limitation) in the patron update script.

I went ahead and filed bug 6870 on his behalf, and submitted a patch for it that may help with his issue. Woohoo!

Liz Rea
lrea at nekls.org



On Sep 13, 2011, at 5:08 PM, Hartman, David W. - GBTS Library wrote:

> Thanks for the reply. :)  i dont think thats it.  The kohaadmin email we are using is a library email address and the user record was a non- library related individual user. 
> 
> Keep the thoughts coming! This is the last hurdle then I won't be bugging y'all ... And maybe I can help someone! 
> 
> Sent from my iPhone! Pardon typos, etc.
> 
> 
> On Sep 13, 2011, at 5:57 PM, "Liz Rea" <lrea at nekls.org> wrote:
> 
>> Well, this is just a guess, so sorry if I'm way off here.
>> 
>> Are these messages patron update emails? I wonder if you're testing the patron update notification with an account that has the same email address as your admin user, thus it *looks* like the to and from are the same. What's really happening, I think (totally not sure! At all!) is that it's sending the notice FROM the patron's user entered address, TO the koha admin email, which happen to be the same.
>> 
>> Plausible?
>> 
>> Liz Rea
>> lrea at nekls.org
>> 
>> <email_signature.jpeg>
>> 
>> On Sep 13, 2011, at 3:34 PM, Hartman, David W. - GBTS Library wrote:
>> 
>>> For sending emails ?. Is there a way to make the To: and From: addresses different in the auto generated messages?   I am getting error messages that we are sending to and from the same address. 
>>>  
>>> It looks like koha is using the admin address (KohaAdminEmailAddress) for both.
>>>  
>>> I am wondering if there is a configuration setting we are missing.
>>>  
>>>  
>>> David W. Hartman 
>>> Global Business Technology Strategy Library 
>>> 
>>> 
>>>  
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at 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/
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110914/1e6d7086/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: email_signature.jpeg
Type: image/jpeg
Size: 4862 bytes
Desc: not available
URL: </pipermail/koha-devel/attachments/20110914/1e6d7086/attachment.jpeg>

From paul.poulain at biblibre.com  Wed Sep 14 22:54:51 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 14 Sep 2011 22:54:51 +0200
Subject: [Koha-devel] Restructuring C4
In-Reply-To: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>
Message-ID: <4E71149B.70009@biblibre.com>

(this mail has been sent 10 hours ago, seems it was too large. I send it
again without attached docs)

Le 30/03/2011 16:47, Ian Walls a ?crit :
> Fellow Developers,
Hello everybody,
> Last night, I stayed up late running circ/circulation.pl
> <http://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.

For those who have used or developed on Koha 2.x, you probably have
noticed that Koha 2.x was much more slower than Koha 3.x
So, yesterday and tonight i've taken my laptop and made a lot of testings.

First of all, i'll thank forever ... The New York Times ... Why will you
tell me ? Because of
http://search.cpan.org/~adamk/Aspect-Library-NYTProf-1.00/lib/Aspect/Library/NYTProf.pm

This tool is really amazing. You run
perl -d:NYTProf mainpage.pl ; nytprofhtml --open
And you get a highly detailled HTML report with the time spent in each
line/sub/module to run mainpage.pl.
Here is the result :  http://depot.biblibre.com/ppoulain/nytprof.ini/
(the .ini is to keep track of the perf before anything optimized)

Note : tests done on my laptop, that is not a server.
1st test with master:
Profile of mainpage.pl for 1.73s (of 2.18s), executing 155108 statements
and 41041 subroutine calls in 249 source files and 64 string evals.

I have investigated to find the longest timings & if we can do something.
(note All the following improvement have been done incrementally)

First of all, C4::Context and C4::Koha are loaded on everypage, so it's
worth investigating

== C4::Context ==
* spent 185ms just reading the config file. Ouch ! that's almost 10% of
the time !!!
(http://depot.biblibre.com/ppoulain/nytprof.ini/C4-Context-pm-13-line.html#230)
I tried to hardcode the hashref instead of XMLin-ing the config file,
the results are astonishing :
after = Profile of mainpage.pl for 1.59s (of 1.93s), executing 117399
statements and 26939 subroutine calls in 241 source files and 63 string
evals.
=> PROPOSAL = add a YAML version of the XML config file that we could
use in //
=> PROPOSAL 2 = memcache the config file
(hint : the config file in koha 2 was not xml !)

* C4::Context, sub db_scheme2dbi, the i flag in /mysql/i cost 84ms !!!
with /i, the duration is 84.4ms, without, it's 10?s !!!
after = Profile of mainpage.pl for 1.55s (of 1.91s), executing 117398
statements and 26938 subroutine calls in 241 source files and 63 string
evals.
=> PROPOSAL = just 'return "mysql"' at the beginning of this sub, as
everything else is not working anyway !

== C4::Languages ==
* C4::Languages::getAllLanguages 43ms => heavily under optimized mysql
query = returns all languages from language_subtag_registry and
language_descriptions even if only a few localisations are installed.
* C4::Languages::_build_languages_arrayref 15ms => same as for
getAllLanguages
I know there is a patch (from hdl) pending to improve this sub, i
haven't tested it yet
(http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6000)
(hint : this sub appeared in 3.0, was not in 2.2 !)

== Other packages ==
* C4::Koha.pm 15ms for use Business::ISBN, that is used only in 1 sub
used only in a few pages (and none if no cover images are enabled unless
i'm wrong)
* C4::Letters use MIME::Lite spend 26ms, that are useless 90% of the
time (why is C4::Letters loaded ! answer = because C4::Reserves is
loaded by Items.pm that is loaded by Biblio.pm that is loaded by
AuthoritiesMarc.pm that is loaded (uselessly) by mainpage.pl
* CGI/Session/Driver/mysql.pm needs 79ms i've tested by switching to
driver::File::Serializer (dropped to 21ms). this seems to work, but
probably requires more testing than what I did
* Date::Manip needs requires 46ms and is useless most of the time.
after = Profile of mainpage.pl for 1.31s (of 1.60s), executing 103643
statements and 25380 subroutine calls in 215 source files and 55 string
evals.
=> PROPOSAL = WHERE it's interesting we could replace the use XXXX by a
require XXXX just before the lines that need the package. The require is
loaded at run tim, so, when unneeded, the package won't be loaded

== mainpage.pl ==
Mainpage.pl load some authorities, we do nothing with it. Commenting the
use C4::Authorities and all related code results in:
after = Profile of mainpage.pl for 1.27s (of 1.57s), executing 103000
statements and 25194 subroutine calls in 212 source files and 55 string
evals.

== Packages nested ==
* I also noticed that Auth.pm loads Members.pm (to retrieve patron
informations and display them on the top right). Members.pm loads
Reserves that loads Biblio.pm, Circulation.pm and Items.pm All those
packages are the biggest to load.
I've written a script, that display, for each file in C4 which package
is loaded and which sub in the package loaded are used. It shows, for
example, that there is a "use Koha.pm;" that is useless in
AuthoritiesMarc.pm It also shows which sub are used, and how many times.
For example, Circulation.pm calls "use C4::Biblio" and :
        In Circulation.pm the Biblio.pm, sub GetBiblioItemData is used 1
times
        In Circulation.pm the Biblio.pm, sub GetBiblioFromItemNumber is
used 4 times
That will be handy to find what can be cleaned & removed.

I've attached the script and the result. If you want to run it yourself,
just export PERL5LIB, KOHA_CONF, put the script in $KOHA directory, and
run it !

== Other ==
* packages that uses the biggest amount of CPU are not C4 packages :
  * utf8_heavy-pl is the most cpu consuming thing : 132ms, I don't know
if we can do something
  * Template::Parser needs 123ms, not sure we can do something
  * all XML stuff is highly consuming = loading MARC::File::XML requires
47ms in Biblio.pm, XML::Sax::Base require 40ms to be loaded
=> definetly, the best way to reduce CPU time is by pre-loading things,
we already knew that

== Next step ==
* i'll file a bug for the various improvements that can be made easily
* i'll continue investigate & report my findings
I'm aware it's a 1st step, and the long-term road is to reach data&code
persistency. But cleaning what we already have may ease the next big
step. And any speed improvement is a good thing, isn't it !

HTH

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08
-------------- section suivante --------------
Une pi?ce jointe autre que texte a ?t? nettoy?e...
Nom: check_subs.pl
Type: application/x-perl-module
Taille: 3072 octets
Desc: non disponible
URL: </pipermail/koha-devel/attachments/20110914/d0a24a31/attachment-0001.bin>

From chris at bigballofwax.co.nz  Wed Sep 14 22:59:21 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Thu, 15 Sep 2011 08:59:21 +1200
Subject: [Koha-devel] Restructuring C4
In-Reply-To: <4E71149B.70009@biblibre.com>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>
	<4E71149B.70009@biblibre.com>
Message-ID: <CA+95qVS2m9McL2n2JG56QgBC44u7+0fc90wTY8CErQWD3_HMjw@mail.gmail.com>

Hi Paul

Good email, just a couple of comments inline.

2011/9/15 Paul Poulain <paul.poulain at biblibre.com>:
> (this mail has been sent 10 hours ago, seems it was too large. I send it
> again without attached docs)
>
> Le 30/03/2011 16:47, Ian Walls a ?crit :
>> Fellow Developers,
> Hello everybody,
>> Last night, I stayed up late running circ/circulation.pl
>> <http://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.
>
> For those who have used or developed on Koha 2.x, you probably have
> noticed that Koha 2.x was much more slower than Koha 3.x
> So, yesterday and tonight i've taken my laptop and made a lot of testings.
>
> First of all, i'll thank forever ... The New York Times ... Why will you
> tell me ? Because of
> http://search.cpan.org/~adamk/Aspect-Library-NYTProf-1.00/lib/Aspect/Library/NYTProf.pm
>
> This tool is really amazing. You run
> perl -d:NYTProf mainpage.pl ; nytprofhtml --open
> And you get a highly detailled HTML report with the time spent in each
> line/sub/module to run mainpage.pl.
> Here is the result : ?http://depot.biblibre.com/ppoulain/nytprof.ini/
> (the .ini is to keep track of the perf before anything optimized)
>
> Note : tests done on my laptop, that is not a server.
> 1st test with master:
> Profile of mainpage.pl for 1.73s (of 2.18s), executing 155108 statements
> and 41041 subroutine calls in 249 source files and 64 string evals.
>
> I have investigated to find the longest timings & if we can do something.
> (note All the following improvement have been done incrementally)
>
> First of all, C4::Context and C4::Koha are loaded on everypage, so it's
> worth investigating
>
> == C4::Context ==
> * spent 185ms just reading the config file. Ouch ! that's almost 10% of
> the time !!!
> (http://depot.biblibre.com/ppoulain/nytprof.ini/C4-Context-pm-13-line.html#230)
> I tried to hardcode the hashref instead of XMLin-ing the config file,
> the results are astonishing :
> after = Profile of mainpage.pl for 1.59s (of 1.93s), executing 117399
> statements and 26939 subroutine calls in 241 source files and 63 string
> evals.
> => PROPOSAL = add a YAML version of the XML config file that we could
> use in //
> => PROPOSAL 2 = memcache the config file
> (hint : the config file in koha 2 was not xml !)
>

Done already
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6193

Some more testing on this, so I can push it would be much appreciated.

> * C4::Context, sub db_scheme2dbi, the i flag in /mysql/i cost 84ms !!!
> with /i, the duration is 84.4ms, without, it's 10?s !!!
> after = Profile of mainpage.pl for 1.55s (of 1.91s), executing 117398
> statements and 26938 subroutine calls in 241 source files and 63 string
> evals.
> => PROPOSAL = just 'return "mysql"' at the beginning of this sub, as
> everything else is not working anyway !
>
> == C4::Languages ==
> * C4::Languages::getAllLanguages 43ms => heavily under optimized mysql
> query = returns all languages from language_subtag_registry and
> language_descriptions even if only a few localisations are installed.
> * C4::Languages::_build_languages_arrayref 15ms => same as for
> getAllLanguages
> I know there is a patch (from hdl) pending to improve this sub, i
> haven't tested it yet
> (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6000)
> (hint : this sub appeared in 3.0, was not in 2.2 !)

These are cached by memoize_memcached if you are running it, I
strongly suggest people do

Chris

From paul.poulain at biblibre.com  Wed Sep 14 23:27:16 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 14 Sep 2011 23:27:16 +0200
Subject: [Koha-devel] Restructuring C4 (work continued)
In-Reply-To: <4E71149B.70009@biblibre.com>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>
	<4E71149B.70009@biblibre.com>
Message-ID: <4E711C34.4000804@biblibre.com>

Hi,

I've continued my work in the train, here is a result of my work.

I've checked a lot of the packages in C4 and checked for dependancies
(sub packages used)
With the check_subs.pl script, it was quite easy to find which subs were
called and see if it's needed.

What I propose next is to file a bug for each package with my findings
and my suggestions. Then, write a patch.
I also plan to investigate some of the most used pages (like
circ/circulation.pl, circ/return.pl, detail.pl, and most opac pages.
Note that the check_subs can be also use to check package dependancies
for perl scripts as well: on line 39, set "dirToCheck" to the directory
you want to check. I've checked circ and opac, and have already
discovered some interesting informations.
If you have some comment, want to make another suggestion or give a
hand, you're welcomed ;-)

mainpage.pl loads the following .pm
==== C4::Auth.pm ====
  == use Members.pm ==
    only to call GetMemberDetails and fill USER_INFO parameters
    USER_INFOS are used in a large variety of place.
    * In a strange way, like in : acqui/acqui-home.pl:   
$template->{VARS}->{'USER_INFO'}[0]->{'borrowernumber'} );
    Q: don't we have another way to retrieve loggedin librarian number ?
    * in opac-reserve, to display who we place a request for. Again,
this could/should be moved to opac-reserve, and we use GetMemberDetails
in this sub
   
    CONCLUSION = we should be able to get rid of use Members.pm in Auth.pm
  == use C4::Context.pm ==
    package that can't be avoided and loads nothing specific
  == use C4::Output.pm ==
    = use C4::Budgets =
    just to call Budget::GetCurrency in the Output::FormatNumber sub.
The Output::FormatNumber sub is used only in a few places, related to
C4::Budgets
    CONCLUTION => move FormatNumber outside from C4::Output into
C4::Budgets and we will get rid of this dependancy
    = use C4::Languages =
    to call a lot of sub here, no possibility to do something
    = use C4::Dates =
    to call format_date, in Date::FormatDate in C4::Output::FormatData
sub that is called only in aqbudgetperiod.pl and should easily be
removed. it contains only
            $$data_hashref{$_} = format_date( $$data_hashref{$_} ) for
grep{/date/} keys (%$data_hashref);
    that can be inlined in aqbudgetperiod (and it would be better to use
the OOo date tools)
    = use C4::Templates =
    needed, it's the package that smoothen the transition between
H::T::P and T::T
   
  == use C4::Branch ==
    = use C4::Koha = just to call get_infos_of once, we could get rid
with this sub by inlining and remove the C4::Koha dependancy

  == use C4::VirtualShelves ==
    * this package is needed in case of an OPAC query (on every opac
page we display the public & private lists). I suspect it's not needed
in staff interface. Anyone to confirm/argue ?
    * We use only GetRecentShelves sub,
    * we put everything in the session (set_shelves_userenv) & context
($session->param('barshelves', $barshelves);) I think there is no use
for this. Anyone to confirm/argue ?
    *  also note that the following line
            my ($total, $pubshelves) =
C4::Context->get_shelves_userenv();  # an anonymous user has no
'barshelves'...
            (C4::Auth, line 301 and the following) seems strange.
    = use C4::Circulation =
        and that's the beginning of circular-painfull-loading-everything.
        In C4::VirtualShelves, there is no use of anything from
C4::Circulation. I've commented the line, made a lot of tests, and saw
no problem at all.
       
==== C4::Koha ====
  This loading is useless. I've commented the line and saw no problem.
 
==== C4::AuthoritiesMarc; ====
This part is useless here, we do nothing with the authorities retrieved.

==== C4::NewsChannels ====
  == use C4::Context ==
  nothing to say, needed to access the database
  == use C4::Dates ==
  nothing to say, needed to format the date the news has been published.

<<<< END OF mainpage specifics >>>>
Continued to check some of the major .pm

==== Member.pm ====
Member.pm, (that is loaded by Auth.pm at the moment) load the following
packages:
    == use Reserves.pm ==
        Reserves.pm is used only to call
            my @itemswaiting =
C4::Reserves::GetReservesFromBorrowernumber(
$patroninformation->{'borrowernumber'},'W' );
        in C4::Members::patronflags sub
        I'm not sure we do anything with the result of
GetReservesFromBorrowernumber:
        C4::Members, line 518 contains :
            my @itemswaiting =
C4::Reserves::GetReservesFromBorrowernumber(
$patroninformation->{'borrowernumber'},'W' );
            my $nowaiting = scalar @itemswaiting;
            if ( $nowaiting > 0 ) {
                my %flaginfo;
                $flaginfo{'message'}  = "Reserved items available";
                $flaginfo{'itemlist'} = \@itemswaiting;
                $flags{'WAITING'}     = \%flaginfo;
            }
            return ( \%flags );
        I've some doubts about the need for this code, i've commented
it, placed a hold, make it waiting for pickup, I see everything as
usual, I saw no difference. It will be worth a bug entry and a patch to
test soon !
       
        I've moved the use C4::Members to a require C4::Member just
before the GetReservesFromBorrowernumber call
            NYTProf before commenting :
            Profile of mainpage.pl for 1.24s (of 1.54s), executing
102597 statements and 25016 subroutine calls in 212 source files and 55
string evals.
            NYTProf after commenting :
            Profile of mainpage.pl for 1.25s (of 1.55s), executing
102489 statements and 24984 subroutine calls in 212 source files and 55
string evals.
            (the duration is strange. But I was with my laptop on the
battery, so that may explain. The number of statements&subroutines are
lowered though)

    == use C4::Overdues.pm ==
      this is loaded only to call checkoverdues in
C4::Members::GetMemberDetails
      The result is stored in the big member detail hash returned :
            my ( $odues, $itemsoverdue ) =
checkoverdues($patroninformation->{'borrowernumber'});
            if ( $odues && $odues > 0 ) {
                my %flaginfo;
                $flaginfo{'message'}  = "Yes";
                $flaginfo{'itemlist'} = $itemsoverdue;
                foreach ( sort { $a->{'date_due'} cmp $b->{'date_due'} }
                    @$itemsoverdue )
                {
                    $flaginfo{'itemlisttext'} .=
                      "$_->{'date_due'} $_->{'barcode'} $_->{'title'}
\n";  # newline is display layer
                }
                $flags{'ODUES'} = \%flaginfo;
        It's used only in circulation.pl, return.pl and SIP.pm
        My opinion is that we could have a dedicated sub for that in
Circulation.pm (that is always loaded in circulation.pl & return.pl),
        retrieve the result from here when needed and reduce the size of
GetMemberDetails (that would not return everything)
       
    == use C4::Biblio.pm ==
      this is loaded just to call C4::Biblio::GetBiblioFromItemNumber in
C4::Members::GetMemberAccountRecords to retrieve title and author
      This can be easily circumvented with a correct LEFT join a few
lines before.
      Instead of
          SELECT *
            FROM accountlines
            WHERE borrowernumber
      write :
      SELECT accountlines.*,biblio.title,biblio.author FROM accountlines
LEFT JOIN items USING(itemnumber) LEFT JOIN biblio USING(biblionumber)
WHERE borrowernumber
      The use C4::Biblio can be removed !
    == use C4::Account.pm ==
      this is loaded to call manualinvoice twice.
      the manualinvoice is used only when adding or renewing a patron.
So it should be efficient to move from a use C4::Account to a require
C4::Account where applicable

==== Accounts.pm ====
    == use C4::Stats ==
    this package contains only one sub (updatestats) and no dependancies
    == use C4::Members ==
    loaded just to call C4::Members::GetMember once in the
C4::Accounts::returnlost sub.
    This sub seems totally unused in Koha (dead code)
    grep -R "returnlost" * shows only the sub header itself. Could be
removed.
    == use C4::Items ==
    loaded to call ModItem twice.
    The 1st call is in C4::Accounts::returnlost, that can be removed
(see below)
    The 2nd call is in C4::Accounts::chargelostitem, that is rarely
used. Switching to require C4::Items should be possible
    == use C4::Circulation ==
    This loading is similar to C4::Items with
C4::Circulation::MarkIssueReturned sub :
    The 1st call is in C4::Accounts::returnlost, that can be removed
(see below)
    The 2nd call is in C4::Accounts::chargelostitem, that is rarely
used. Switching to require C4::Circulation should be possible

==== Acquisition.pm ====
    There is a use Debug.pm that is useless in Acquisition.pm
    There is a use Biblio.pm that is useless in Acquisition.pm
    use C4::Debug is written twice !
    == use C4::Suggestions ==
      the ModSuggestion and GetSuggestionFromBiblionumber are called
when an order is recieved. Could switch to require, both statements are
close

==== Biblio.pm ====
      == use C4::Serials ==
      Serials.pm is loaded to delete subscriptions in
C4::Biblio::DelBiblio. 2 subs are used :
C4::Serials::GetFullSubscriptionsFromBiblionumber and
C4::Serials::DelSubscription
      both can be moved to require at the right place
      == use C4::Items ==
      * the check_subs script wrongly report a use of ModItem and
DelItem, it's a comment in the code :
          # duplication or incorrect data - use AddItem() or ModItem()
      * C4::Biblio uses C4::Items::GetMarcItem twice
        * once in PrepareItemrecordDisplay => this sub sounds at a wrong
place. It could/should be moved to C4::Items itself.
PrepareItemrecordDisplay is used by:
          * acqui/addorderiso2709.pl = already loads C4::Items
          * acqui/neworderempty.pl = don't load C4::Items for instance
          * acqui/orderreceive.pl = already loads C4::Items
          * C4/Serials.pm = need more investigation
          * serials/serials-edit.pl = already loads C4::Items
        * once in C4::Biblio::EmbedItemsInMarcBiblio
          Could we remove this sub ? question still pending. it's used
only in:
            * C4::Biblio::GetMarcBiblio
            * misc/migration_tools/rebuild_zebra.pl
            * tools/export.pl

==== Items.pm ====
    == use C4::Biblio ==
    Too many things are required, we can't change. The best solution
would be to remove C4::Items reference in C4::Biblio
GetOrderFromItemnumber   
    == use C4::Reserves ==
    This package is loaded just for C4::Reserves::CheckReserves called
in C4::Items::GetItemsInfo
    The GetItemsInfo stores the result of CheckReserves in a hash entry,
count_reserve, that is used only in opac_detail to display the status of
a hold. We could remove the reserve_count hash entry and inline
C4::Reserves::CheckReserves directly from opac-detail.pl page
    in opac-detail.pl, instead of
    if( $itm->{'count_reserves'} eq "Waiting"){ $itm->{'waiting'} = 1; }
    write :
    if ( C4::Reserves::CheckReserves(<<parameters>>) eq "Waiting"){
$itm->{'waiting'} = 1; }
   
    == use C4::Acquisition ==
    This package is loaded to call
    * C4::Acquisition::ModOrder = recent addition, when you move an item
to another biblio, you move the order if it's relevant. This sub is
rarely called and could be switched to require
    * C4::Acquisition::GetOrderFromItemnumber = same comment, used a few
lines before ModOrder
   
==== Reserves.pm ====
Reserves.pm is really crapy and should probably be rewritten entirely.
A grep -R "use C4::Reserves;" *|wc -l says that 33 scripts are using
this package.

    There is a use Search.pm that is useless in Reserves.pm
    == use C4::Biblio ==
    loaded to call GetBiblioItemData and GetBiblioData:
      * GetBiblioData is called in AddReserve, to prepare and send a
mail depending on the syspref emailLibrarianWhenHoldIsPlaced
      * GetBiblioItemData is used twice in the same sub
C4::Reserves::GetReservesFromBiblionumber. Those informations are
retrieved just to get title,author,... and could be added into the
previous SQL query :
      instead of:
      SELECT biblioitemnumber
                FROM  reserveconstraints
                WHERE  biblionumber   = ?
                AND   borrowernumber = ?
                AND   reservedate    = ?
      write:
      SELECT reserveconstraints.biblionumber,biblio.*,biblioitems.* FROM
reserveconstraints
            LEFT JOIN biblio USING(biblionumber) LEFT JOIN biblioitems
USING(biblionumber)
            WHERE  biblionumber   = ? AND   borrowernumber = ? AND  
reservedate    = ?
     That should do the job, and the dependancy could be removed.
     Note: C4::Reserves::GetReservesFromBiblionumber is used in various
places, for example opac-reserve.pl or in catalogue/detail.pl, but it
seems we don't use all of the result computed in the sub. So maybe we
can just clean GetReservesFromBiblionumber. It must be checked better
    
     == use C4::Members ==
     loaded to call:
       * C4::Members::GetMember is called in
         * C4::Reserves::AddReserve, to prepare and send a mail
depending on the syspref emailLibrarianWhenHoldIsPlaced
         * C4::Reserves::CanItemBeReserved. This call is just to
retrieve patron category and branch. The CanItemBeReserved is called
only in request & opac-reserve & ILSDI pages. an option would be to send
categorycode and branchcode from here (and change the API of the sub)
         * C4::Reserves::_koha_notify_reserve, to retrieve the Email
(GetMember is always called, but the email is then retrieved from it or
from GetFirstValidEmailAddress (see below, it's a dirty code...)
       * C4::Members::GetFirstValidEmailAddress
GetFirstValidEmailAddress is called to send emails to patron that places
a reserve, I don't see how to remove this dependancy...
       * C4::Members::GetMemberDetails is called in
C4::Reserves::CheckReserves This sub is probably the crappiest in Koha.
It mixes many things, it should be entirely rewritten
   
Conclusion for C4::Reserves: I think we should try to isolate as much as
possible this package.

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08


From mjr at phonecoop.coop  Thu Sep 15 00:51:43 2011
From: mjr at phonecoop.coop (MJ Ray)
Date: Wed, 14 Sep 2011 23:51:43 +0100 (BST)
Subject: [Koha-devel] Commentary on Paul's Koha 3.8 Release Manager
	proposal
In-Reply-To: <CAE2wdZwcbYEn+EGr54wJDy00__HEK1Hy6SN=LdXB7hFSv__FRw@mail.gmail.com>
Message-ID: <20110914225143.5442B9F0E8@nail.towers.org.uk>

Ian Walls <ian.walls at bywatersolutions.com> [...]
> The major disagreement is with the timeline.  The proposal as it stands is
> to start working on Koha 3.8 and Koha 4.0 in parallel, with Koha 3.8
> releasing April 2012, and Koha 4.0 releasing Oct. 2012.  I feel that going
> from Koha 3.8 directly to 4.0 is unwarranted.  To my mind, there are many
> possible releases between 3.8 and 4.0, like 3.10, 3.12, 3.14 and so forth.
> This is supported by the actual database version numbers in Koha: the
> current release is actually 3.04.04; the zeros are squashed out for
> convenience. [...]

A minor disagreement is with the platform.  Paul's proposal seems to
be for 3.8 and 4.0 RM, yet there's very little detail on 4.0 because
the community discussion hasn't really started: lots of great features
suggested, some scary changes, but not much agreed.  Let's agree the
RM for 3.8 and then when the next release rolls around, then let's see
what we want to do then?

In general, I'm fine with folding into 3.x progressively.  Seems
like a good idea.  (Now find me more libraries so I can spend
more time on it... ;-) )

Regards,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for various work through http://www.software.coop/

From mjr at phonecoop.coop  Thu Sep 15 00:57:27 2011
From: mjr at phonecoop.coop (MJ Ray)
Date: Wed, 14 Sep 2011 23:57:27 +0100 (BST)
Subject: [Koha-devel] tools should they be command line executable as
	well ?
In-Reply-To: <4E5E4775.5010904@biblibre.com>
Message-ID: <20110914225727.34A2D9F0E8@nail.towers.org.uk>

Paul Poulain asked:
> On http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5636 Ian
> asked a question last month no-one answered. So I ask it here:
> > Style question to the community:  should core pages in the staff client (like
> > tools/cleanborrowers.pl) have both a templated page in the staff client AND a
> > command-line presence, or should the commandline tool be a separate script in
> > misc/? [...]
> My answer is:
> * right, there is no precedent
> * This feature to clean borrowers from command line is highly useful :
> most libraries want to define a rule, and have it applied every week,
> through a cronjob. But some want to clean manually. So it's meaningful
> to have a script for both cases.
> * I think it's fair to have this script run from both, and it's better
> than having 2 scripts for that, it's easier to maintain [...]

Would it be better to move the shared logic into a C4 module and have
both the staff web script and a misc CLI script?  Having scripts behave
differently depending on invocation environment seems a bit risky.

Hope that helps,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for various work through http://www.software.coop/

From paul.poulain at biblibre.com  Wed Sep 14 11:43:27 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 14 Sep 2011 11:43:27 +0200
Subject: [Koha-devel] Restructuring C4
In-Reply-To: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>
Message-ID: <4E70773F.6080309@biblibre.com>

Le 30/03/2011 16:47, Ian Walls a ?crit :
> Fellow Developers,
Hello everybody,
> Last night, I stayed up late running circ/circulation.pl
> <http://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.

For those who have used or developed on Koha 2.x, you probably have
noticed that Koha 2.x was much more slower than Koha 3.x
So, yesterday and tonight i've taken my laptop and made a lot of testings.

First of all, i'll thank forever ... The New York Times ... Why will you
tell me ? Because of
http://search.cpan.org/~adamk/Aspect-Library-NYTProf-1.00/lib/Aspect/Library/NYTProf.pm

This tool is really amazing. You run
perl -d:NYTProf mainpage.pl ; nytprofhtml --open
And you get a highly detailled HTML report with the time spent in each
line/sub/module to run mainpage.pl.
Here is the result :  http://depot.biblibre.com/ppoulain/nytprof.ini/
(the .ini is to keep track of the perf before anything optimized)

Note : tests done on my laptop, that is not a server.
1st test with master:
Profile of mainpage.pl for 1.73s (of 2.18s), executing 155108 statements
and 41041 subroutine calls in 249 source files and 64 string evals.

I have investigated to find the longest timings & if we can do something.
(note All the following improvement have been done incrementally)

First of all, C4::Context and C4::Koha are loaded on everypage, so it's
worth investigating

== C4::Context ==
* spent 185ms just reading the config file. Ouch ! that's almost 10% of
the time !!!
(http://depot.biblibre.com/ppoulain/nytprof.ini/C4-Context-pm-13-line.html#230)
I tried to hardcode the hashref instead of XMLin-ing the config file,
the results are astonishing :
after = Profile of mainpage.pl for 1.59s (of 1.93s), executing 117399
statements and 26939 subroutine calls in 241 source files and 63 string
evals.
=> PROPOSAL = add a YAML version of the XML config file that we could
use in //
=> PROPOSAL 2 = memcache the config file
(hint : the config file in koha 2 was not xml !)

* C4::Context, sub db_scheme2dbi, the i flag in /mysql/i cost 84ms !!!
with /i, the duration is 84.4ms, without, it's 10?s !!!
after = Profile of mainpage.pl for 1.55s (of 1.91s), executing 117398
statements and 26938 subroutine calls in 241 source files and 63 string
evals.
=> PROPOSAL = just 'return "mysql"' at the beginning of this sub, as
everything else is not working anyway !

== C4::Languages ==
* C4::Languages::getAllLanguages 43ms => heavily under optimized mysql
query = returns all languages from language_subtag_registry and
language_descriptions even if only a few localisations are installed.
* C4::Languages::_build_languages_arrayref 15ms => same as for
getAllLanguages
I know there is a patch (from hdl) pending to improve this sub, i
haven't tested it yet
(http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6000)
(hint : this sub appeared in 3.0, was not in 2.2 !)

== Other packages ==
* C4::Koha.pm 15ms for use Business::ISBN, that is used only in 1 sub
used only in a few pages (and none if no cover images are enabled unless
i'm wrong)
* C4::Letters use MIME::Lite spend 26ms, that are useless 90% of the
time (why is C4::Letters loaded ! answer = because C4::Reserves is
loaded by Items.pm that is loaded by Biblio.pm that is loaded by
AuthoritiesMarc.pm that is loaded (uselessly) by mainpage.pl
* CGI/Session/Driver/mysql.pm needs 79ms i've tested by switching to
driver::File::Serializer (dropped to 21ms). this seems to work, but
probably requires more testing than what I did
* Date::Manip needs requires 46ms and is useless most of the time.
after = Profile of mainpage.pl for 1.31s (of 1.60s), executing 103643
statements and 25380 subroutine calls in 215 source files and 55 string
evals.
=> PROPOSAL = WHERE it's interesting we could replace the use XXXX by a
require XXXX just before the lines that need the package. The require is
loaded at run tim, so, when unneeded, the package won't be loaded

== mainpage.pl ==
Mainpage.pl load some authorities, we do nothing with it. Commenting the
use C4::Authorities and all related code results in:
after = Profile of mainpage.pl for 1.27s (of 1.57s), executing 103000
statements and 25194 subroutine calls in 212 source files and 55 string
evals.

== Packages nested ==
* I also noticed that Auth.pm loads Members.pm (to retrieve patron
informations and display them on the top right). Members.pm loads
Reserves that loads Biblio.pm, Circulation.pm and Items.pm All those
packages are the biggest to load.
I've written a script, that display, for each file in C4 which package
is loaded and which sub in the package loaded are used. It shows, for
example, that there is a "use Koha.pm;" that is useless in
AuthoritiesMarc.pm It also shows which sub are used, and how many times.
For example, Circulation.pm calls "use C4::Biblio" and :
        In Circulation.pm the Biblio.pm, sub GetBiblioItemData is used 1
times
        In Circulation.pm the Biblio.pm, sub GetBiblioFromItemNumber is
used 4 times
That will be handy to find what can be cleaned & removed.

I've attached the script and the result. If you want to run it yourself,
just export PERL5LIB, KOHA_CONF, put the script in $KOHA directory, and
run it !

== Other ==
* packages that uses the biggest amount of CPU are not C4 packages :
  * utf8_heavy-pl is the most cpu consuming thing : 132ms, I don't know
if we can do something
  * Template::Parser needs 123ms, not sure we can do something
  * all XML stuff is highly consuming = loading MARC::File::XML requires
47ms in Biblio.pm, XML::Sax::Base require 40ms to be loaded
=> definetly, the best way to reduce CPU time is by pre-loading things,
we already knew that

== Next step ==
* i'll file a bug for the various improvements that can be made easily
* i'll continue investigate & report my findings
I'm aware it's a 1st step, and the long-term road is to reach data&code
persistency. But cleaning what we already have may ease the next big
step. And any speed improvement is a good thing, isn't it !

HTH

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

-------------- section suivante --------------
Une pi?ce jointe autre que texte a ?t? nettoy?e...
Nom: check_subs.log
Type: text/x-log
Taille: 42215 octets
Desc: non disponible
URL: </pipermail/koha-devel/attachments/20110914/6b19520d/attachment-0002.bin>
-------------- section suivante --------------
Une pi?ce jointe autre que texte a ?t? nettoy?e...
Nom: check_subs.pl
Type: content-type: text/marc
Taille: 2946 octets
Desc: non disponible
URL: </pipermail/koha-devel/attachments/20110914/6b19520d/attachment-0003.bin>

From ian.walls at bywatersolutions.com  Thu Sep 15 13:35:32 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Thu, 15 Sep 2011 07:35:32 -0400
Subject: [Koha-devel] Restructuring C4 (work continued)
In-Reply-To: <4E711C34.4000804@biblibre.com>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>
	<4E71149B.70009@biblibre.com> <4E711C34.4000804@biblibre.com>
Message-ID: <CAE2wdZxjjnKKYp+TT6Tez+uL93oP0+3SHqLK=vKYU-Nk=f5SSA@mail.gmail.com>

Paul,


Excellent!  I'd been meaning to do a complete workup on the system through
NYTProf when I got the time, and it looks like you've beat me too it.  Can
you post the full reports somewhere online, with some kind of guide as to
what scripts are which, which system preferences you had, and what input
params you passed?

I've got NYTProf on NEKLS test system (with their permission) and find that
that's an excellent resource for testing pages under various kinds of load.
It helped me fine the root of bug 6801 (which I still need to patch :/ )

Cheers,


-Ian

On Wed, Sep 14, 2011 at 5:27 PM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Hi,
>
> I've continued my work in the train, here is a result of my work.
>
> I've checked a lot of the packages in C4 and checked for dependancies
> (sub packages used)
> With the check_subs.pl script, it was quite easy to find which subs were
> called and see if it's needed.
>
> What I propose next is to file a bug for each package with my findings
> and my suggestions. Then, write a patch.
> I also plan to investigate some of the most used pages (like
> circ/circulation.pl, circ/return.pl, detail.pl, and most opac pages.
> Note that the check_subs can be also use to check package dependancies
> for perl scripts as well: on line 39, set "dirToCheck" to the directory
> you want to check. I've checked circ and opac, and have already
> discovered some interesting informations.
> If you have some comment, want to make another suggestion or give a
> hand, you're welcomed ;-)
>
> mainpage.pl loads the following .pm
> ==== C4::Auth.pm ====
>  == use Members.pm ==
>    only to call GetMemberDetails and fill USER_INFO parameters
>    USER_INFOS are used in a large variety of place.
>    * In a strange way, like in : acqui/acqui-home.pl:
> $template->{VARS}->{'USER_INFO'}[0]->{'borrowernumber'} );
>    Q: don't we have another way to retrieve loggedin librarian number ?
>    * in opac-reserve, to display who we place a request for. Again,
> this could/should be moved to opac-reserve, and we use GetMemberDetails
> in this sub
>
>    CONCLUSION = we should be able to get rid of use Members.pm in Auth.pm
>  == use C4::Context.pm ==
>    package that can't be avoided and loads nothing specific
>  == use C4::Output.pm ==
>    = use C4::Budgets =
>    just to call Budget::GetCurrency in the Output::FormatNumber sub.
> The Output::FormatNumber sub is used only in a few places, related to
> C4::Budgets
>    CONCLUTION => move FormatNumber outside from C4::Output into
> C4::Budgets and we will get rid of this dependancy
>    = use C4::Languages =
>    to call a lot of sub here, no possibility to do something
>    = use C4::Dates =
>    to call format_date, in Date::FormatDate in C4::Output::FormatData
> sub that is called only in aqbudgetperiod.pl and should easily be
> removed. it contains only
>            $$data_hashref{$_} = format_date( $$data_hashref{$_} ) for
> grep{/date/} keys (%$data_hashref);
>    that can be inlined in aqbudgetperiod (and it would be better to use
> the OOo date tools)
>    = use C4::Templates =
>    needed, it's the package that smoothen the transition between
> H::T::P and T::T
>
>  == use C4::Branch ==
>    = use C4::Koha = just to call get_infos_of once, we could get rid
> with this sub by inlining and remove the C4::Koha dependancy
>
>  == use C4::VirtualShelves ==
>    * this package is needed in case of an OPAC query (on every opac
> page we display the public & private lists). I suspect it's not needed
> in staff interface. Anyone to confirm/argue ?
>    * We use only GetRecentShelves sub,
>    * we put everything in the session (set_shelves_userenv) & context
> ($session->param('barshelves', $barshelves);) I think there is no use
> for this. Anyone to confirm/argue ?
>    *  also note that the following line
>            my ($total, $pubshelves) =
> C4::Context->get_shelves_userenv();  # an anonymous user has no
> 'barshelves'...
>            (C4::Auth, line 301 and the following) seems strange.
>    = use C4::Circulation =
>        and that's the beginning of circular-painfull-loading-everything.
>        In C4::VirtualShelves, there is no use of anything from
> C4::Circulation. I've commented the line, made a lot of tests, and saw
> no problem at all.
>
> ==== C4::Koha ====
>  This loading is useless. I've commented the line and saw no problem.
>
> ==== C4::AuthoritiesMarc; ====
> This part is useless here, we do nothing with the authorities retrieved.
>
> ==== C4::NewsChannels ====
>  == use C4::Context ==
>  nothing to say, needed to access the database
>  == use C4::Dates ==
>  nothing to say, needed to format the date the news has been published.
>
> <<<< END OF mainpage specifics >>>>
> Continued to check some of the major .pm
>
> ==== Member.pm ====
> Member.pm, (that is loaded by Auth.pm at the moment) load the following
> packages:
>    == use Reserves.pm ==
>        Reserves.pm is used only to call
>            my @itemswaiting =
> C4::Reserves::GetReservesFromBorrowernumber(
> $patroninformation->{'borrowernumber'},'W' );
>        in C4::Members::patronflags sub
>        I'm not sure we do anything with the result of
> GetReservesFromBorrowernumber:
>        C4::Members, line 518 contains :
>            my @itemswaiting =
> C4::Reserves::GetReservesFromBorrowernumber(
> $patroninformation->{'borrowernumber'},'W' );
>            my $nowaiting = scalar @itemswaiting;
>            if ( $nowaiting > 0 ) {
>                my %flaginfo;
>                $flaginfo{'message'}  = "Reserved items available";
>                $flaginfo{'itemlist'} = \@itemswaiting;
>                $flags{'WAITING'}     = \%flaginfo;
>            }
>            return ( \%flags );
>        I've some doubts about the need for this code, i've commented
> it, placed a hold, make it waiting for pickup, I see everything as
> usual, I saw no difference. It will be worth a bug entry and a patch to
> test soon !
>
>        I've moved the use C4::Members to a require C4::Member just
> before the GetReservesFromBorrowernumber call
>            NYTProf before commenting :
>            Profile of mainpage.pl for 1.24s (of 1.54s), executing
> 102597 statements and 25016 subroutine calls in 212 source files and 55
> string evals.
>            NYTProf after commenting :
>            Profile of mainpage.pl for 1.25s (of 1.55s), executing
> 102489 statements and 24984 subroutine calls in 212 source files and 55
> string evals.
>            (the duration is strange. But I was with my laptop on the
> battery, so that may explain. The number of statements&subroutines are
> lowered though)
>
>    == use C4::Overdues.pm ==
>      this is loaded only to call checkoverdues in
> C4::Members::GetMemberDetails
>      The result is stored in the big member detail hash returned :
>            my ( $odues, $itemsoverdue ) =
> checkoverdues($patroninformation->{'borrowernumber'});
>            if ( $odues && $odues > 0 ) {
>                my %flaginfo;
>                $flaginfo{'message'}  = "Yes";
>                $flaginfo{'itemlist'} = $itemsoverdue;
>                foreach ( sort { $a->{'date_due'} cmp $b->{'date_due'} }
>                    @$itemsoverdue )
>                {
>                    $flaginfo{'itemlisttext'} .=
>                      "$_->{'date_due'} $_->{'barcode'} $_->{'title'}
> \n";  # newline is display layer
>                }
>                $flags{'ODUES'} = \%flaginfo;
>        It's used only in circulation.pl, return.pl and SIP.pm
>        My opinion is that we could have a dedicated sub for that in
> Circulation.pm (that is always loaded in circulation.pl & return.pl),
>        retrieve the result from here when needed and reduce the size of
> GetMemberDetails (that would not return everything)
>
>    == use C4::Biblio.pm ==
>      this is loaded just to call C4::Biblio::GetBiblioFromItemNumber in
> C4::Members::GetMemberAccountRecords to retrieve title and author
>      This can be easily circumvented with a correct LEFT join a few
> lines before.
>      Instead of
>          SELECT *
>            FROM accountlines
>            WHERE borrowernumber
>      write :
>      SELECT accountlines.*,biblio.title,biblio.author FROM accountlines
> LEFT JOIN items USING(itemnumber) LEFT JOIN biblio USING(biblionumber)
> WHERE borrowernumber
>      The use C4::Biblio can be removed !
>    == use C4::Account.pm ==
>      this is loaded to call manualinvoice twice.
>      the manualinvoice is used only when adding or renewing a patron.
> So it should be efficient to move from a use C4::Account to a require
> C4::Account where applicable
>
> ==== Accounts.pm ====
>    == use C4::Stats ==
>    this package contains only one sub (updatestats) and no dependancies
>    == use C4::Members ==
>    loaded just to call C4::Members::GetMember once in the
> C4::Accounts::returnlost sub.
>    This sub seems totally unused in Koha (dead code)
>    grep -R "returnlost" * shows only the sub header itself. Could be
> removed.
>    == use C4::Items ==
>    loaded to call ModItem twice.
>    The 1st call is in C4::Accounts::returnlost, that can be removed
> (see below)
>    The 2nd call is in C4::Accounts::chargelostitem, that is rarely
> used. Switching to require C4::Items should be possible
>    == use C4::Circulation ==
>    This loading is similar to C4::Items with
> C4::Circulation::MarkIssueReturned sub :
>    The 1st call is in C4::Accounts::returnlost, that can be removed
> (see below)
>    The 2nd call is in C4::Accounts::chargelostitem, that is rarely
> used. Switching to require C4::Circulation should be possible
>
> ==== Acquisition.pm ====
>    There is a use Debug.pm that is useless in Acquisition.pm
>    There is a use Biblio.pm that is useless in Acquisition.pm
>    use C4::Debug is written twice !
>    == use C4::Suggestions ==
>      the ModSuggestion and GetSuggestionFromBiblionumber are called
> when an order is recieved. Could switch to require, both statements are
> close
>
> ==== Biblio.pm ====
>      == use C4::Serials ==
>      Serials.pm is loaded to delete subscriptions in
> C4::Biblio::DelBiblio. 2 subs are used :
> C4::Serials::GetFullSubscriptionsFromBiblionumber and
> C4::Serials::DelSubscription
>      both can be moved to require at the right place
>      == use C4::Items ==
>      * the check_subs script wrongly report a use of ModItem and
> DelItem, it's a comment in the code :
>          # duplication or incorrect data - use AddItem() or ModItem()
>      * C4::Biblio uses C4::Items::GetMarcItem twice
>        * once in PrepareItemrecordDisplay => this sub sounds at a wrong
> place. It could/should be moved to C4::Items itself.
> PrepareItemrecordDisplay is used by:
>          * acqui/addorderiso2709.pl = already loads C4::Items
>          * acqui/neworderempty.pl = don't load C4::Items for instance
>          * acqui/orderreceive.pl = already loads C4::Items
>          * C4/Serials.pm = need more investigation
>          * serials/serials-edit.pl = already loads C4::Items
>        * once in C4::Biblio::EmbedItemsInMarcBiblio
>          Could we remove this sub ? question still pending. it's used
> only in:
>            * C4::Biblio::GetMarcBiblio
>            * misc/migration_tools/rebuild_zebra.pl
>            * tools/export.pl
>
> ==== Items.pm ====
>    == use C4::Biblio ==
>    Too many things are required, we can't change. The best solution
> would be to remove C4::Items reference in C4::Biblio
> GetOrderFromItemnumber
>    == use C4::Reserves ==
>    This package is loaded just for C4::Reserves::CheckReserves called
> in C4::Items::GetItemsInfo
>    The GetItemsInfo stores the result of CheckReserves in a hash entry,
> count_reserve, that is used only in opac_detail to display the status of
> a hold. We could remove the reserve_count hash entry and inline
> C4::Reserves::CheckReserves directly from opac-detail.pl page
>    in opac-detail.pl, instead of
>    if( $itm->{'count_reserves'} eq "Waiting"){ $itm->{'waiting'} = 1; }
>    write :
>    if ( C4::Reserves::CheckReserves(<<parameters>>) eq "Waiting"){
> $itm->{'waiting'} = 1; }
>
>    == use C4::Acquisition ==
>    This package is loaded to call
>    * C4::Acquisition::ModOrder = recent addition, when you move an item
> to another biblio, you move the order if it's relevant. This sub is
> rarely called and could be switched to require
>    * C4::Acquisition::GetOrderFromItemnumber = same comment, used a few
> lines before ModOrder
>
> ==== Reserves.pm ====
> Reserves.pm is really crapy and should probably be rewritten entirely.
> A grep -R "use C4::Reserves;" *|wc -l says that 33 scripts are using
> this package.
>
>    There is a use Search.pm that is useless in Reserves.pm
>    == use C4::Biblio ==
>    loaded to call GetBiblioItemData and GetBiblioData:
>      * GetBiblioData is called in AddReserve, to prepare and send a
> mail depending on the syspref emailLibrarianWhenHoldIsPlaced
>      * GetBiblioItemData is used twice in the same sub
> C4::Reserves::GetReservesFromBiblionumber. Those informations are
> retrieved just to get title,author,... and could be added into the
> previous SQL query :
>      instead of:
>      SELECT biblioitemnumber
>                FROM  reserveconstraints
>                WHERE  biblionumber   = ?
>                AND   borrowernumber = ?
>                AND   reservedate    = ?
>      write:
>      SELECT reserveconstraints.biblionumber,biblio.*,biblioitems.* FROM
> reserveconstraints
>            LEFT JOIN biblio USING(biblionumber) LEFT JOIN biblioitems
> USING(biblionumber)
>            WHERE  biblionumber   = ? AND   borrowernumber = ? AND
> reservedate    = ?
>     That should do the job, and the dependancy could be removed.
>     Note: C4::Reserves::GetReservesFromBiblionumber is used in various
> places, for example opac-reserve.pl or in catalogue/detail.pl, but it
> seems we don't use all of the result computed in the sub. So maybe we
> can just clean GetReservesFromBiblionumber. It must be checked better
>
>     == use C4::Members ==
>     loaded to call:
>       * C4::Members::GetMember is called in
>         * C4::Reserves::AddReserve, to prepare and send a mail
> depending on the syspref emailLibrarianWhenHoldIsPlaced
>         * C4::Reserves::CanItemBeReserved. This call is just to
> retrieve patron category and branch. The CanItemBeReserved is called
> only in request & opac-reserve & ILSDI pages. an option would be to send
> categorycode and branchcode from here (and change the API of the sub)
>         * C4::Reserves::_koha_notify_reserve, to retrieve the Email
> (GetMember is always called, but the email is then retrieved from it or
> from GetFirstValidEmailAddress (see below, it's a dirty code...)
>       * C4::Members::GetFirstValidEmailAddress
> GetFirstValidEmailAddress is called to send emails to patron that places
> a reserve, I don't see how to remove this dependancy...
>       * C4::Members::GetMemberDetails is called in
> C4::Reserves::CheckReserves This sub is probably the crappiest in Koha.
> It mixes many things, it should be entirely rewritten
>
> Conclusion for C4::Reserves: I think we should try to isolate as much as
> possible this package.
>
> --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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 at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110915/33a45764/attachment-0001.htm>

From paul.poulain at biblibre.com  Thu Sep 15 22:00:39 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 15 Sep 2011 22:00:39 +0200
Subject: [Koha-devel] Restructuring C4 (work continued)
In-Reply-To: <CAE2wdZxjjnKKYp+TT6Tez+uL93oP0+3SHqLK=vKYU-Nk=f5SSA@mail.gmail.com>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>	<4E71149B.70009@biblibre.com>	<4E711C34.4000804@biblibre.com>
	<CAE2wdZxjjnKKYp+TT6Tez+uL93oP0+3SHqLK=vKYU-Nk=f5SSA@mail.gmail.com>
Message-ID: <4E725967.5070405@biblibre.com>

Le 15/09/2011 13:35, Ian Walls a ?crit :
> Paul,
> 
> 
> Excellent!  I'd been meaning to do a complete workup on the system through
> NYTProf when I got the time, and it looks like you've beat me too it.  Can
> you post the full reports somewhere online,
I don't understand what you mean by "full reports"
> with some kind of guide as to
> what scripts are which, which system preferences you had, and what input
> params you passed?
well, all this analysis was just based on mainpage.pl run, and
investigating C4 modules.
I worked on both de-nesting and perf improving.
My first tests were mostly done to test performances. It appears that
the biggest goal now is to lower the package loading cost, thus I moved
from perfs to de-nesting. I think de-nesting will greatly help moving
forward on perf improving. Plus it will be a good help to reach
persistency. Plus it's always better to have a clean code, of course.


-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From cnighswonger at foundations.edu  Fri Sep 16 02:26:53 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Thu, 15 Sep 2011 20:26:53 -0400
Subject: [Koha-devel] 3.4.x String Freeze
In-Reply-To: <CAP3yOokae06Ziuf20asHKJyoDBPiMyyhRAuPcz-b8e=hTS4UoA@mail.gmail.com>
References: <CAP3yOokae06Ziuf20asHKJyoDBPiMyyhRAuPcz-b8e=hTS4UoA@mail.gmail.com>
Message-ID: <CAP3yOo=yZ_uDkM1LG=re92wFLxt79BkGN8wEvAqtoRRjOdbsHQ@mail.gmail.com>

Hi all,

3.4.x is presently in a string freeze preparing for the 3.4.5 release. 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110915/3571008f/attachment.htm>

From colin.campbell at ptfs-europe.com  Fri Sep 16 14:13:57 2011
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Fri, 16 Sep 2011 13:13:57 +0100
Subject: [Koha-devel] tt style point
Message-ID: <4E733D85.9020300@ptfs-europe.com>

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 at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com

From ian.walls at bywatersolutions.com  Fri Sep 16 14:33:59 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Fri, 16 Sep 2011 08:33:59 -0400
Subject: [Koha-devel] tt style point
In-Reply-To: <4E733D85.9020300@ptfs-europe.com>
References: <4E733D85.9020300@ptfs-europe.com>
Message-ID: <CAE2wdZx4tuGBUxWBZw7bCknooLz7VoLM=rmfroV+N_O9UmhC6Q@mail.gmail.com>

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?

Cheers,


-Ian

On Fri, Sep 16, 2011 at 8:13 AM, Colin Campbell <
colin.campbell at 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 at ptfs-europe.com
> skype: colin_campbell2
>
> http://www.ptfs-europe.com
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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 at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110916/1b6980d7/attachment.htm>

From paul.a at aandc.org  Fri Sep 16 16:48:21 2011
From: paul.a at aandc.org (Paul)
Date: Fri, 16 Sep 2011 10:48:21 -0400
Subject: [Koha-devel] tt style point
In-Reply-To: <CAE2wdZx4tuGBUxWBZw7bCknooLz7VoLM=rmfroV+N_O9UmhC6Q@mail.g
	mail.com>
References: <4E733D85.9020300@ptfs-europe.com>
	<4E733D85.9020300@ptfs-europe.com>
Message-ID: <5.2.1.1.2.20110916101537.06108c78@localhost>

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 at 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 at ptfs-europe.com
>skype: colin_campbell2
>
>http://www.ptfs-europe.com
>_______________________________________________
>Koha-devel mailing list
>Koha-devel at 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 at bywatersolutions.com
>Twitter: @sekjal
>_______________________________________________
>Koha-devel mailing list
>Koha-devel at 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/


From suzanne.bellande at univ-lr.fr  Fri Sep 16 16:50:00 2011
From: suzanne.bellande at univ-lr.fr (Suzanne Bellande)
Date: Fri, 16 Sep 2011 16:50:00 +0200
Subject: [Koha-devel] unsuscribed
Message-ID: <4E736218.9060600@univ-lr.fr>

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




From henridamien.laurent at gmail.com  Fri Sep 16 17:04:22 2011
From: henridamien.laurent at gmail.com (LAURENT Henri-Damien)
Date: Fri, 16 Sep 2011 17:04:22 +0200
Subject: [Koha-devel] tt style point
In-Reply-To: <CAE2wdZx4tuGBUxWBZw7bCknooLz7VoLM=rmfroV+N_O9UmhC6Q@mail.gmail.com>
References: <4E733D85.9020300@ptfs-europe.com>
	<CAE2wdZx4tuGBUxWBZw7bCknooLz7VoLM=rmfroV+N_O9UmhC6Q@mail.gmail.com>
Message-ID: <4E736576.9020306@gmail.com>

Hi
I agree with both of you.
kohaisms are not really interesting.
And we need to try and strengthen the Coding Style GuideLines.
But then.
Who, How, When ?
Who ? should it be up to contributors or to QA manager to ensure that
coding style GuideLines are abided.
Coding Style guidelines could also state a kind of hierarchy in
folders/templates design, pod commenting. Posting some hooks and/or some
vimrc (for indentation) may help. We could improve one another way to
test and develop.

I think both should have some responsibility.
How ?
For already sent patches, new guidelines should be considered as not
appliable and it could be up to the QA queue to update the patch
and send a followup
For new patches, as soon as it is publicised in the wiki, it could be up
to the developer to comply with the guidelines.
The problem is that when the developer donot have time enough to update
the patch and the patch either fixes a bug  OR add a much desired
feature. Then anyone willing to have that patch could send a sign off
and a followup and ask for sign-off.
my 2 cts.
-- 
Henri-Damien LAURENT

Le 16/09/2011 14:33, Ian Walls a ?crit :
> 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?
> 
> Cheers,
> 
> 
> -Ian
> 
> On Fri, Sep 16, 2011 at 8:13 AM, Colin Campbell
> <colin.campbell at ptfs-europe.com <mailto:colin.campbell at 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
> 
> 
> -- 
> Ian Walls
> Lead Development Specialist
> ByWater Solutions
> Phone # (888) 900-8944
> http://bywatersolutions.com
> ian.walls at bywatersolutions.com <mailto:ian.walls at bywatersolutions.com>
> Twitter: @sekjal
> 
> 


From colin.campbell at ptfs-europe.com  Fri Sep 16 18:01:56 2011
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Fri, 16 Sep 2011 17:01:56 +0100
Subject: [Koha-devel] tt style point
In-Reply-To: <4E736576.9020306@gmail.com>
References: <4E733D85.9020300@ptfs-europe.com>
	<CAE2wdZx4tuGBUxWBZw7bCknooLz7VoLM=rmfroV+N_O9UmhC6Q@mail.gmail.com>
	<4E736576.9020306@gmail.com>
Message-ID: <4E7372F4.4090109@ptfs-europe.com>

On 16/09/11 16:04, LAURENT Henri-Damien wrote:
> Hi
> I agree with both of you.
> kohaisms are not really interesting.
> And we need to try and strengthen the Coding Style GuideLines.
> But then.
> Who, How, When ?
> Who ? should it be up to contributors or to QA manager to ensure that
> coding style GuideLines are abided.

Style guidelines should be a) simple and b) mechanizable

Here's the style guide for perl in the Apache::Lucy project:

>All code should follow perlstyle.
>
>Formatting is handled automatically using Perltidy with a perltidyrc
>file derived from the guidelines laid out in Damian Conway's book
>'Perl Best Practices'.

Its nice because it points to an way of automatically maintaining
consistency (perltidy) and two sources of recommendations and rationales
for those recommendations.

The fact that its automatic means contributors can be pointed at simple
instructions on how to conform, and QA or RM  can enforce it with a script.

( although my initial point about tt was about style being imposed on
something that usually doesn't have such concerns )

C.

-- 
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 at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com

From mtj at kohaaloha.com  Sun Sep 18 21:43:05 2011
From: mtj at kohaaloha.com (Mason James)
Date: Mon, 19 Sep 2011 07:43:05 +1200
Subject: [Koha-devel] tt style point
In-Reply-To: <4E7372F4.4090109@ptfs-europe.com>
References: <4E733D85.9020300@ptfs-europe.com>
	<CAE2wdZx4tuGBUxWBZw7bCknooLz7VoLM=rmfroV+N_O9UmhC6Q@mail.gmail.com>
	<4E736576.9020306@gmail.com> <4E7372F4.4090109@ptfs-europe.com>
Message-ID: <F9DD9E28-46AC-4DD0-8934-2E0C0B9BBA71@kohaaloha.com>


On 2011-09-17, at 4:01 AM, Colin Campbell wrote:

> On 16/09/11 16:04, LAURENT Henri-Damien wrote:
>> Hi
>> I agree with both of you.
>> kohaisms are not really interesting.
>> And we need to try and strengthen the Coding Style GuideLines.
>> But then.
>> Who, How, When ?
>> Who ? should it be up to contributors or to QA manager to ensure that
>> coding style GuideLines are abided.
> 
> Style guidelines should be a) simple and b) mechanizable
> 
> Here's the style guide for perl in the Apache::Lucy project
> 
>> All code should follow perlstyle.
>> 
>> Formatting is handled automatically using Perltidy with a perltidyrc
>> file derived from the guidelines laid out in Damian Conway's book
>> 'Perl Best Practices'.
> 
> Its nice because it points to an way of automatically maintaining
> consistency (perltidy) and two sources of recommendations and rationales
> for those recommendations.
> 


nice spotting Colin :)

i agree, and always run perltidy over my code as a habit

i just checked and there's no mention yet of default .perltidyrc standard on the 'Koha coding guidelines' wiki page
 http://wiki.koha-community.org/wiki/Coding_Guidelines#HTML_Templates

can we discuss, then add one?!? :p
i'm keen on the -pbp 'Perl Best Practices' style, myself

what do other folk think?


cheers, Mason

From cnighswonger at foundations.edu  Sun Sep 18 23:42:18 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Sun, 18 Sep 2011 17:42:18 -0400
Subject: [Koha-devel] tt style point
In-Reply-To: <F9DD9E28-46AC-4DD0-8934-2E0C0B9BBA71@kohaaloha.com>
References: <4E733D85.9020300@ptfs-europe.com>
	<CAE2wdZx4tuGBUxWBZw7bCknooLz7VoLM=rmfroV+N_O9UmhC6Q@mail.gmail.com>
	<4E736576.9020306@gmail.com> <4E7372F4.4090109@ptfs-europe.com>
	<F9DD9E28-46AC-4DD0-8934-2E0C0B9BBA71@kohaaloha.com>
Message-ID: <CAP3yOomwiyrsqt2LZH=69=krrUbHQV-iquscd=WFnVUvV3SqzQ@mail.gmail.com>

On Sun, Sep 18, 2011 at 3:43 PM, Mason James <mtj at kohaaloha.com> wrote:

> nice spotting Colin :)
>
> i agree, and always run perltidy over my code as a habit
>
> i just checked and there's no mention yet of default .perltidyrc standard
> on the 'Koha coding guidelines' wiki page
>  http://wiki.koha-community.org/wiki/Coding_Guidelines#HTML_Templates
>
>

Actually this has been discussed before and there is a perltidyrc available
in the main repo:

http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=xt/perltidyrc;h=f7d9a3c9be7674a86961f675c46c224d8f72cef0;hb=HEAD



> can we discuss, then add one?!? :p
> i'm keen on the -pbp 'Perl Best Practices' style, myself
>

IIRC we ended up agreeing that there was much disagreement in coding style.

My opinion, FWIW, leans toward PBP as well, though.

Kind Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110918/5b732d1b/attachment.htm>

From mtj at kohaaloha.com  Mon Sep 19 04:06:28 2011
From: mtj at kohaaloha.com (Mason James)
Date: Mon, 19 Sep 2011 14:06:28 +1200
Subject: [Koha-devel] tt style point
In-Reply-To: <CAP3yOomwiyrsqt2LZH=69=krrUbHQV-iquscd=WFnVUvV3SqzQ@mail.gmail.com>
References: <4E733D85.9020300@ptfs-europe.com>
	<CAE2wdZx4tuGBUxWBZw7bCknooLz7VoLM=rmfroV+N_O9UmhC6Q@mail.gmail.com>
	<4E736576.9020306@gmail.com> <4E7372F4.4090109@ptfs-europe.com>
	<F9DD9E28-46AC-4DD0-8934-2E0C0B9BBA71@kohaaloha.com>
	<CAP3yOomwiyrsqt2LZH=69=krrUbHQV-iquscd=WFnVUvV3SqzQ@mail.gmail.com>
Message-ID: <ED0B6CC3-2DC8-4CEC-BEF0-DC0AA19F6E6B@kohaaloha.com>


On 2011-09-19, at 9:42 AM, Chris Nighswonger wrote:

> 
> On Sun, Sep 18, 2011 at 3:43 PM, Mason James <mtj at kohaaloha.com> wrote:
> nice spotting Colin :)
> 
> i agree, and always run perltidy over my code as a habit
> 
> i just checked and there's no mention yet of default .perltidyrc standard on the 'Koha coding guidelines' wiki page
>  http://wiki.koha-community.org/wiki/Coding_Guidelines#HTML_Templates
> 
> 
> 
> Actually this has been discussed before and there is a perltidyrc available in the main repo:
> 
> http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=xt/perltidyrc;h=f7d9a3c9be7674a86961f675c46c224d8f72cef0;hb=HEAD


yep, i use that xt/perltidyrc example for my own Koha perl code, like a good Koha developer

>  
> can we discuss, then add one?!? :p
> i'm keen on the -pbp 'Perl Best Practices' style, myself
> 
> IIRC we ended up agreeing that there was much disagreement in coding style.
> 
> My opinion, FWIW, leans toward PBP as well, though.

me too PBP++, 
if its good enough for Damian Conway - its good enough for us :p

a quick google shows that this topic has been discussed a few times over the years... with no firm agreement :/

http://lists.gnu.org/archive/html/koha-devel/2007-02/msg00013.html
http://lists.koha-community.org/pipermail/koha-devel/2010-February/033658.html
http://lists.koha-community.org/pipermail/koha-devel/2003-May/025915.html

shall we have another go at an agreement on this Folks? 
is this a topic for the next IRC meeting?

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 


is there anyone that *doesnt* want -pbp 'Perl Best Practices' style formatting as the default??


cheers, Mason
-- 
KohaAloha, NZ


From chrisc at catalyst.net.nz  Mon Sep 19 06:28:45 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Mon, 19 Sep 2011 16:28:45 +1200
Subject: [Koha-devel] Feature Freeze September 22nd
Message-ID: <20110919042845.GX3571@rorohiko.wgtn.cat-it.co.nz>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20110919/e6fbd2d8/attachment.pgp>

From robin at catalyst.net.nz  Mon Sep 19 06:32:13 2011
From: robin at catalyst.net.nz (Robin Sheat)
Date: Mon, 19 Sep 2011 16:32:13 +1200
Subject: [Koha-devel] tt style point
In-Reply-To: <ED0B6CC3-2DC8-4CEC-BEF0-DC0AA19F6E6B@kohaaloha.com>
References: <4E733D85.9020300@ptfs-europe.com>
	<CAE2wdZx4tuGBUxWBZw7bCknooLz7VoLM=rmfroV+N_O9UmhC6Q@mail.gmail.com>
	<4E736576.9020306@gmail.com> <4E7372F4.4090109@ptfs-europe.com>
	<F9DD9E28-46AC-4DD0-8934-2E0C0B9BBA71@kohaaloha.com>
	<CAP3yOomwiyrsqt2LZH=69=krrUbHQV-iquscd=WFnVUvV3SqzQ@mail.gmail.com>
	<ED0B6CC3-2DC8-4CEC-BEF0-DC0AA19F6E6B@kohaaloha.com>
Message-ID: <1316406734.5304.3.camel@zarathud>

Op maandag 19-09-2011 om 14:06 uur [tijdzone +1200], schreef Mason
James:
> is there anyone that *doesnt* want -pbp 'Perl Best Practices' style
> formatting as the default??

That was a silly question ;)

Maybe better to just mandate it and deal with issues as they come up? I
don't agree with 100% of PBP, but I'd be happy to go with it in order to
make the code nice and consistent.

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
GPG: 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20110919/06ba29f3/attachment.pgp>

From mtj at kohaaloha.com  Mon Sep 19 11:18:59 2011
From: mtj at kohaaloha.com (Mason James)
Date: Mon, 19 Sep 2011 21:18:59 +1200
Subject: [Koha-devel] tt style point
In-Reply-To: <1316406734.5304.3.camel@zarathud>
References: <4E733D85.9020300@ptfs-europe.com>
	<CAE2wdZx4tuGBUxWBZw7bCknooLz7VoLM=rmfroV+N_O9UmhC6Q@mail.gmail.com>
	<4E736576.9020306@gmail.com> <4E7372F4.4090109@ptfs-europe.com>
	<F9DD9E28-46AC-4DD0-8934-2E0C0B9BBA71@kohaaloha.com>
	<CAP3yOomwiyrsqt2LZH=69=krrUbHQV-iquscd=WFnVUvV3SqzQ@mail.gmail.com>
	<ED0B6CC3-2DC8-4CEC-BEF0-DC0AA19F6E6B@kohaaloha.com>
	<1316406734.5304.3.camel@zarathud>
Message-ID: <226DAC9C-930A-410D-89E8-A3FC27B5AFEA@kohaaloha.com>


On 2011-09-19, at 4:32 PM, Robin Sheat wrote:

> Op maandag 19-09-2011 om 14:06 uur [tijdzone +1200], schreef Mason
> James:
>> is there anyone that *doesnt* want -pbp 'Perl Best Practices' style
>> formatting as the default??
> 
> That was a silly question ;)
> 
> Maybe better to just mandate it and deal with issues as they come up? I
> don't agree with 100% of PBP,

yes, i dont like all of PBP style too...

> but I'd be happy to go with it in order to make the code nice and consistent.

yep,  but i'm very happy to go with PBP style over another formatting style

so it sounds like a tentative vote for PBP style formatting from Robin, Chris.N and Mason... 

anyone else have a better idea? 



From mjr at phonecoop.coop  Mon Sep 19 18:18:02 2011
From: mjr at phonecoop.coop (MJ Ray)
Date: Mon, 19 Sep 2011 17:18:02 +0100 (BST)
Subject: [Koha-devel] tt style point
In-Reply-To: <ED0B6CC3-2DC8-4CEC-BEF0-DC0AA19F6E6B@kohaaloha.com>
Message-ID: <20110919161802.C70FB9F0E8@nail.towers.org.uk>

Mason James wrote:
> 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 
> 
> is there anyone that *doesnt* want -pbp 'Perl Best Practices' style formatting as the default??

Probably.  I dislike delegating this decision to an O'Reilly book
and it would change some historic practices, so probably reformat
a lot of code.  I think -pbp is equivalent to:

    -l=78 -i=4 -ci=4 -st -se -vt=2 -cti=0 -pt=1 -bt=1 -sbt=1 -bbt=1 -nsfs -nolq
    -wbb="% + - * / x != == >= <= =~ !~ < > | & = 
          **= += *= &= <<= &&= -= /= |= >>= ||= //= .= %= ^= x="

but the perltidy man page doesn't say why those are best practices!
They look as arbitrary as the GNU Coding Standards to me and rather
more invasive, but would anyone who has the book like to enlighten us?

The Koha current perltidyrc conflicts with -pbp in that it has -l=178
-ci=2 -bbt=0 -sfs -olq which disagree with the above.

I've linked the perltidyrc from
http://wiki.koha-community.org/wiki/Coding_Guidelines#Perl
which might help more people to notice it.

I think that perltidyrc was submitted in response to bug 2269 by
Andrew Moore at LibLime, apparently based on my suggestions.  I also
suggested -bar -ce which I don't think affects -pbp either way, -vt=2
which agrees, -pt=2 which disagrees and -en=4 which doesn't even seem
to exist!

http://wiki.koha-community.org/wiki/Coding_Guidelines#To_be_decided
also specifies a capitalisation approach, -> for hashrefs and use of
ODLIS terms which I don't think perltidy can enforce.

So, why would it be worth changing the line length limits,
indentation, outdentation, brace-tightness, and semicolon spacing to pbp?

Looking forward to your replies,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for various work through http://www.software.coop/

From robin at catalyst.net.nz  Mon Sep 19 23:51:12 2011
From: robin at catalyst.net.nz (Robin Sheat)
Date: Tue, 20 Sep 2011 09:51:12 +1200
Subject: [Koha-devel] tt style point
In-Reply-To: <20110919161802.C70FB9F0E8@nail.towers.org.uk>
References: <20110919161802.C70FB9F0E8@nail.towers.org.uk>
Message-ID: <201109200951.13205.robin@catalyst.net.nz>

Op dinsdag 20 september 2011 04:18:02 schreef MJ Ray:
> Probably.  I dislike delegating this decision to an O'Reilly book

I prefer to delegate to Conway than some other arbitrary standard. The 
publisher is irrelevant.

> and it would change some historic practices, so probably reformat
> a lot of code.  I think -pbp is equivalent to:
> 
>     -l=78 -i=4 -ci=4 -st -se -vt=2 -cti=0 -pt=1 -bt=1 -sbt=1 -bbt=1 -nsfs
> -nolq -wbb="% + - * / x != == >= <= =~ !~ < > | & =
>           **= += *= &= <<= &&= -= /= |= >>= ||= //= .= %= ^= x="
> 
> but the perltidy man page doesn't say why those are best practices!

Because you could fill an entire book with that, and that's too big for a man 
page.

> They look as arbitrary as the GNU Coding Standards to me and rather
> more invasive, but would anyone who has the book like to enlighten us?

Each one is justified fairly well. For the one or two I disagree with (that 
I've found so far) I can see the rationale, I'm really just used to doing it 
another way. I'm not, however, going to write out everything, because that's a 
lot of effort for little gain. If you have a particular question, I'm sure I 
can answer it.
 
> The Koha current perltidyrc conflicts with -pbp in that it has -l=178
> -ci=2 -bbt=0 -sfs -olq which disagree with the above.

Of these, I think that each is "wrong", not because it's different to pbp, but 
because it hinders read/writeability. And -l=178? You must be kidding. That's 
terrible in-and-of itself. If I were to disregard something because of where 
it came from, this would be enough to make me disregard the rest of your 
suggestions ;)

> suggested -bar -ce

-bar isn't addressed in pbp (iirc), however -ce is in direct contradiction to 
it (this is something I'm not in total agreement with, but I'm willing to 
overlook it happily enough. I think my bias here comes from several years 
doing Java.)

> which I don't think affects -pbp either way, -vt=2
> which agrees, -pt=2 which disagrees and -en=4 which doesn't even seem
> to exist!

-pt=1 (the default) is another where my usual way of writing differs, but I do 
find myself doing that in the more confusing constructs, which leads me to 
think that it's actually not such a bad idea.

As for -en=4, that's almost as terrible an idea as -l=178. I'll pretend you 
didn't say it.
 
> http://wiki.koha-community.org/wiki/Coding_Guidelines#To_be_decided
> also specifies a capitalisation approach, -> for hashrefs and use of
> ODLIS terms which I don't think perltidy can enforce.

Again, I prefer the PBP method for naming. It's what (almost) every other Perl 
module does, and for fairly good reason. (Nutshell version: sub_name, 
$identifier_name, %title_of{$book_id}, @flowers, Package::Name, $CONSTANT)

As for -> for hash/arrayrefs, definitely.

> So, why would it be worth changing the line length limits,
> indentation, outdentation, brace-tightness, and semicolon spacing to pbp?

Because: a) it's a standard that many perl editors understand, b) many perl 
programmers understand, c) it's less arbitrary than any other standard (as the 
reasoning is quite meticulously backed up), d) it's a pretty good standard, e) 
if you don't pick a standard then the code will continue to be quite ugly, and 
this is one we have now without years of quibbling over where braces should 
go, f) many people have access to the book and so can read the justifications 
if they wish. 

There's probably more reasons I haven't thought of.

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/koha-devel/attachments/20110920/51c1167d/attachment.pgp>

From mtj at kohaaloha.com  Tue Sep 20 04:33:30 2011
From: mtj at kohaaloha.com (Mason James)
Date: Tue, 20 Sep 2011 14:33:30 +1200
Subject: [Koha-devel] tt style point
In-Reply-To: <4E76F8A5.40509@gmail.com>
References: <4E733D85.9020300@ptfs-europe.com>	<CAE2wdZx4tuGBUxWBZw7bCknooLz7VoLM=rmfroV+N_O9UmhC6Q@mail.gmail.com>	<4E736576.9020306@gmail.com>
	<4E7372F4.4090109@ptfs-europe.com>	<F9DD9E28-46AC-4DD0-8934-2E0C0B9BBA71@kohaaloha.com>	<CAP3yOomwiyrsqt2LZH=69=krrUbHQV-iquscd=WFnVUvV3SqzQ@mail.gmail.com>
	<ED0B6CC3-2DC8-4CEC-BEF0-DC0AA19F6E6B@kohaaloha.com>
	<4E76F8A5.40509@gmail.com>
Message-ID: <44EE2F7E-6B48-4969-A60C-7212DF55B18C@kohaaloha.com>


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

From mtj at kohaaloha.com  Tue Sep 20 04:52:19 2011
From: mtj at kohaaloha.com (Mason James)
Date: Tue, 20 Sep 2011 14:52:19 +1200
Subject: [Koha-devel] tt style point
In-Reply-To: <201109200951.13205.robin@catalyst.net.nz>
References: <20110919161802.C70FB9F0E8@nail.towers.org.uk>
	<201109200951.13205.robin@catalyst.net.nz>
Message-ID: <DDF77D86-6677-4A99-A5E3-FF72F7C20495@kohaaloha.com>


On 2011-09-20, at 9:51 AM, Robin Sheat wrote:

> Op dinsdag 20 september 2011 04:18:02 schreef MJ Ray:
>> Probably.  I dislike delegating this decision to an O'Reilly book
> 
> I prefer to delegate to Conway than some other arbitrary standard. The 
> publisher is irrelevant.

> 
>> So, why would it be worth changing the line length limits,
>> indentation, outdentation, brace-tightness, and semicolon spacing to pbp?
> 
> Because: a) it's a standard that many perl editors understand, b) many perl 
> programmers understand, c) it's less arbitrary than any other standard (as the 
> reasoning is quite meticulously backed up), d) it's a pretty good standard, e) 
> if you don't pick a standard then the code will continue to be quite ugly, and 
> this is one we have now without years of quibbling over where braces should 
> go, f) many people have access to the book and so can read the justifications 
> if they wish. 
> 
> There's probably more reasons I haven't thought of.
> 

i know i just wrote a ranty reply to HDL's email before on this thread... :p

but hey... Robin's above points are perfect
-PBP is a standard, and AFAIK its the only meticulously reasoned Perl formatting standard there is

if not -PBP, then what?


Mason

From mtj at kohaaloha.com  Tue Sep 20 13:40:52 2011
From: mtj at kohaaloha.com (Mason James)
Date: Tue, 20 Sep 2011 23:40:52 +1200
Subject: [Koha-devel] tt style point
In-Reply-To: <4E784C0D.2090308@gmail.com>
References: <4E733D85.9020300@ptfs-europe.com>	<CAE2wdZx4tuGBUxWBZw7bCknooLz7VoLM=rmfroV+N_O9UmhC6Q@mail.gmail.com>	<4E736576.9020306@gmail.com>
	<4E7372F4.4090109@ptfs-europe.com>	<F9DD9E28-46AC-4DD0-8934-2E0C0B9BBA71@kohaaloha.com>	<CAP3yOomwiyrsqt2LZH=69=krrUbHQV-iquscd=WFnVUvV3SqzQ@mail.gmail.com>
	<ED0B6CC3-2DC8-4CEC-BEF0-DC0AA19F6E6B@kohaaloha.com>
	<4E76F8A5.40509@gmail.com>
	<44EE2F7E-6B48-4969-A60C-7212DF55B18C@kohaaloha.com>
	<4E784C0D.2090308@gmail.com>
Message-ID: <B452C122-D6CE-4828-830A-823D54640C2D@kohaaloha.com>

reply inline

On 2011-09-20, at 8:17 PM, LAURENT Henri-Damien wrote:

> Le 20/09/2011 04:33, Mason James a ?crit :
>> 
>> 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...
>> 
> it is always the same question : who will decide

we can decide now the koha-devel mailing-list, or as a topic for the next Koha IRC meeting


> and who will process
> the files ?

not sure on that bit yet :p , lets agree on a Perl style standard first, then decide who/how/when later


>> 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 :)
> When ? some things has already been committed. And things donot get
> improved.


when should we agree on a formatting style,? how about now...

>> 
>> 
>> 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
> I am not.
> git blame may be useful, but code readability is a much serious issue.
> I think that some decision should be not only discussed but also taken,
> announced and applied.

ah, ok 
that would be the next thing to discuss, after we all voted on a Perl formatting style :)

>> 
>> 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
> How can you enforce PBP or any formatting on part of a file ?

its easy using vim!, and surely possible for all other respectable editors


> If previous file indentation is broken, you will just add broken things.

nope, perltidy corrects the indentation perfectly, without any syntax errors


> If there is some magic I don't know please tell me.

yes, there is some magic :)

i added this to my .vimrc file, now F4 tidys a selected block of text :)
fyi: i use this method many times a day

----------------------------------------                                                              
map <F4>   <Esc>:%! perltidy<CR>                                                
----------------------------------------                                                              

described here...
http://www.modernperlbooks.com/mt/2009/10/from-novice-to-adept-cleaning-up-bad-code.html

i very rarely run perltidy on a whole Koha file, 
instead i run it *carefully* on small blocks of messy historical Koha code as i see them


>> 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!
>> 
> I don't know what ranty mean.

"To speak agressivly about somthing. or to take your own tangent about a subject and talk for a long time in a passionate manner" :)

http://www.urbandictionary.com/define.php?term=rant


> But don't be mistaken, all I want is a change for better. The fact is
> that ppl are working on the same code ignoring what other ppl are doing.
> And with the need to revamp more and more things for security,
> sustainability and performance issues. I think that it should be shared,
> discussed, stated, worked in groups and done.

yes... but thats a separate issue to what Perl formatting style to use for Koha

so remember, there's a few who/when/how issues to discuss here... 
but can we at least agree on a Perl formatting style, for a start

-PBP++ ;)


cheers, Mason

From robin at catalyst.net.nz  Wed Sep 21 00:53:15 2011
From: robin at catalyst.net.nz (Robin Sheat)
Date: Wed, 21 Sep 2011 10:53:15 +1200
Subject: [Koha-devel] tt style point
In-Reply-To: <B452C122-D6CE-4828-830A-823D54640C2D@kohaaloha.com>
References: <4E733D85.9020300@ptfs-europe.com>
	<CAE2wdZx4tuGBUxWBZw7bCknooLz7VoLM=rmfroV+N_O9UmhC6Q@mail.gmail.com>
	<4E736576.9020306@gmail.com> <4E7372F4.4090109@ptfs-europe.com>
	<F9DD9E28-46AC-4DD0-8934-2E0C0B9BBA71@kohaaloha.com>
	<CAP3yOomwiyrsqt2LZH=69=krrUbHQV-iquscd=WFnVUvV3SqzQ@mail.gmail.com>
	<ED0B6CC3-2DC8-4CEC-BEF0-DC0AA19F6E6B@kohaaloha.com>
	<4E76F8A5.40509@gmail.com>
	<44EE2F7E-6B48-4969-A60C-7212DF55B18C@kohaaloha.com>
	<4E784C0D.2090308@gmail.com>
	<B452C122-D6CE-4828-830A-823D54640C2D@kohaaloha.com>
Message-ID: <1316559195.5304.27.camel@zarathud>

Op dinsdag 20-09-2011 om 23:40 uur [tijdzone +1200], schreef Mason
James:
> i added this to my .vimrc file, now F4 tidys a selected block of
> text :)
> fyi: i use this method many times a day
> 
> ----------------------------------------                                                              
> map <F4>   <Esc>:%!
> perltidy<CR>                                                
> ----------------------------------------                                                              
> 

Nifty. I've improved on this slightly:

" Allow easy running of perltidy, bound to F6
nnoremap <F6>   <Esc>:%! perltidy -q<CR>
vnoremap <F6>   <Esc>:'<,'> ! perltidy -q<CR>

this allows you to apply it to parts of the file using visual mode, or
the whole thing if you're not in visual mode. -q is good to stop it
doing syntax checks and outputting other things that may mess up your
editor display (or maybe the content of the file itself when it goes
through the filter, not sure.)

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
GPG: 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20110921/8e3be08a/attachment.pgp>

From tajoli at cilea.it  Wed Sep 21 11:53:01 2011
From: tajoli at cilea.it (Zeno Tajoli)
Date: Wed, 21 Sep 2011 11:53:01 +0200
Subject: [Koha-devel] incomplete list in  install_misc/debian.packages
Message-ID: <4E79B3FD.6060503@cilea.it>

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

From robin at catalyst.net.nz  Wed Sep 21 12:27:17 2011
From: robin at catalyst.net.nz (Robin Sheat)
Date: Wed, 21 Sep 2011 22:27:17 +1200
Subject: [Koha-devel] incomplete list in  install_misc/debian.packages
In-Reply-To: <4E79B3FD.6060503@cilea.it>
References: <4E79B3FD.6060503@cilea.it>
Message-ID: <201109212227.22548.robin@catalyst.net.nz>

Op woensdag 21 september 2011 21:53:01 schreef Zeno Tajoli:
> 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.

Have you seen this:

http://wiki.koha-community.org/wiki/Koha_3.4_on_Debian_Squeeze

it may make things easier. Also, all the dependencies that aren't in Debian 
are in there, should you still want to do it the old-fashioned way.

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/koha-devel/attachments/20110921/282734ab/attachment.pgp>

From tajoli at cilea.it  Wed Sep 21 12:42:27 2011
From: tajoli at cilea.it (Zeno Tajoli)
Date: Wed, 21 Sep 2011 12:42:27 +0200
Subject: [Koha-devel] incomplete list in  install_misc/debian.packages
In-Reply-To: <201109212227.22548.robin@catalyst.net.nz>
References: <4E79B3FD.6060503@cilea.it>
	<201109212227.22548.robin@catalyst.net.nz>
Message-ID: <4E79BF93.7060606@cilea.it>

Hi,

Il 21/09/2011 12:27, Robin Sheat ha scritto:
> Op woensdag 21 september 2011 21:53:01 schreef Zeno Tajoli:
>> 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.
> 
> Have you seen this:
> 
> http://wiki.koha-community.org/wiki/Koha_3.4_on_Debian_Squeeze
> 
> it may make things easier. Also, all the dependencies that aren't in Debian 
> are in there, should you still want to do it the old-fashioned way.


i'm doing a git installation by hand.
So I use install_misc/debian.packages.

But if I use
deb http://debian.koha-community.org/koha squeeze-dev main
as source, do I use the code of git master ?

Bye
Zeno Tajoli

-- 
Dott. Zeno Tajoli
tajoliAT_SPAM_no_prendiATcilea.it
fax +39 02 2135520
CILEA - Consorzio Interuniversitario
http://www.cilea.it/disclaimer

From robin at catalyst.net.nz  Wed Sep 21 13:39:05 2011
From: robin at catalyst.net.nz (Robin Sheat)
Date: Wed, 21 Sep 2011 23:39:05 +1200
Subject: [Koha-devel] incomplete list in  install_misc/debian.packages
In-Reply-To: <4E79BF93.7060606@cilea.it>
References: <4E79B3FD.6060503@cilea.it>
	<201109212227.22548.robin@catalyst.net.nz> <4E79BF93.7060606@cilea.it>
Message-ID: <201109212339.24735.robin@catalyst.net.nz>

Op woensdag 21 september 2011 22:42:27 schreef Zeno Tajoli:
> But if I use
> deb http://debian.koha-community.org/koha squeeze-dev main
> as source, do I use the code of git master ?

If you use squeeze-dev, it's master. If you use just squeeze, it's 3.4.4 (and 
I try to update it shortly after each release.)

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/koha-devel/attachments/20110921/ce731d68/attachment.pgp>

From paul.poulain at biblibre.com  Wed Sep 21 13:49:41 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 21 Sep 2011 13:49:41 +0200
Subject: [Koha-devel] unsuscribed
In-Reply-To: <4E736218.9060600@univ-lr.fr>
References: <4E736218.9060600@univ-lr.fr>
Message-ID: <4E79CF55.5040903@biblibre.com>

Le 16/09/2011 16:50, Suzanne Bellande a ?crit :
> Please unsuscribed me.
> 
> sincerely,
> Suzanne Bellande

Hi Suzanne,

seems noone answered your mail, so I do.
Look at the end of any mail, the address to manage your subscription is
written :
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From paul.poulain at biblibre.com  Wed Sep 21 17:44:10 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 21 Sep 2011 17:44:10 +0200
Subject: [Koha-devel] Restructuring C4 (Bug 6875)
In-Reply-To: <4E725967.5070405@biblibre.com>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>	<4E71149B.70009@biblibre.com>	<4E711C34.4000804@biblibre.com>
	<CAE2wdZxjjnKKYp+TT6Tez+uL93oP0+3SHqLK=vKYU-Nk=f5SSA@mail.gmail.com>
	<4E725967.5070405@biblibre.com>
Message-ID: <4E7A064A.1030802@biblibre.com>

Hello world!

For ppl looking at bugzilla, you'll already have seen that the bug 6875
has been open to keep track of all my work.

I spent 30+ hours on this topic, and 17 patches are attached to this
bug, that now require sign-off

The final gain is interesting (see
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6875#c20) . My
gain evaluation are incomplete, and i'm sure they'll be very important
on some pages, and quite limited on some. The packages for circulation &
reserves are heavily nested, it's almost impossible to do better without
restructuring completly C4, and that will be another goal.
In the meantime, if someone feel brave enough to give a try to each
patch, the rule is easy to test for signoff = those patches strictly
changes nothing in Koha behaviour, it's just internal stuff...

For some of them, it will be easy, for a few of them it will require a
lot of testing.

Chris C. = can you run all automated tests easily or tell me how to do it ?

All = i've added this bug as an ENH, but I was hesitating with
"Critical". What do you think ? is it just an ENH or a bugfix ?


-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From danielg.koha at gmail.com  Wed Sep 21 20:21:18 2011
From: danielg.koha at gmail.com (Daniel Grobani)
Date: Wed, 21 Sep 2011 11:21:18 -0700
Subject: [Koha-devel] Call for News for the September Newsletter
Message-ID: <CAOeKewifX8cNHMntB3zqp3=DA8uDPjhKwgD2+eK9NhgtX2hxVg@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110921/e68caa09/attachment.htm>

From mjr at phonecoop.coop  Thu Sep 22 16:24:16 2011
From: mjr at phonecoop.coop (MJ Ray)
Date: Thu, 22 Sep 2011 15:24:16 +0100 (BST)
Subject: [Koha-devel] tt style point
In-Reply-To: <201109200951.13205.robin@catalyst.net.nz>
Message-ID: <20110922142416.12DEB9F0E8@nail.towers.org.uk>

Robin Sheat wrote:
> Op dinsdag 20 september 2011 04:18:02 schreef MJ Ray:
> > Probably.  I dislike delegating this decision to an O'Reilly book
> 
> I prefer to delegate to Conway than some other arbitrary standard. The 
> publisher is irrelevant.

I dislike that publisher in particular, but also I'm a democrat, so
in general I'm against appointing Conway as a pope.  This discussion
should be about whether that book is correct, not who is the best
person to follow.

> > and it would change some historic practices, so probably reformat
> > a lot of code.  I think -pbp is equivalent to:
> > 
> >     -l=78 -i=4 -ci=4 -st -se -vt=2 -cti=0 -pt=1 -bt=1 -sbt=1 -bbt=1 -nsfs
> > -nolq -wbb="% + - * / x != == >= <= =~ !~ < > | & =
> >           **= += *= &= <<= &&= -= /= |= >>= ||= //= .= %= ^= x="
> > 
> > but the perltidy man page doesn't say why those are best practices!
> 
> Because you could fill an entire book with that, and that's too big for a man 
> page.
> 
> > They look as arbitrary as the GNU Coding Standards to me and rather
> > more invasive, but would anyone who has the book like to enlighten us?
> 
> Each one is justified fairly well. For the one or two I disagree with (that 
> I've found so far) I can see the rationale, I'm really just used to doing it 
> another way. I'm not, however, going to write out everything, because that's a 
> lot of effort for little gain. If you have a particular question, I'm sure I 
> can answer it.

So is there no concise explanation of any of them?  If so, this must
be quite tenuous.

If someone could justify the bits where it's in conflict with Koha
perltidyrc/past practice, that would suffice.

[...]
> > The Koha current perltidyrc conflicts with -pbp in that it has -l=178
> > -ci=2 -bbt=0 -sfs -olq which disagree with the above.
> 
> Of these, I think that each is "wrong", not because it's different to pbp, but 
> because it hinders read/writeability. And -l=178? You must be kidding. That's 
> terrible in-and-of itself. If I were to disregard something because of where 
> it came from, this would be enough to make me disregard the rest of your 
> suggestions ;)

Oh niiiice, shoot the messenger because you can't justify it?

When I made parameter suggestions, I think I was trying to codify
current practice where it existed, as a starting point, but my memory
is poor and I don't have any relevant notes to hand.

Personally, I don't care what the maximum line length is, but I seem
to recall that some at liblime and biblibre used pretty wide windows
for coding, so there are some long lines in the code and I had
patches rejected when I split them.

[...]
> > So, why would it be worth changing the line length limits,
> > indentation, outdentation, brace-tightness, and semicolon spacing to pbp?
> 
> Because: a) it's a standard that many perl editors understand, b) many perl 
> programmers understand, c) it's less arbitrary than any other standard (as the 
> reasoning is quite meticulously backed up), d) it's a pretty good standard, e) 
> if you don't pick a standard then the code will continue to be quite ugly, and 
> this is one we have now without years of quibbling over where braces should 
> go, f) many people have access to the book and so can read the justifications 
> if they wish. 

But, a and b) they understand others too (GCS being the obvious
alternative which would help open Koha up to non-perl and
multi-language programmers); c and d) no evidence of that has been
shown; e) is irrelevant because I'm not arguing against setting any
standard; f) seems like proof by appeal to authority, also creating a
divide between those who buy the ORA texts and those who do not.  (The
book is not in LibrariesWest and I'm not inclined to suggest my taxes
are spent on it.)

So at the moment, I think GCS with a few relaxations to avoid changing
old Koha code seems like the most logical standard.

Regards,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for various work through http://www.software.coop/

From colin.campbell at ptfs-europe.com  Thu Sep 22 17:59:31 2011
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Thu, 22 Sep 2011 16:59:31 +0100
Subject: [Koha-devel] tt style point
In-Reply-To: <20110922142416.12DEB9F0E8@nail.towers.org.uk>
References: <20110922142416.12DEB9F0E8@nail.towers.org.uk>
Message-ID: <4E7B5B63.60404@ptfs-europe.com>

On 22/09/11 15:24, MJ Ray wrote:
> Robin Sheat wrote:
>> Op dinsdag 20 september 2011 04:18:02 schreef MJ Ray:
>>> Probably.  I dislike delegating this decision to an O'Reilly book
>>
>> I prefer to delegate to Conway than some other arbitrary standard. The 
>> publisher is irrelevant.
> 
> I dislike that publisher in particular, but also I'm a democrat, so
> in general I'm against appointing Conway as a pope.  This discussion
> should be about whether that book is correct, not who is the best
> person to follow.

The rationale for most of the formatting issues in pbp is that code
should be consistent and that unless there is a good reason not to we
should adopt the perl style guide ('perldoc perlstyle'). So most of the
recommendations don't come from Damien or his evil publishers but have
been distributed with perl for ages.

>>
>> Of these, I think that each is "wrong", not because it's different to pbp, but 
>> because it hinders read/writeability. And -l=178? You must be kidding. That's 
>> terrible in-and-of itself. If I were to disregard something because of where 
>> it came from, this would be enough to make me disregard the rest of your 
>> suggestions ;)
> 
> 
> Personally, I don't care what the maximum line length is, but I seem
> to recall that some at liblime and biblibre used pretty wide windows
> for coding, so there are some long lines in the code and I had
> patches rejected when I split them.
I agree wholeheartedly with Robin's point, although you might have lots
of screen real estate its surprising how many tools for looking at code
work better with a shorter line length and the extra real estate is
probably more useful for running more windows. Too often the real import
of a line might just disappear of the right edge... Plus its a handy
reminder that your code might be becoming far too deeply nested so I
think most coding standards irrespective of language gravitate towards
an 80 col standard.
> 

> 
> But, a and b) they understand others too (GCS being the obvious
> alternative which would help open Koha up to non-perl and
> multi-language programmers); c and d) no evidence of that has been
> shown; e) is irrelevant because I'm not arguing against setting any
> standard; f) seems like proof by appeal to authority, also creating a
> divide between those who buy the ORA texts and those who do not.  (The
> book is not in LibrariesWest and I'm not inclined to suggest my taxes
> are spent on it.)
As far as GCS is concerned perltidy's man page points out that "-gnu
approximates to the Gnu Coding Standards (which do not apply to perl) as
they are sometimes implemented" Not really a resounding vote in favour.

It's not about the book, almost all the formatting recommendations come
from the documentation which has always come with perl. It also is a
style which does not jar with the bulk of good code you'll find in CPAN
and elsewhere.
The purpose of PBP was to encourage people to think about writing
robust, maintainable code. If folks want to see what the recommendations
were (unfortunately minus the rationale) see:

http://refcards.com/docs/vromansj/perl-best-practices/refguide.pdf

For rationales of some of the recommendations and other good suggestions
folk might want to look at

http://onyxneon.com/books/modern_perl/

which is free in its electronic form.
One of the points made there is that following community norms unless
theres a real reason to differ is good because the community builds
tools which leverage those norms. perltidy is an example, I think if you
compare the defaults with the pbp recommendations they are identical for
most settings

C.

-- 
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 at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com

From paul.a at aandc.org  Thu Sep 22 18:07:53 2011
From: paul.a at aandc.org (Paul)
Date: Thu, 22 Sep 2011 12:07:53 -0400
Subject: [Koha-devel] tt style point
In-Reply-To: <20110922142416.12DEB9F0E8@nail.towers.org.uk>
References: <201109200951.13205.robin@catalyst.net.nz>
Message-ID: <5.2.1.1.2.20110922120439.018dde18@localhost>

At 03:24 PM 9/22/2011 +0100, MJ Ray wrote:
[snip]
>So at the moment, I think GCS with a few relaxations to avoid changing
>old Koha code seems like the most logical standard.

Could you please point me to a write-up about "GCS" -- my googling 
abilities are coming up short. Thanks,

Paul
Tired old sys-admin 


From mjr at phonecoop.coop  Thu Sep 22 18:52:36 2011
From: mjr at phonecoop.coop (MJ Ray)
Date: Thu, 22 Sep 2011 17:52:36 +0100 (BST)
Subject: [Koha-devel] tt style point
In-Reply-To: <5.2.1.1.2.20110922120439.018dde18@localhost>
Message-ID: <20110922165236.CA8B49F0E8@nail.towers.org.uk>

Paul wrote:
> At 03:24 PM 9/22/2011 +0100, MJ Ray wrote:
> [snip]
> >So at the moment, I think GCS with a few relaxations to avoid changing
> >old Koha code seems like the most logical standard.
> 
> Could you please point me to a write-up about "GCS" -- my googling 
> abilities are coming up short. Thanks,

I should have expanded the abbreviation on the first use in the post,
but look back up this discussion and you'll see it's GNU Coding
Standards, which are at http://www.gnu.org/prep/standards/ and the
most relevant section probably starts at
http://www.gnu.org/prep/standards/html_node/Formatting.html

Do you like Google or not? If you like it, I seem to recall they
don't like it as a verb. If not, use a better search engine. ;-)

Hope that informs,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for various work through http://www.software.coop/

From mjr at phonecoop.coop  Thu Sep 22 19:42:51 2011
From: mjr at phonecoop.coop (MJ Ray)
Date: Thu, 22 Sep 2011 18:42:51 +0100 (BST)
Subject: [Koha-devel] tt style point
In-Reply-To: <4E7B5B63.60404@ptfs-europe.com>
Message-ID: <20110922174251.2DDC99F0E8@nail.towers.org.uk>

Colin Campbell wrote:
> On 22/09/11 15:24, MJ Ray wrote:
> > I dislike that publisher in particular, but also I'm a democrat, so
> > in general I'm against appointing Conway as a pope.  This discussion
> > should be about whether that book is correct, not who is the best
> > person to follow.
> 
> The rationale for most of the formatting issues in pbp is that code
> should be consistent and that unless there is a good reason not to we
> should adopt the perl style guide ('perldoc perlstyle'). So most of the
> recommendations don't come from Damien or his evil publishers but have
> been distributed with perl for ages.

Past practices (the current perltidyrc) and making it easy for a
broader audience than just perl hackers (-gcs) both seem like good
reasons not to do it, but pbp is not the same as perlstyle (which
is the perltidy defaults).

[line length of 178]
> > Personally, I don't care what the maximum line length is, but I seem
> > to recall that some at liblime and biblibre used pretty wide windows
> > for coding, so there are some long lines in the code and I had
> > patches rejected when I split them.
> I agree wholeheartedly with Robin's point, although you might have lots
> of screen real estate its surprising how many tools for looking at code
> work better with a shorter line length and the extra real estate is
> probably more useful for running more windows. Too often the real import
> of a line might just disappear of the right edge... Plus its a handy
> reminder that your code might be becoming far too deeply nested so I
> think most coding standards irrespective of language gravitate towards
> an 80 col standard.

Those are whole debates in themselves, like whether short-line-only
tools are broken and whether it's healthy to restructure code mainly
to reduce nesting, but I suggested 178 because coders were using it.

If I've got these command right, they still seem to be:

coop at koha:~/koha/unstable/src$ find . -type f -name '*.pl' | wc -l
966

coop at koha:~/koha/unstable/src$ grep -Erl '^.{79,999}' $(find . -type f -name '*.pl') | wc -l
937

coop at koha:~/koha/unstable/src$ grep -Erl '^.{79,178}' $(find . -type f -name '*.pl') | wc -l
937

So I think about 97% of .pl files would be changed by just that one
setting change.

I'd love to hear if many use 178-columns now, especially at biblibre
and liblime because I think it came from one of them.

> > But, a and b) they understand others too (GCS being the obvious
> > alternative which would help open Koha up to non-perl and
> > multi-language programmers); 
> As far as GCS is concerned perltidy's man page points out that "-gnu
> approximates to the Gnu Coding Standards (which do not apply to perl) as
> they are sometimes implemented" Not really a resounding vote in favour.

Well, they're written only for C, but it's a pretty trivial
translation to most languages and they're less Perl-specific.

> > [...] proof by appeal to authority, also creating a
> > divide between those who buy the ORA texts and those who do not.
> It's not about the book, almost all the formatting recommendations come
> from the documentation which has always come with perl. It also is a
> style which does not jar with the bulk of good code you'll find in CPAN
> and elsewhere.

It does jar with the bulk of Koha, much of which is also good code in
other ways, isn't it?

The Koha community never followed the perlstyle recommendations,
they're not new and I'd like to think that our predecessor coders had
their reasons for what they did (I don't know if Chris C knows why but
I think it was on Josh's watch), so I feel there needs to be a decent
reason for such a wide-reaching change.

> For rationales of some of the recommendations and other good suggestions
> folk might want to look at
> http://onyxneon.com/books/modern_perl/
> which is free in its electronic form.

I'll take a look at that.  It may take some time.  PDFs aren't fun.

> One of the points made there is that following community norms unless
> theres a real reason to differ is good because the community builds
> tools which leverage those norms. perltidy is an example, I think if you
> compare the defaults with the pbp recommendations they are identical for
> most settings

perltidy's defaults are perlstyle, not PBP.

Following community norms is a great idea!  *Which* community norms?

We've at least four norms to choose between here: Koha, GNU, Perlstyle
and PBP.  PBP seems the least accessibly documented of them all and I
don't think any formatting can be brilliant enought to outweigh that
barrier - and I don't think a restricted book like PBP is really a
*community* norm either.

Regards,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
http://koha-community.org supporter, web and LMS developer, statistician.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for Koha work http://www.software.coop/products/koha

From alex.arnaud at biblibre.com  Fri Sep 23 11:07:52 2011
From: alex.arnaud at biblibre.com (Alex Arnaud)
Date: Fri, 23 Sep 2011 11:07:52 +0200
Subject: [Koha-devel] tt style point
In-Reply-To: <20110922174251.2DDC99F0E8@nail.towers.org.uk>
References: <20110922174251.2DDC99F0E8@nail.towers.org.uk>
Message-ID: <4E7C4C68.2040900@biblibre.com>

Hi all,

I've not had time to read all in this topic, then sorry if you already 
told about my problem.

I got an error when going to the biblio_framework page in koha. 
"unexpected token (marc) [% grille marc %] at 
/home/users/koha/versions/community/C4/Templates.pm line 119."

[% grille marc %] is simply the french tranlation of [% frameworkcode %] 
in the english template. I've modified the EN Template to add 
parenthesis around 'framwork' and it has not been translated to 'grille 
marc'. good.

Then i think it would be better to do the same for each variables in 
each template but, strangely, in the same template, few lines later 
another [% frameworkcode %] has not been translated to [% grille marc 
%]. I don't know why ...


Le 22/09/2011 19:42, MJ Ray a ?crit :
> Colin Campbell wrote:
>> On 22/09/11 15:24, MJ Ray wrote:
>>> I dislike that publisher in particular, but also I'm a democrat, so
>>> in general I'm against appointing Conway as a pope.  This discussion
>>> should be about whether that book is correct, not who is the best
>>> person to follow.
>> The rationale for most of the formatting issues in pbp is that code
>> should be consistent and that unless there is a good reason not to we
>> should adopt the perl style guide ('perldoc perlstyle'). So most of the
>> recommendations don't come from Damien or his evil publishers but have
>> been distributed with perl for ages.
> Past practices (the current perltidyrc) and making it easy for a
> broader audience than just perl hackers (-gcs) both seem like good
> reasons not to do it, but pbp is not the same as perlstyle (which
> is the perltidy defaults).
>
> [line length of 178]
>>> Personally, I don't care what the maximum line length is, but I seem
>>> to recall that some at liblime and biblibre used pretty wide windows
>>> for coding, so there are some long lines in the code and I had
>>> patches rejected when I split them.
>> I agree wholeheartedly with Robin's point, although you might have lots
>> of screen real estate its surprising how many tools for looking at code
>> work better with a shorter line length and the extra real estate is
>> probably more useful for running more windows. Too often the real import
>> of a line might just disappear of the right edge... Plus its a handy
>> reminder that your code might be becoming far too deeply nested so I
>> think most coding standards irrespective of language gravitate towards
>> an 80 col standard.
> Those are whole debates in themselves, like whether short-line-only
> tools are broken and whether it's healthy to restructure code mainly
> to reduce nesting, but I suggested 178 because coders were using it.
>
> If I've got these command right, they still seem to be:
>
> coop at koha:~/koha/unstable/src$ find . -type f -name '*.pl' | wc -l
> 966
>
> coop at koha:~/koha/unstable/src$ grep -Erl '^.{79,999}' $(find . -type f -name '*.pl') | wc -l
> 937
>
> coop at koha:~/koha/unstable/src$ grep -Erl '^.{79,178}' $(find . -type f -name '*.pl') | wc -l
> 937
>
> So I think about 97% of .pl files would be changed by just that one
> setting change.
>
> I'd love to hear if many use 178-columns now, especially at biblibre
> and liblime because I think it came from one of them.
>
>>> But, a and b) they understand others too (GCS being the obvious
>>> alternative which would help open Koha up to non-perl and
>>> multi-language programmers);
>> As far as GCS is concerned perltidy's man page points out that "-gnu
>> approximates to the Gnu Coding Standards (which do not apply to perl) as
>> they are sometimes implemented" Not really a resounding vote in favour.
> Well, they're written only for C, but it's a pretty trivial
> translation to most languages and they're less Perl-specific.
>
>>> [...] proof by appeal to authority, also creating a
>>> divide between those who buy the ORA texts and those who do not.
>> It's not about the book, almost all the formatting recommendations come
>> from the documentation which has always come with perl. It also is a
>> style which does not jar with the bulk of good code you'll find in CPAN
>> and elsewhere.
> It does jar with the bulk of Koha, much of which is also good code in
> other ways, isn't it?
>
> The Koha community never followed the perlstyle recommendations,
> they're not new and I'd like to think that our predecessor coders had
> their reasons for what they did (I don't know if Chris C knows why but
> I think it was on Josh's watch), so I feel there needs to be a decent
> reason for such a wide-reaching change.
>
>> For rationales of some of the recommendations and other good suggestions
>> folk might want to look at
>> http://onyxneon.com/books/modern_perl/
>> which is free in its electronic form.
> I'll take a look at that.  It may take some time.  PDFs aren't fun.
>
>> One of the points made there is that following community norms unless
>> theres a real reason to differ is good because the community builds
>> tools which leverage those norms. perltidy is an example, I think if you
>> compare the defaults with the pbp recommendations they are identical for
>> most settings
> perltidy's defaults are perlstyle, not PBP.
>
> Following community norms is a great idea!  *Which* community norms?
>
> We've at least four norms to choose between here: Koha, GNU, Perlstyle
> and PBP.  PBP seems the least accessibly documented of them all and I
> don't think any formatting can be brilliant enought to outweigh that
> barrier - and I don't think a restricted book like PBP is really a
> *community* norm either.
>
> Regards,


From tajoli at cilea.it  Fri Sep 23 15:34:16 2011
From: tajoli at cilea.it (Zeno Tajoli)
Date: Fri, 23 Sep 2011 15:34:16 +0200
Subject: [Koha-devel] bug  6328 signed off, patch stopped (spam ?)
Message-ID: <4E7C8AD8.5000409@cilea.it>

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 at 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

From colin.campbell at ptfs-europe.com  Fri Sep 23 16:31:43 2011
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Fri, 23 Sep 2011 15:31:43 +0100
Subject: [Koha-devel] tt style point
In-Reply-To: <4E7C4C68.2040900@biblibre.com>
References: <20110922174251.2DDC99F0E8@nail.towers.org.uk>
	<4E7C4C68.2040900@biblibre.com>
Message-ID: <4E7C984F.4010504@ptfs-europe.com>

On 23/09/11 10:07, Alex Arnaud wrote:

> I've not had time to read all in this topic, then sorry if you already
> told about my problem.
> 
> I got an error when going to the biblio_framework page in koha.
> "unexpected token (marc) [% grille marc %] at
> /home/users/koha/versions/community/C4/Templates.pm line 119."
> 
> [% grille marc %] is simply the french tranlation of [% frameworkcode %]
> in the english template. I've modified the EN Template to add
> parenthesis around 'framwork' and it has not been translated to 'grille
> marc'. good.
> 
> Then i think it would be better to do the same for each variables in
> each template but, strangely, in the same template, few lines later
> another [% frameworkcode %] has not been translated to [% grille marc
> %]. I don't know why ...
> 
> 
Its not a case of the bug reported as bug 6458?
C.


-- 
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 at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com

From chrisc at catalyst.net.nz  Fri Sep 23 23:01:28 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Sat, 24 Sep 2011 09:01:28 +1200
Subject: [Koha-devel] Why is it so cold in here? Oh the features are all
	frozen
Message-ID: <20110923210128.GX3571@rorohiko.wgtn.cat-it.co.nz>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20110924/bf57cdb3/attachment.pgp>

From gbarniskis at gmail.com  Mon Sep 26 03:33:19 2011
From: gbarniskis at gmail.com (Greg Barniskis)
Date: Sun, 25 Sep 2011 20:33:19 -0500
Subject: [Koha-devel] re-introducing myself
Message-ID: <CAJ3gSkR3_68CBTxuMbvHPTXze+aZ+K1OWmX0n4dy036=7z+LUQ@mail.gmail.com>

Hello all,

Some of you may recognize my name from the context of my long-time
employment at a leading Wisconsin public library system. My employer
has a contract with LibLime to develop LibLime Koha in ways specific
to their business needs as a very large public library consortium.
That's not really central to my job description there; I am a
technology integrator, a generalist for a pretty wide and deep tech
stack that happens to include LibLime Koha. I mainly get to watch, and
sometimes assist in integrating the outcomes of that contractual
development process.

I only bring up that subject so that I may acknowledge it as loosely
relevant in an environmental way (I know some of what I know because
of where I work), but then to really emphasize how little my employer
or its vendor relationship has to do with my reasons for writing this
today, or for that matter anything else that I may write in the
future. Just to be clear, when I'm writing things or contributing code
from my personal gmail address, I'm doing it on my own time, on my own
equipment, for my own reasons in my own context as an informed private
citizen.

Anyway, I have decided that, all forkiness aside, I would like to
contribute code and other content to the Koha community via the
community's selected tools for bugs, wiki, git, etc. To that end I
have registered for accounts on k-c bugs and wiki, and have for a long
time now been subscribed to the devel and patches email lists (I
sometimes even grok what passes on them =).

I've been using Perl as an all-purpose utility glue for quite a few
years, doing mostly smallish scripts for unix and windows systems
management. My most celebrated Perl achievement: low-jacking my
employer's old Sun server print spool in order to digitally shred its
venerable but verbose Dynix Classic ILS greenbar paper reports
directly into Excel spreadsheets on no paper. The customers seemed to
really like that trick.

In more recent years, I've also been using Perl a lot with
HTML::Template and with DBI for lots of different Access, MySQL and
Postgres contexts, all on relatively small scales. I don't really know
any Template::Toolkit yet, but I have the ora book for it and expect
the transition won't be too traumatic. I'm new to Git, but have read
enough of the relevant Koha wiki pages to think that I have now
correctly checked out the current development HEAD to play with,
formatted my first patch file, and eventually even got that first
patch emailed to the patches list (I think).

I expect I'll be limiting my contributions to low hanging fruit in the
short term, until I get a bit more comfortable with Git and Koha
internals. For now, I just wanted to say hi, and that I plan to begin
submitting small bug fixes soon and various enhancements someday, and
that I'm doing so from a context strictly unrelated to my employment.

Thanks to those who helped me get started on irc today (and to those
who will undoubtedly have to clean up my Git newbie mistakes tomorrow
=).

From magnus at enger.priv.no  Mon Sep 26 09:41:28 2011
From: magnus at enger.priv.no (Magnus Enger)
Date: Mon, 26 Sep 2011 09:41:28 +0200
Subject: [Koha-devel] 2011-10-07 Global bug squashing day - 3.6 String
	Freeze Sprint
Message-ID: <CABg6UYFut6Spfuwi-Oi=XG8RpyQH7qN_ZmLX2LGgzqwnBDUEVA@mail.gmail.com>

Dear Community!

String freeze for 3.6 has been set to 8 October 23:59 UTC.

I'd like to propose a Global bug squashing day for October 7th, as a
last, concerted effort to get as much as possible from the "needs
signoff" queue into 3.6. Details are here:

http://wiki.koha-community.org/wiki/2011-10-07_Global_bug_squashing_day

Happy squashing!
Magnus Enger

From ian.walls at bywatersolutions.com  Mon Sep 26 13:53:19 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Mon, 26 Sep 2011 07:53:19 -0400
Subject: [Koha-devel] re-introducing myself
In-Reply-To: <CAJ3gSkR3_68CBTxuMbvHPTXze+aZ+K1OWmX0n4dy036=7z+LUQ@mail.gmail.com>
References: <CAJ3gSkR3_68CBTxuMbvHPTXze+aZ+K1OWmX0n4dy036=7z+LUQ@mail.gmail.com>
Message-ID: <CAE2wdZy8RodLbxcfFw8UaJxRyPPjSrnT+bGPfzTv8Y21DbhGeg@mail.gmail.com>

Greg,


Welcome, welcome, welcome!  Always glad to have another private citizen take
up the call and choose to become part of the development community for
Koha.  It sounds like you're already well on your way, so I'll refrain from
offering any advice or recommendations.  Your plan to tackle low-hanging
fruit sounds very good to me, and I look forward to seeing your patches.

As I'm sure you're aware, Koha has just entered the "feature freeze" portion
of the 3.6 development cycle, so any patches you submit that introduce new
features will be held until after the Oct. 22nd release of Koha 3.6.  So, if
your submitted feature seems "stuck" for a while, that's why.  Bug fixes
are, of course, fair game, and greatly appreciated.

If you'd like some Git practice, you can always test submitted patches and
send them back with your sign-off.  A list of patches that need a signoff
can be found here:
http://bugs.koha-community.org/bugzilla3/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=cf_patch_status&query_format=advanced&type0-0-0=equals&value0-0-0=Needs%20Signoff&title=Bug%20List:%20Needs%20Signoff.

Cheers,


-Ian
(sekjal in IRC)

On Sun, Sep 25, 2011 at 9:33 PM, Greg Barniskis <gbarniskis at gmail.com>wrote:

> Hello all,
>
> Some of you may recognize my name from the context of my long-time
> employment at a leading Wisconsin public library system. My employer
> has a contract with LibLime to develop LibLime Koha in ways specific
> to their business needs as a very large public library consortium.
> That's not really central to my job description there; I am a
> technology integrator, a generalist for a pretty wide and deep tech
> stack that happens to include LibLime Koha. I mainly get to watch, and
> sometimes assist in integrating the outcomes of that contractual
> development process.
>
> I only bring up that subject so that I may acknowledge it as loosely
> relevant in an environmental way (I know some of what I know because
> of where I work), but then to really emphasize how little my employer
> or its vendor relationship has to do with my reasons for writing this
> today, or for that matter anything else that I may write in the
> future. Just to be clear, when I'm writing things or contributing code
> from my personal gmail address, I'm doing it on my own time, on my own
> equipment, for my own reasons in my own context as an informed private
> citizen.
>
> Anyway, I have decided that, all forkiness aside, I would like to
> contribute code and other content to the Koha community via the
> community's selected tools for bugs, wiki, git, etc. To that end I
> have registered for accounts on k-c bugs and wiki, and have for a long
> time now been subscribed to the devel and patches email lists (I
> sometimes even grok what passes on them =).
>
> I've been using Perl as an all-purpose utility glue for quite a few
> years, doing mostly smallish scripts for unix and windows systems
> management. My most celebrated Perl achievement: low-jacking my
> employer's old Sun server print spool in order to digitally shred its
> venerable but verbose Dynix Classic ILS greenbar paper reports
> directly into Excel spreadsheets on no paper. The customers seemed to
> really like that trick.
>
> In more recent years, I've also been using Perl a lot with
> HTML::Template and with DBI for lots of different Access, MySQL and
> Postgres contexts, all on relatively small scales. I don't really know
> any Template::Toolkit yet, but I have the ora book for it and expect
> the transition won't be too traumatic. I'm new to Git, but have read
> enough of the relevant Koha wiki pages to think that I have now
> correctly checked out the current development HEAD to play with,
> formatted my first patch file, and eventually even got that first
> patch emailed to the patches list (I think).
>
> I expect I'll be limiting my contributions to low hanging fruit in the
> short term, until I get a bit more comfortable with Git and Koha
> internals. For now, I just wanted to say hi, and that I plan to begin
> submitting small bug fixes soon and various enhancements someday, and
> that I'm doing so from a context strictly unrelated to my employment.
>
> Thanks to those who helped me get started on irc today (and to those
> who will undoubtedly have to clean up my Git newbie mistakes tomorrow
> =).
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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 at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110926/2a3b9fd9/attachment.htm>

From gbarniskis at gmail.com  Mon Sep 26 15:28:05 2011
From: gbarniskis at gmail.com (Greg Barniskis)
Date: Mon, 26 Sep 2011 08:28:05 -0500
Subject: [Koha-devel] re-introducing myself
In-Reply-To: <CAE2wdZy8RodLbxcfFw8UaJxRyPPjSrnT+bGPfzTv8Y21DbhGeg@mail.gmail.com>
References: <CAJ3gSkR3_68CBTxuMbvHPTXze+aZ+K1OWmX0n4dy036=7z+LUQ@mail.gmail.com>
	<CAE2wdZy8RodLbxcfFw8UaJxRyPPjSrnT+bGPfzTv8Y21DbhGeg@mail.gmail.com>
Message-ID: <CAJ3gSkTRrDP1Y1vMz_DHBR17sSbLbe2R=vb5_JTT2NrDinmv2g@mail.gmail.com>

On Mon, Sep 26, 2011 at 6:53 AM, Ian Walls
<ian.walls at bywatersolutions.com> wrote:

> As I'm sure you're aware, Koha has just entered the "feature freeze"...

Understood. And more likely, some of my submissions may get stuck due
to my own deficiencies. I understand the nature of QA is that some
patches get sent back down to the minor leagues for remediation before
they are pushed. No worries.

I am still on the shallow end of a pretty long learning curve. Like
bugs 6914 and 6915 that I filed yesterday, I'll be starting with
smallish fixes for things that happen to bite me or otherwise cause
annoyance when I poke them. I do have some feature areas where I have
enhancements in mind, but no sense of hurry about getting there.


> If you'd like some Git practice, you can always test submitted patches and
> send them back with your sign-off.? A list of patches that need a signoff
> can be found here:
> http://bugs.koha-community.org/bugzilla3/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=cf_patch_status&query_format=advanced&type0-0-0=equals&value0-0-0=Needs%20Signoff&title=Bug%20List:%20Needs%20Signoff

That is very helpful, thanks. I definitely need more git practice, and
more Bugzilla practice. I've taken the liberty of linking that bug
status query as a "See Also" to the related workflow document:
http://wiki.koha-community.org/wiki/Sign_off_on_patches.

From danielg.koha at gmail.com  Mon Sep 26 19:51:48 2011
From: danielg.koha at gmail.com (Daniel Grobani)
Date: Mon, 26 Sep 2011 10:51:48 -0700
Subject: [Koha-devel] Official Koha Newsletter : Volume 2,
	Issue 9: September 2011
Message-ID: <CAOeKewjh4qcxf0D3TYBHW2zYnkZuvspLyLn3o5BA0ALJwv0wJA@mail.gmail.com>

[Below is the text of the newsletter. For active links and a more readable
format, please visit
http://koha-community.org/koha-newsletter-volume-2issue-9-september-2011]

Official Koha Newsletter (ISSN 2153-8328)
Volume 2, Issue 9: September 2011

Edited by Daniel Grobani, Koha Community Newsletter Editor.
Please submit news items to danielg.koha at gmail.com.

Table of Contents

    Koha Developments
        Koha 3.4.5 Release Delayed
        Koha 3.6 Feature Freeze
        Koha 3.8 Roles
        New Database Schema Site
    Koha Community
        New Koha Libraries
        Community Gossip
    Past Koha Events
        Global Bug Squashing Day #4
        September General IRC Meeting
    Upcoming Koha Events
        Global Bug Squashing Day
        October General IRC Meeting
        KohaCon11
        KohaCon12: Voting on Proposals

Koha Developments

Koha 3.4.5 Release Delayed

Chris Nighswonger, Koha 3.4.x release maintainer, reports that the release
of Koha 3.4.5, originally scheduled for 22 October, has been delayed a few
days.

Koha 3.6 Feature Freeze
by Chris Cormack

Why is it so cold in here? We are in feature freeze leading up to next
month?s 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 on 8 October, and the more we get signed off by then, the better.

Koha 3.8 Roles
by Paul Poulain

A reminder: Everyone who plans to volunteer for a position in Koha version
3.8 is welcome to file his/her name on the wiki page:
http://wiki.koha-community.org/wiki/Roles_for_3.8.

The specific module maintainers and release maintainer positions are
(desperately) empty.

Elections will be held in October.

New Database Schema Site
by Chris Cormack

For everyone who writes reports, or develops on Koha, we have a new site
available to help: http://schema.koha-community.org.

This, combined with the work Nicole has been doing to add comments, allows
for nice information like this:
http://schema.koha-community.org/tables/biblio.html.

It is up to date with master (what will be 3.6.0 on October 22), and will
continue to track master thereafter.

Thanks to Robin for rediscovering SchemaSpy and to Nicole for adding
comments.
Koha Community

New Koha Libraries

    Arcadia University (via ByWater Solutions)
    College of the Redwoods (via ByWater Solutions)
    Ducks Unlimited Canada (via Equinox Software)
    Mississippi Department of Archives and History (via ByWater Solutions)
    New Zealand State Services Commission (via Catalyst IT)
    New Zealand Treasury Department (via Catalyst IT)

Community Gossip

Thatcher Rea joined ByWater Solutions as their Lead Support Specialist.

Paul Poulain of BibLibre is convening a working group to address integrating
solR and a re-implementation of Zebra into Koha 4.0.

Vandana Singh of University of Tennessee Knoxville is seeking people to
interview for a study comparing technical support of open source ILSs and
proprietary ILSs. For more info, or to participate, see
http://www.facebook.com/pages/OSS-Lib-Tech/111245305579507.

Bones 1: Nicole Engard is recovering from hip replacement surgery.

Bones 2: Koustubha Kale is recovering from a broken arm and wrist.

Six Koha libraries are jointly sponsoring development of customizable print
slips.
Past Koha Events

Global Bug Squashing Day #4

Global Bug Squashing Day #4 occured on 2 September.

For more info, see
http://wiki.koha-community.org/wiki/2011-09-02_Global_bug_squashing_day.

September General IRC Meeting

The September general IRC meeting was held on 7 September 2011.

For more info, including links to the minutes, see
http://wiki.koha-community.org/wiki/General_IRC_Meeting,_7_September_2011.
Upcoming Koha Events

Global Bug Squashing Day

by Magnus Enger

String freeze for 3.6 has been set to 8 October 23:59 UTC.

I?d like to propose a Global bug squashing day for October 7th, as a last,
concerted effort to get as much as possible from the ?needs signoff? queue
into 3.6. Details are here:
http://wiki.koha-community.org/wiki/2011-10-07_Global_bug_squashing_day.

Happy squashing!

October General IRC Meeting

The next general IRC meeting is 5 October 2011 1000 UTC.

Here?s the agenda as of publication time:

    Introductions
    Update on Roadmap to 3.4
    Update on Roadmap to 3.6
    Vote for Roles for 3.8
    KohaCon2011
    Results of the Vote for KohaCon2012
    Global bug squashing days
    Actions from General IRC Meeting, 7 September 2011
    Miscellaneous
        Follow-up on koha-devel thread ?bugzilla & default assignee?.
suggestion made : add koha-devel at lists.koha-community.org as a possible
assignee for bugs the default assignee don?t want to handle. Adopt this
proposition? any other proposition?
        Gamification and Open Badges
    Set time of next meeting

For more info, see
http://wiki.koha-community.org/wiki/General_IRC_Meeting,_5_October_2011.

KohaCon11

KohaCon11 will be held 31 October 2011 to 6 November 2011 in Thane, India.

For more info, see http://wiki.koha-community.org/wiki/Category:KohaCon11 or
http://kohacon11.vpmthane.org/ocs/index.php/k/k11.

KohaCon12: Voting on Proposals

by Magnus Enger
The deadline for proposals for KohaCon12 ended on 1 September, and we have
two proposals:

    software.coop and other tbc: Edinburgh, Scotland, UK
    Washoe County Library System: Reno, NV USA

Details on the proposals are at
http://wiki.koha-community.org/wiki/Proposals_for_KohaCon12.

Nicole Engard has created a survey where folks can vote on their preference:
http://survey.web2learning.net/limesurvey/index.php?sid=63529.

The deadline for voting is 1 October.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110926/f7f17db1/attachment-0001.htm>

From cnighswonger at foundations.edu  Tue Sep 27 13:44:04 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Tue, 27 Sep 2011 07:44:04 -0400
Subject: [Koha-devel] Koha 3.4.5 is now available
Message-ID: <CAP3yOonD+-Eb+p-NuExwT4r3-s9gv+GMZvG5Yg=LraH4mJ8asg@mail.gmail.com>

It is with pleasure that I announce the release of Koha 3.4.5.

The package can be retrieved from:

http://download.koha-community.org/koha-3.04.05.tar.gz

You can use the following checksum and signature files to verify the download:

http://download.koha-community.org/koha-3.04.05.tar.gz.MD5
http://download.koha-community.org/koha-3.04.05.tar.gz.MD5.asc
http://download.koha-community.org/koha-3.04.05.tar.gz.sig

Release notes for 3.4.5 are below.

Come and get it!

RELEASE NOTES FOR KOHA 3.4.5 - 26 September 2011
========================================================================

Koha is the first free and open source software library automation package
(ILS). Development is sponsored by libraries of varying types and sizes,
volunteers, and support companies from around the world.
The website for the Koha project is

? ?http://koha-community.org/

Koha 3.4.5 can be downloaded from:

? ?http://download.koha-community.org/koha-3.04.05.tar.gz

Installation instructions can be found at:

? ?http://wiki.koha-community.org/wiki/Installation_Documentation

? ?OR in the INSTALL files that come in the tarball

Koha 3.4.5 is a bugfix/maintenance release.

Highlights of 3.4.5
======================

4122 ? ?blocker ? ? WebBasedSelfCheck doesn't control anything
6704 ? ?critical ? ?merging records cuts off fields at quotation marks
6727 ? ?critical ? ?can't import frameworks
6750 ? ?critical ? ?Guarantor search broken on translated templates
4419 ? ?major ? ? ? Cannot change module for notice templates
4966 ? ?major ? ? ? no way to finish receiving
6318 ? ?major ? ? ? fields missing when editing a layout
6351 ? ?major ? ? ? Cannot delete library-specific circulation rules
6620 ? ?major ? ? ? Sip Server Output may be buffered
6651 ? ?major ? ? ? koha-upgrade-to-3.4 fails when multiple instances
are present
6665 ? ?major ? ? ? advancedMARCeditor preference not functioning
6765 ? ?major ? ? ? Enable correct checksums for UTF-8 encoded data
6834 ? ?major ? ? ? $template->{param_map} is deprecated with the
introduction of Template::Toolkit
6841 ? ?major ? ? ? A member with cataloging permissions cannot change
branches (when independent branches is set on)


Bugs fixed in 3.4.5
======================

520 ? ? Displaying ALL records
1016 ? ?Crashed mySql tables
1220 ? ?validation problems and usability in lynx
1664 ? ?Installer not picking up missing perl modules
2539 ? ?kohaspsuggest is deprecated, notes outmoded
2775 ? ?Test suite failing after change to cache sysprefs
2891 ? ?Cannot manually enter dates in some report forms
4866 ? ?Optionally enable Change event for item plugins
4868 ? ?Improve controls for cloning and deleting MARC subfields
4877 ? ?Create and update the manual pages for the koha-* scripts.
5028 ? ?Remove references to catmaintain.pl
5252 ? ?Emails & Phones On Patron Add/Edit form
5498 ? ?Standardize markup and style of pagination menus
5524 ? ?Can't delete list from second page of results
5602 ? ?Improve configurability of package building scripts
5866 ? ?At larger hold volume, waitingreserves.pl for all libraries
times out, can cause generalized slowness
6121 ? ?waitingreserves: branchname instead of branch code
6129 ? ?ISSN url param for serialssolutions.com
6256 ? ?Many bib1 attributes missing
6275 ? ?Automated backups of data and config
6368 ? ?unimarc_field_4XX plugin does not work with new templates
6431 ? ?New Circulation modules for Hourly Circulation
6458 ? ?incorrect parsing result in translation processing
6479 ? ?Encoding problem in "recievedlist" when the numbering formula
contains utf-8 characters
6516 ? ?koha-create makes assumptions about borrowernumber of staff user
6517 ? ?koha-create wants "use database" in DEFAULTSQL
6528 ? ?Cataloging search issues - Holdings not displayed in location column
6538 ? ?help on letter.pl is incorrect
6540 ? ?Add more options to koha-create
6555 ? ?only 10 lists in pull down when adding from a bib record
6562 ? ?Reserve request generates unnecessary runtime errors
6595 ? ?Add German translation for purchase suggestion mails
6602 ? ?Reports dictionary doesn't properly recognize text columns
6640 ? ?Template errors in defining default variable values causes
information not to be displayed
6652 ? ?Zip showing in funny place on libraries admin
6656 ? ?Default sort preferences ignored on advanced search
6662 ? ?sort options in opac are dewey specific
6677 ? ?patron stats still refers to debarred
6695 ? ?Layout of patron category add/edit form slightly broken
6696 ? ?New category button broken when no categories defined
6712 ? ?Remove memberofinstitution markup from templates until it can
be completed
6715 ? ?xmlControlField.js always fetches the value_builder xml files
in the "en" directory.
6723 ? ?allow framework import with CRLF
6724 ? ?Holds Ratio does not allow decimals
6726 ? ?When SMS is enabled the messaging table is misaligned
6728 ? ?Table sorter for receiving acquisitions
6732 ? ?Missing Title for Manual Invoice
6733 ? ?printing routing list sends you to main serials page
6744 ? ?Acknowledge the actual es-ES translators
6747 ? ?Additional check in opac-export
6753 ? ?Markup corrections and improvements for label export window
6754 ? ?Improve breadcrumbs on lists pages
6768 ? ?Two unused include files can be removed: error-top.inc and
error-bottom.inc
6791 ? ?editing list with apostrophe loses text
6794 ? ?Broken toggle in member-flags in ie
6822 ? ?RIS export problem in opac-export.pl with parsing the MARC
6829 ? ?Remove two warnings for opac-MARCdetail
6860 ? ?syndetics covers not showing on search results or shelf browse
6863 ? ?covers missing from shelf browse for various services


System requirements
======================

? ?Changes since 3.2:

? ?* Template::Toolkit


Documentation
======================

As of Koha 3.2, the Koha manual is now maintained in DocBook. ?The
home page for Koha documentation is

? ?http://koha-community.org/documentation/

As of the date of these release notes, only the english version of the
Koha manual is available:

? ?http://koha-community.org/documentation/3-4-manual/

The Git repository for the Koha manual can be found at

? ?http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary

Translations
======================

Complete or near-complete translations of the OPAC and staff
interface are available in this release for the following languages:

?* Chinese
?* Danish
?* English (New Zealand)
?* English (USA)
?* French (France)
?* French (Canada)
?* German
?* Greek
?* Hindi
?* Italian
?* Norwegian
?* Portuguese
?* Spanish
?* Turkish

Partial translations are available for various other languages.

The Koha team welcomes additional translations; please see

? ?http://wiki.koha-community.org/wiki/Translating_Koha

for information about translating Koha, and join the koha-translate
list to volunteer:

? ?http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate

The most up-to-date translations can be found at:

? ?http://translate.koha-community.org/

Release Team
======================

The release team for Koha 3.4 is

Release Manager: ? ? ? ?Chris Cormack <chrisc at catalyst.net.nz>
Documentation Manager: ?Nicole C Engard <nengard at gmail.com>
Translation Manager: ? ?Fr??d??ric Demians <frederic at tamil.fr>
Release Maintainer (3.2.x):
? ? ? ? ? ? ? ? ? ? ? ?Chris Nighswonger <cnighswonger at foundations.edu>
Release Maintainer (3.4.x):
? ? ? ? ? ? ? ? ? ? ? ?Chris Nighswonger <cnighswonger at foundations.edu>
QA Manager: ? ? ? ? ? ? Colin Campbell


Credits
======================

We thank the following individuals who contributed patches to
Koha 3.4.5

Tomas Cohen Arazi
Alex Arnaud
Steven Callender
Colin Campbell
Fr??d??rick Capovilla
Chris Cormack
Christophe Croullebois
Fr??d??ric Demians
Nicole C. Engard
Magnus Enger
Katrin Fischer
Srdjan Jankovic
Janusz Kaczmarek
Ulrich Kleiber
Henri-Damien LAURENT
Owen Leonard
Chris Nighswonger
Maxime Pelletier
Paul Poulain
Liz Rea
Marcel de Rooy
Salvador Zaragoza Rubio
Robin Sheat
Ian Walls
Ward van Wanrooij
Brett Wilkins


We regret any omissions. ?If a contributor has been inadvertantly missed,
please send a patch against these release notes to
koha-patches at lists.koha-community.org.

Revision control notes
======================

The Koha project uses Git for version control. ?The current development
version of Koha can be retrieved by checking out the master branch of

? ?git://git.koha-community.org/koha.git

The branch for Koha 3.4.x (i.e., this version of Koha and future bugfix
releases) is 3.4.x.

The next major feature release of Koha will be Koha 3.6.0.

Bugs and feature requests
======================

Bug reports and feature requests can be filed at the Koha bug
tracker at

? ?http://bugs.koha-community.org/


Ehara taku toa i te toa takitahi, engari he toa takitini

From paul.poulain at biblibre.com  Tue Sep 27 15:08:53 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 27 Sep 2011 15:08:53 +0200
Subject: [Koha-devel] Adding rel_3_8 to bugzilla ?
Message-ID: <4E81CAE5.9060108@biblibre.com>

Hello,

As we've now feature frozen, shouldn't we add rel_3_8 for new features
submitted on bugzilla ?
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From cnighswonger at foundations.edu  Tue Sep 27 15:15:15 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Tue, 27 Sep 2011 09:15:15 -0400
Subject: [Koha-devel] Adding rel_3_8 to bugzilla ?
In-Reply-To: <4E81CAE5.9060108@biblibre.com>
References: <4E81CAE5.9060108@biblibre.com>
Message-ID: <CAP3yOonBdiPZcsbDfbjptOPYh9eQaK7SaRpBparS9Fg_fgf5NQ@mail.gmail.com>

On Tue, Sep 27, 2011 at 9:08 AM, Paul Poulain <paul.poulain at biblibre.com> wrote:
> Hello,
>
> As we've now feature frozen, shouldn't we add rel_3_8 for new features
> submitted on bugzilla ?

Sounds like a good idea from here.

Kind Regards,
Chris

From chrisc at catalyst.net.nz  Tue Sep 27 21:13:46 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Wed, 28 Sep 2011 08:13:46 +1300
Subject: [Koha-devel] Adding rel_3_8 to bugzilla ?
In-Reply-To: <CAP3yOonBdiPZcsbDfbjptOPYh9eQaK7SaRpBparS9Fg_fgf5NQ@mail.gmail.com>
References: <4E81CAE5.9060108@biblibre.com>
	<CAP3yOonBdiPZcsbDfbjptOPYh9eQaK7SaRpBparS9Fg_fgf5NQ@mail.gmail.com>
Message-ID: <20110927191346.GI3571@rorohiko.wgtn.cat-it.co.nz>

* Chris Nighswonger (cnighswonger at foundations.edu) wrote:
> On Tue, Sep 27, 2011 at 9:08 AM, Paul Poulain <paul.poulain at biblibre.com> wrote:
> > Hello,
> >
> > As we've now feature frozen, shouldn't we add rel_3_8 for new features
> > submitted on bugzilla ?
> 
> Sounds like a good idea from here.
> 
Done

Chris
-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20110928/274f86b5/attachment.pgp>

From paul.poulain at biblibre.com  Wed Sep 28 11:26:59 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 28 Sep 2011 11:26:59 +0200
Subject: [Koha-devel] tt style point
In-Reply-To: <B452C122-D6CE-4828-830A-823D54640C2D@kohaaloha.com>
References: <4E733D85.9020300@ptfs-europe.com>	<CAE2wdZx4tuGBUxWBZw7bCknooLz7VoLM=rmfroV+N_O9UmhC6Q@mail.gmail.com>	<4E736576.9020306@gmail.com>	<4E7372F4.4090109@ptfs-europe.com>	<F9DD9E28-46AC-4DD0-8934-2E0C0B9BBA71@kohaaloha.com>	<CAP3yOomwiyrsqt2LZH=69=krrUbHQV-iquscd=WFnVUvV3SqzQ@mail.gmail.com>	<ED0B6CC3-2DC8-4CEC-BEF0-DC0AA19F6E6B@kohaaloha.com>	<4E76F8A5.40509@gmail.com>	<44EE2F7E-6B48-4969-A60C-7212DF55B18C@kohaaloha.com>	<4E784C0D.2090308@gmail.com>
	<B452C122-D6CE-4828-830A-823D54640C2D@kohaaloha.com>
Message-ID: <4E82E863.5090204@biblibre.com>

Le 20/09/2011 13:40, Mason James a ?crit :
>> > it is always the same question : who will decide
> we can decide now the koha-devel mailing-list, or as a topic for the next Koha IRC meeting
> 
> 
i've added the topic for the next IRC meeting
http://wiki.koha-community.org/wiki/General_IRC_Meeting,_5_October_2011#Agenda

HTH
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08