From M.de.Rooy at rijksmuseum.nl  Thu Mar  1 10:17:19 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 1 Mar 2012 09:17:19 +0000
Subject: [Koha-devel] Search results numbering in master
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3109548B6C@S-MAIL-1B.rijksmuseum.intra>

Hi all,

Just now I noticed missing the search result numbering in current master.
A "glance" through git brought me to this commit:

commit 706712dd1edebb6eed8b632ca8db4dcd9df39b56
Author: Srdjan Jankovic <srdjan at catalyst.net.nz>
Date:   Mon Jan 23 17:04:02 2012 +1300
    bug_6488: Take in account opachiddenitems when searching in opac
Containing:
-                <td class="select selectcol">[% SEARCH_RESULT.result_number %].</td>


I would love to have them back! Why were they removed?

In the 6488 report there are these references:

1)     I sign off on this with the following caveat: results numbering will have to be revisited (or removed).

2)     The number that was removed is one that was next to the Save tickbox, the ordinal number of the result in the result set. It was removed because it was
awkward to show eg 6 results numbered 3,5,8,13,16,19.

I personally do not favor that adding an optional feature of hiding items removes search results numbering in general. The numbering is very handy. Now everybody loses that while not even using the hidden items feature!

I would suggest that possibly Srdjan (as the author) adds the search results numbering back and only removes it when opachiddenitems is active. This could be provisional while resolving the numbering issue in full.

Any comments?

Marcel

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

From paul.poulain at biblibre.com  Fri Mar  2 15:11:59 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 02 Mar 2012 15:11:59 +0100
Subject: [Koha-devel] bugzilla upgrade
Message-ID: <4F50D52F.8050609@biblibre.com>

Hello koha-devel,

Last night, Chris C. has upgraded bugzilla to version 4.2, that has been
released recently.
You'll see the change in the mails you recieve, they have changed a lot,
and are in HTML. If you don't like that, you can switch back to "text
mode" in your account preferences

There is also a side effect with this upgrade : columns of search
results are back to standard size.
*GALEN* = could you take care of this problem and switch back to larger
columns for component, patch status and version ? thanks


I've read the page with the new features:
http://www.bugzilla.org/releases/4.2/release-notes.html#v42_feat

One look great to me :
Local bug IDs are now valid in the See Also field. Adding such an ID
will also add a reciprocal link in the other bug.

=> with this feature we can link 2 bugs that are related but don't have
a "block" or "is blocked" relationship

Other nice improvements:
* Inactive accounts are no longer displayed in user fields when
user-autocompletion is enabled.
* User-autocompletion is now much faster on installations with many user
accounts.
* The See Also field now accepts URLs pointing to MantisBT, Trac, JIRA
and the sourceforge.net bug trackers.
* Searches: Buglists will now only display the first 500 bugs by
default. It is still possible to display the whole list, though.

Please also note that I made a tiny change, that is not related to the
upgrade:
* the defauls "my bugs" now also returns "patch doesn't apply" bugs

-- 
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  Fri Mar  2 15:29:04 2012
From: mjr at phonecoop.coop (MJ Ray)
Date: Fri, 02 Mar 2012 14:29:04 +0000
Subject: [Koha-devel] bugzilla upgrade
In-Reply-To: <4F50D52F.8050609@biblibre.com>
Message-ID: <E1S3TTk-0008Kf-Sm@petrol.towers.org.uk>

Paul Poulain <paul.poulain at biblibre.com>
> You'll see the change in the mails you recieve, they have changed a lot,
> and are in HTML. If you don't like that, you can switch back to "text
> mode" in your account preferences

That's at the bottom of
http://bugs.koha-community.org/bugzilla3/userprefs.cgi

Have any other site defaults been changed? (If so, could they be
reset to what they used to be, please?)

Nice upgrade apart from the defaults change, though!

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

From paul.poulain at biblibre.com  Fri Mar  2 15:41:39 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 02 Mar 2012 15:41:39 +0100
Subject: [Koha-devel] bugzilla upgrade
In-Reply-To: <E1S3TTk-0008Kf-Sm@petrol.towers.org.uk>
References: <E1S3TTk-0008Kf-Sm@petrol.towers.org.uk>
Message-ID: <4F50DC23.3090405@biblibre.com>

Le 02/03/2012 15:29, MJ Ray a ?crit :
> Have any other site defaults been changed? (If so, could they be
> reset to what they used to be, please?)
I've read the release notes, and haven't noticed anything that has
consequences.


-- 
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 Mar  2 16:23:14 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 02 Mar 2012 16:23:14 +0100
Subject: [Koha-devel] Release Manager newsletter #4, 2012-02
Message-ID: <4F50E5E2.7060003@biblibre.com>

Hello everybody,

I just published my Release Manager newsletter for february
(yes, it's no more february, BUT: if February had 31 days like many
other months, it would be feb, 31th today, so complain to ppl that
decided to have only 28 or 29 days for feb ;-) )

you can read it at:
http://koha-community.org/koha-release-manager-newsletter-4-2012-02/

Happy reading !
-- 
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  Sun Mar  4 22:48:43 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Sun, 4 Mar 2012 16:48:43 -0500
Subject: [Koha-devel] Koha 3.6.4 is now available
Message-ID: <CAP3yOomTzbyKQJGz3wuPeBnqXMwxY9_wcZAAhYMMjFicgdG_1w@mail.gmail.com>

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

The package can be retrieved from:

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

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

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

Release notes for 3.6.4 are below the fold.

Come and get it!

RELEASE NOTES FOR KOHA 3.6.4
22 Feb 2012
========================================================================

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.6.4 can be downloaded from:

    http://download.koha-community.org/koha-3.06.04.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.6.4 is a bugfix/maintenance release.

Highlights of 3.6.4
======================

6488	critical	opachiddenitems not working in master
6634	critical	manager_id not populated when paying fines
6984	critical	Holds Statistics Doesn't Work
7018	critical	need all acq permissions to search
7339	critical	Help System in IE8-9 Does Not Load With 500 Error
7359	critical	Begin migration to a new "Koha" namespace from the old
"C4" namespace
7432	critical	Changing frameworks should refresh cache
7450	critical	Missing placeholders in admin/authorised_values.pl
7551	critical	Any logged-in OPAC user can renew items for others using
a properly constructed URL
2012	major		Add bilio crashes under no zebra
3264	major		Uncloning a dropdown list in MARC authorities/biblio
editor may clear all subfields (see comment 17)
5327	major		Unit tests required for all C4 modules
6115	major		Acquisition reports : date filter & sorting don't work
6490	major		Lost and paid not updated when book is checked out without check-in
6631	major		Unrestricted creation of lists by anonymous users
6718	major		No manager_id saved for writeoff of fines
6842	major		Branch transfer limits broken
7005	major		no confirmation for write off all
7431	major		OPAC item hold list doesn't show 'checked out'
7459	major		Can only add to one public list in OPAC search results


Bugs fixed in 3.6.4
======================

5473	normal		952 fields should be filled in by Acquisitions
6598	normal		OPACFineNoRenewals syspreference does not stop user
renewing in opac
6694	normal		Anonymous sessions not kept when casAuthentication is on
7114	normal		Hiding filters on funds page messes with layout
7127	normal		Templates must be valid XHTML
7190	normal		written off fines being refunded
7350	normal		In New order the "+" button duplicates input text but not
the "selected" in ddl
7402	normal		invoice not showing received titles
7406	normal		saved reports not showing right number
7409	normal		Missing dependencies for Debian package
7457	normal		basket.pl makes a lot of noise in the logs
7466	normal		Cart notification popup should appear onscreen even when
button is offscreen
7472	normal		Edit button ineffective when paying borrower fee
7476	normal		Files executable that probably should not be
7489	normal		Implement DisplayOPACiconsXSLT for NORMARC XSLT
7501	normal		OPAC authority browser should mark alternate rows as highlighted
7521	normal		Cannot receive serials without full serials permissions
4376	enhancement	A minor change in the ???GetMarcAuthors??   function
of C4/Biblio.pm would allow differentiate the type of authors in the
templates
5346	enhancement	Linking suggestions & orders
6210	enhancement	Choose framework on Merge
6299	enhancement	Provide a list of authorized values for relator terms
6314	enhancement	UNIMARC OPAC XSL improvements
6323	enhancement	Attach/move items - adding option "try again" after
success or wrong barcode
6752	enhancement	Be stricter with utf-8 output
6790	enhancement	C4::Serials::getroutinglist returns unnecessary variable
6838	enhancement	Filtering and pagination in subscriptions table
6865	enhancement	Replace image-based gradient backgrounds with CSS3 gradients
6913	enhancement	Improving koha-list and koha-create
6985	enhancement	Hide "kw,wrdl:" from Search Results
7080	enhancement	Clean up interface on fine payment screens
7083	enhancement	Show creator name on list of public lists
7090	enhancement	Add "AllowItemsOnHandCheckout" syspref to allow issue
to the patron regardless of hold status
7148	enhancement	Add some error handling to Acquisitions' Z39.50
search to match Cataloging's
7157	enhancement	Improve the j2a.pl cronjob
7201	enhancement	Hold to pull report needs extra fields
7246	enhancement	rebuild_zebra.pl --limit option to allow partial re-indexing
7289	enhancement	edition statement field
7343	enhancement	search tag usability in MARC framework
7345	enhancement	Should be possible to export MARC records without
private fields
7355	enhancement	Note subfields are not displayed in TEXTAREA if hidden
7357	enhancement	Subscriptions titles are replaced by "---" when duplicated
7458	enhancement	New call number allocation plugin
7511	enhancement	Caching Templates
7514	enhancement	Choose OPAC language with URL parameter
7532	enhancement	opac-ics depends on Date::ICal which is largely unmaintained


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

    Changes since 3.4:

    * Perl 5.10 is required


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://manual.koha-community.org/3.6/en/

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 (Taiwan)
  * Danish
  * English (USA)
  * English (UK)
  * French (France)
  * German
  * Italian
  * Portuguese (Brazil)
  * Spanish

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.6 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>
QA Manager:             Ian Walls <ian.walls at bywatersolutions.com>
Bug Wranglers:          MJ Ray, Marcel de Rooy, Paul Poulain, Mason James

Release Maintainer (3.4.x):
                        Chris Nighswonger <cnighswonger at foundations.edu>
Release Maintainer (3.6.x):
                        Chris Nighswonger <cnighswonger at foundations.edu>



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

We thank the following libraries who are known to have sponsored
new features in Koha 3.6:
  * Los Gatos Public Library
  * NEKLS
  * East Brunswick Public Library
  * Athens County Public Libraries
  * Horowhenua Library Trust
  * Halton Borough Council
  * South Taranaki District Council

We thank the following individuals who contributed patches to
Koha 3.6.4.

     3	Tomas Cohen Arazi
     1	Alex Arnaud
     2	D Ruth Bavousett
     3	Jared Camins-Esakov
     2	Colin Campbell
     7	Garry Collum
    11	Chris Cormack
     1	Christophe Croullebois
     1	St??phane Delaune
     8	Fr??d??ric Demians
     1	Connor Dewar
     1	Jonathan Druart
     1	Nicole Engard
     1	Magnus Enger
     4	Katrin Fischer
     2	Kyle M Hall
     2	Kate Henderson
     7	Srdjan Jankovic
     1	Bart Jorgensen
     1	Janusz Kaczmarek
     1	Jorgia Kelsey
     1	Henri-Damien Laurent
    13	Owen Leonard
     1	Peter Lorimer
     5	Julian Maurice
     1	Matthias Meusburger
     2	Jono Mingard
    31	Chris Nighswonger
     2	Maxime Pelletier
    26	Paul Poulain
     1	MJ Ray
     7	Liz Rea
     5	Marcel de Rooy
     5	Sam Sanders
     3	Adrien Saurat
     6	Robin Sheat
     1	Juan Sieira
     1	Duncan Tyler
     2	Aleksa Vujicic
     1	biblibre


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.6.x (i.e., this version of Koha and future bugfix
releases) is 3.6.x.

The next major feature release of Koha will be Koha 3.8.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

##### Autogenerated release notes updated last on 22 Feb 2012 20:14:40 Z #####

From pratik.malhotra at fountainheadschools.org  Mon Mar  5 05:53:44 2012
From: pratik.malhotra at fountainheadschools.org (Pratik Malhotra)
Date: Mon, 5 Mar 2012 10:23:44 +0530
Subject: [Koha-devel] Google Apps integration
Message-ID: <CAKYb74kCbKTkrKCFzj8cd4XrgfKX_FyxcNEgqTyk6tbFFjMUNw@mail.gmail.com>

Hello all,

I am looking for someone who can do some development in Koha for me.

My users should be able to login koha using their google apps email ids.
Please let me know if anybody is interested.

Thanks

Pratik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120305/2a93759e/attachment.htm>

From kyle.m.hall at gmail.com  Mon Mar  5 13:30:49 2012
From: kyle.m.hall at gmail.com (Kyle Hall)
Date: Mon, 5 Mar 2012 07:30:49 -0500
Subject: [Koha-devel] Google Apps integration
In-Reply-To: <CAKYb74kCbKTkrKCFzj8cd4XrgfKX_FyxcNEgqTyk6tbFFjMUNw@mail.gmail.com>
References: <CAKYb74kCbKTkrKCFzj8cd4XrgfKX_FyxcNEgqTyk6tbFFjMUNw@mail.gmail.com>
Message-ID: <CACpVHfwjK6PxH=08eaypv4h9CTH0Jmb6T3U=bGp=KYL1972Tcw@mail.gmail.com>

It sounds like you might want to just add openid support instead. That
would allow not only gmail address, but also the use of any other
openid provider.

Kyle


2012/3/4 Pratik Malhotra <pratik.malhotra at fountainheadschools.org>:
> Hello all,
>
> I am looking for someone who can do some development in Koha for me.
>
> My users should be able to login koha using their google apps email ids.
> Please let me know if anybody is interested.
>
> Thanks
>
> Pratik
>
> _______________________________________________
> 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 pratik.malhotra at fountainheadschools.org  Mon Mar  5 13:36:00 2012
From: pratik.malhotra at fountainheadschools.org (Pratik Malhotra)
Date: Mon, 5 Mar 2012 18:06:00 +0530
Subject: [Koha-devel] Google Apps integration
In-Reply-To: <CACpVHfwjK6PxH=08eaypv4h9CTH0Jmb6T3U=bGp=KYL1972Tcw@mail.gmail.com>
References: <CAKYb74kCbKTkrKCFzj8cd4XrgfKX_FyxcNEgqTyk6tbFFjMUNw@mail.gmail.com>
	<CACpVHfwjK6PxH=08eaypv4h9CTH0Jmb6T3U=bGp=KYL1972Tcw@mail.gmail.com>
Message-ID: <CAKYb74koG1W-FHpvTg17LExaDd+zJ8TPE1C259_cXXbfL5sJiA@mail.gmail.com>

that will also do kyle...but i am searching for someone who can or already
has done this thing.

On Mon, Mar 5, 2012 at 6:00 PM, Kyle Hall <kyle.m.hall at gmail.com> wrote:

> It sounds like you might want to just add openid support instead. That
> would allow not only gmail address, but also the use of any other
> openid provider.
>
> Kyle
>
>
> 2012/3/4 Pratik Malhotra <pratik.malhotra at fountainheadschools.org>:
> > Hello all,
> >
> > I am looking for someone who can do some development in Koha for me.
> >
> > My users should be able to login koha using their google apps email ids.
> > Please let me know if anybody is interested.
> >
> > Thanks
> >
> > Pratik
> >
> > _______________________________________________
> > 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/20120305/0fff18bf/attachment.htm>

From oleonard at myacpl.org  Mon Mar  5 14:29:56 2012
From: oleonard at myacpl.org (Owen Leonard)
Date: Mon, 5 Mar 2012 08:29:56 -0500
Subject: [Koha-devel] Google Apps integration
In-Reply-To: <CAKYb74koG1W-FHpvTg17LExaDd+zJ8TPE1C259_cXXbfL5sJiA@mail.gmail.com>
References: <CAKYb74kCbKTkrKCFzj8cd4XrgfKX_FyxcNEgqTyk6tbFFjMUNw@mail.gmail.com>
	<CACpVHfwjK6PxH=08eaypv4h9CTH0Jmb6T3U=bGp=KYL1972Tcw@mail.gmail.com>
	<CAKYb74koG1W-FHpvTg17LExaDd+zJ8TPE1C259_cXXbfL5sJiA@mail.gmail.com>
Message-ID: <CAO4qe2PDNWJS2btwO5i-1mJ4x9UCUNJofMizc8qgPt9i96uAhA@mail.gmail.com>

2012/3/5 Pratik Malhotra <pratik.malhotra at fountainheadschools.org>:
> that will also do kyle...but i am searching for someone who can or already
> has done this thing.

If anyone has done it already they have neither shared the code nor
told anyone about it. This would be a good place to start:

http://koha-community.org/support/paid-support/

  -- Owen

-- 
Web Developer
Athens County Public Libraries
http://www.myacpl.org

From claire.hernandez at biblibre.com  Mon Mar  5 17:12:09 2012
From: claire.hernandez at biblibre.com (Claire Hernandez)
Date: Mon, 05 Mar 2012 17:12:09 +0100
Subject: [Koha-devel] Blog post about BibLibre development rebases
Message-ID: <4F54E5D9.1040704@biblibre.com>

Hello all,

I wrote a blog post about our developments and the community 
integration. You can read it here: 
http://drupal.biblibre.com/en/blog/entry/biblibre-developpments-rebase-and-you

It is about:
- 2012 goals development rebases
- Vision and roadmap
- Progress and learnt of january and february
- Why the community needs you

The purpose was to make visible our work and explain how people can 
invest into this development integration (for example for our french 
customers).

If you have questions, juste ask.

Have a good day,
Claire;

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

From fridolyn.somers at gmail.com  Tue Mar  6 09:03:50 2012
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Tue, 6 Mar 2012 09:03:50 +0100
Subject: [Koha-devel] Google Apps integration
In-Reply-To: <CAO4qe2PDNWJS2btwO5i-1mJ4x9UCUNJofMizc8qgPt9i96uAhA@mail.gmail.com>
References: <CAKYb74kCbKTkrKCFzj8cd4XrgfKX_FyxcNEgqTyk6tbFFjMUNw@mail.gmail.com>
	<CACpVHfwjK6PxH=08eaypv4h9CTH0Jmb6T3U=bGp=KYL1972Tcw@mail.gmail.com>
	<CAKYb74koG1W-FHpvTg17LExaDd+zJ8TPE1C259_cXXbfL5sJiA@mail.gmail.com>
	<CAO4qe2PDNWJS2btwO5i-1mJ4x9UCUNJofMizc8qgPt9i96uAhA@mail.gmail.com>
Message-ID: <CAN6cLAWzc8724cG7MF5DeisM3wJRR3SynRprnoxWv_6e+TKi-w@mail.gmail.com>

Hie,

Development can be based on acutal CAS support of Koha.
What might be different with OpenID ?

On Mon, Mar 5, 2012 at 2:29 PM, Owen Leonard <oleonard at myacpl.org> wrote:

> 2012/3/5 Pratik Malhotra <pratik.malhotra at fountainheadschools.org>:
> > that will also do kyle...but i am searching for someone who can or
> already
> > has done this thing.
>
> If anyone has done it already they have neither shared the code nor
> told anyone about it. This would be a good place to start:
>
> http://koha-community.org/support/paid-support/
>
>  -- Owen
>
> --
> Web Developer
> Athens County Public Libraries
> http://www.myacpl.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/
>



-- 
Fridolyn SOMERS
fridolyn.somers at gmail.com
Marsillargues - France
 <fridolyn.somers at gmail.com>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20120306/f0ad7402/attachment.htm>

From tomascohen at gmail.com  Tue Mar  6 13:52:41 2012
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Tue, 6 Mar 2012 09:52:41 -0300
Subject: [Koha-devel] Google Apps integration
In-Reply-To: <CAN6cLAWzc8724cG7MF5DeisM3wJRR3SynRprnoxWv_6e+TKi-w@mail.gmail.com>
References: <CAKYb74kCbKTkrKCFzj8cd4XrgfKX_FyxcNEgqTyk6tbFFjMUNw@mail.gmail.com>
	<CACpVHfwjK6PxH=08eaypv4h9CTH0Jmb6T3U=bGp=KYL1972Tcw@mail.gmail.com>
	<CAKYb74koG1W-FHpvTg17LExaDd+zJ8TPE1C259_cXXbfL5sJiA@mail.gmail.com>
	<CAO4qe2PDNWJS2btwO5i-1mJ4x9UCUNJofMizc8qgPt9i96uAhA@mail.gmail.com>
	<CAN6cLAWzc8724cG7MF5DeisM3wJRR3SynRprnoxWv_6e+TKi-w@mail.gmail.com>
Message-ID: <CABZfb=Wjqp7C1NwONF_ECKZ0k1UL-ZeM6hmH2GG-asTqn6UnBg@mail.gmail.com>

2012/3/6 Fridolyn SOMERS <fridolyn.somers at gmail.com>:
> Hie,
>
> Development can be based on acutal CAS support of Koha.
> What might be different with OpenID ?

I think OpenID means de-centralized authentication, whereas CAS means
SingleSignOn using some kind of token, plus a centralized source of
authentication.

Regards
To+

From paul.poulain at biblibre.com  Tue Mar  6 14:04:34 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 06 Mar 2012 14:04:34 +0100
Subject: [Koha-devel] Google Apps integration
In-Reply-To: <CABZfb=Wjqp7C1NwONF_ECKZ0k1UL-ZeM6hmH2GG-asTqn6UnBg@mail.gmail.com>
References: <CAKYb74kCbKTkrKCFzj8cd4XrgfKX_FyxcNEgqTyk6tbFFjMUNw@mail.gmail.com>
	<CACpVHfwjK6PxH=08eaypv4h9CTH0Jmb6T3U=bGp=KYL1972Tcw@mail.gmail.com>
	<CAKYb74koG1W-FHpvTg17LExaDd+zJ8TPE1C259_cXXbfL5sJiA@mail.gmail.com>
	<CAO4qe2PDNWJS2btwO5i-1mJ4x9UCUNJofMizc8qgPt9i96uAhA@mail.gmail.com>
	<CAN6cLAWzc8724cG7MF5DeisM3wJRR3SynRprnoxWv_6e+TKi-w@mail.gmail.com>
	<CABZfb=Wjqp7C1NwONF_ECKZ0k1UL-ZeM6hmH2GG-asTqn6UnBg@mail.gmail.com>
Message-ID: <4F560B62.8030808@biblibre.com>

Le 06/03/2012 13:52, Tomas Cohen Arazi a ?crit :
> 2012/3/6 Fridolyn SOMERS <fridolyn.somers at gmail.com>:
>> Hie,
>> Development can be based on acutal CAS support of Koha.
>> What might be different with OpenID ?
> I think OpenID means de-centralized authentication, whereas CAS means
> SingleSignOn using some kind of token, plus a centralized source of
> authentication.

Right,

Maybe openID is more related to shibboleth then.

breaking news = BibLibre is working on shibboleth, it should be
submitted soon for integration into Koha.


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

From koha.sekjal at gmail.com  Tue Mar  6 17:03:15 2012
From: koha.sekjal at gmail.com (Ian Walls)
Date: Tue, 6 Mar 2012 11:03:15 -0500
Subject: [Koha-devel] Google Apps integration
In-Reply-To: <4F560B62.8030808@biblibre.com>
References: <CAKYb74kCbKTkrKCFzj8cd4XrgfKX_FyxcNEgqTyk6tbFFjMUNw@mail.gmail.com>
	<CACpVHfwjK6PxH=08eaypv4h9CTH0Jmb6T3U=bGp=KYL1972Tcw@mail.gmail.com>
	<CAKYb74koG1W-FHpvTg17LExaDd+zJ8TPE1C259_cXXbfL5sJiA@mail.gmail.com>
	<CAO4qe2PDNWJS2btwO5i-1mJ4x9UCUNJofMizc8qgPt9i96uAhA@mail.gmail.com>
	<CAN6cLAWzc8724cG7MF5DeisM3wJRR3SynRprnoxWv_6e+TKi-w@mail.gmail.com>
	<CABZfb=Wjqp7C1NwONF_ECKZ0k1UL-ZeM6hmH2GG-asTqn6UnBg@mail.gmail.com>
	<4F560B62.8030808@biblibre.com>
Message-ID: <CANL=k+GK5TXdb+gLW2Y3BS-GXWROtfji4AT84WPZbaf1HUhiYw@mail.gmail.com>

Paul,


Has the work on Shibboleth required a refactoring of C4/Auth?  It's sorely
needed.  Looking forward to testing it out!


-Ian

On Tue, Mar 6, 2012 at 08:04, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Le 06/03/2012 13:52, Tomas Cohen Arazi a ?crit :
> > 2012/3/6 Fridolyn SOMERS <fridolyn.somers at gmail.com>:
> >> Hie,
> >> Development can be based on acutal CAS support of Koha.
> >> What might be different with OpenID ?
> > I think OpenID means de-centralized authentication, whereas CAS means
> > SingleSignOn using some kind of token, plus a centralized source of
> > authentication.
>
> Right,
>
> Maybe openID is more related to shibboleth then.
>
> breaking news = BibLibre is working on shibboleth, it should be
> submitted soon for integration into Koha.
>
>
> --
> 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/20120306/70f156d8/attachment.htm>

From bibliwho at gmail.com  Tue Mar  6 22:50:23 2012
From: bibliwho at gmail.com (Cab Vinton)
Date: Tue, 6 Mar 2012 16:50:23 -0500
Subject: [Koha-devel] Retrieving 10-digit ISBNs in a report
Message-ID: <CABW43UTMwBC7taGvfpWx-GfyR2UUYxuoAAtwdi=Y68JMCJDuYg@mail.gmail.com>

Hi, All --

For the purposes of creating a web-based carousel of book covers of
our recent acquisitions, I'd like to run a report that generates a
list of ISBNs of items added between 2 dates.

Amazon & therefore Koha rely on 10-digit ISBNs for book cover retrieval.

However, when I run a report using biblioitems.isbn, this is the
output I get. Many truncated ISBNs, presumably because the max length
= 30 restriction.

9780425243244 (pbk.) | 0425243
9780307718099 | 0307718093
0804840288 | 9780804840286 (tr
9780811876377 : | 0811876373 :
1569244677
9781400064588 (acidfree paper)
9780061429255 | 0061429252
9781451661064 (hardcover) | 14

Is there a way to run a report that outputs only the 10 digit ISBNs?

Many thanks,

Cab Vinton, Director
Sanbornton Public Library
Sanbornton, NH

From mtj at kohaaloha.com  Wed Mar  7 03:16:32 2012
From: mtj at kohaaloha.com (Mason James)
Date: Wed, 7 Mar 2012 15:16:32 +1300
Subject: [Koha-devel] replace Data::Dumper with faster JSON::XS in Koha?
Message-ID: <6C7C48AE-46B9-4F2D-901A-26C7CCC79412@kohaaloha.com>

i noticed there are a few places in Koha where Data::Dumper is loaded, even if $debug is off, etc
(like the Items and Circ modules)

i wonder if we could replace Data::Dumper with something faster, perhaps...?

like  JSON::XS, YAML::XS or YAML::Tiny

here's some benchmarks and discussions, etc
  http://martin-evans.me.uk/node/42
  http://stackoverflow.com/questions/1876735/should-i-use-yaml-or-json-to-store-my-perl-data


any thoughts, people?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20120307/9e46508d/attachment.pgp>

From vanoudt at gmail.com  Thu Mar  8 06:49:58 2012
From: vanoudt at gmail.com (Nicholas van Oudtshoorn)
Date: Thu, 08 Mar 2012 13:49:58 +0800
Subject: [Koha-devel] Retrieving 10-digit ISBNs in a report
In-Reply-To: <CABW43UTMwBC7taGvfpWx-GfyR2UUYxuoAAtwdi=Y68JMCJDuYg@mail.gmail.com>
References: <CABW43UTMwBC7taGvfpWx-GfyR2UUYxuoAAtwdi=Y68JMCJDuYg@mail.gmail.com>
Message-ID: <jj9ha8$71s$1@dough.gmane.org>

A simple bit of code can be used to get the first valid 10-digit ISBN. 
This is the php code we use - it could be adapted to perl quite easily, 
though.... (Actually, if I recall correctly, there is a C4 function to 
get the Normalised ISBN...)

// Normalise the ISBN
$isbn = preg_replace('/(.*) \| (.*)/', '$1', $isbn); // Get first isbn
$isbn = preg_replace('/(.*) (.*)/', '$1', $isbn); // Get rid of text
if (strlen($isbn) == 11) {
   if ($debugging) { print "Chopping 11 digit ISBN to a 10 digit ISBN"; }
   $isbn = substr($isbn,1,10);
} else if (strlen($isbn) == 13) {
   $isbn = substr($isbn,3,9);
   $checksum = 0;
   $weight = 10;
   $isbnCharArray = str_split($isbn);
   foreach($isbnCharArray as $char) {
     $checksum += $char * $weight;
     $weight--;
   }
   $checksum = 11-($checksum % 11);
   if ($checksum == 10) {
     $isbn += "X";
   } else if ($checksum == 11) {
     $isbn += "0";
   } else {
     $isbn .= $checksum;
   }
} else if (strlen($isbn) != 10) {
   if ($debugging) { print "<p>Illegal ISBN Found: $isbn</p>"; }
     exit;
}
if ($debugging) { print "Normalised ISBN: $isbn"; exit; }


-
Nick

On 03/07/2012 05:50 AM, Cab Vinton wrote:
> Hi, All --
>
> For the purposes of creating a web-based carousel of book covers of
> our recent acquisitions, I'd like to run a report that generates a
> list of ISBNs of items added between 2 dates.
>
> Amazon&  therefore Koha rely on 10-digit ISBNs for book cover retrieval.
>
> However, when I run a report using biblioitems.isbn, this is the
> output I get. Many truncated ISBNs, presumably because the max length
> = 30 restriction.
>
> 9780425243244 (pbk.) | 0425243
> 9780307718099 | 0307718093
> 0804840288 | 9780804840286 (tr
> 9780811876377 : | 0811876373 :
> 1569244677
> 9781400064588 (acidfree paper)
> 9780061429255 | 0061429252
> 9781451661064 (hardcover) | 14
>
> Is there a way to run a report that outputs only the 10 digit ISBNs?
>
> Many thanks,
>
> Cab Vinton, Director
> Sanbornton Public Library
> Sanbornton, NH
> _______________________________________________
> 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 vanoudt at gmail.com  Thu Mar  8 07:01:23 2012
From: vanoudt at gmail.com (Nicholas van Oudtshoorn)
Date: Thu, 08 Mar 2012 14:01:23 +0800
Subject: [Koha-devel] Retrieving 10-digit ISBNs in a report
In-Reply-To: <CABW43UTMwBC7taGvfpWx-GfyR2UUYxuoAAtwdi=Y68JMCJDuYg@mail.gmail.com>
References: <CABW43UTMwBC7taGvfpWx-GfyR2UUYxuoAAtwdi=Y68JMCJDuYg@mail.gmail.com>
Message-ID: <jj9hvk$ajm$1@dough.gmane.org>

Hi Cab,

If it's of any help, the 'carousel of book covers' system we use at 
library.pbc.wa.edu.au is available. It also incorporates our fake book 
cover generating system for books that don't have a cover-image 
available. Rather than generating a report, we chose to extract the data 
directly from SQL...

A (slightly old - if you want the latest version I can get it when I'm 
back on site next week) version of our carousel-generating code can be 
downloaded here:
http://dl.dropbox.com/u/8648526/August2011_librarycoversystem.tar.bz2

(See also the newsgroup archives from 19 August 2011.) The changes that 
have been made since then are mostly cosmetic and to do with tidying the 
code... but I guess that's what important!

If all you're looking for is the SQL, this is what we *were* using. (We 
now show the latest 30 books regardless of date)

SELECT items.biblionumber AS biblionumber, isbn, title, author, 
coverlocation FROM ((items JOIN biblio ON items.biblionumber = 
biblio.biblionumber) JOIN biblioitems on 
items.biblionumber=biblioitems.biblioitemnumber AND 
items.biblioitemnumber=biblioitems.biblioitemnumber) LEFT JOIN 
bibliocovers on items.biblionumber = bibliocovers.biblionumber WHERE 
dateaccessioned > SUBDATE(SYSDATE(), INTERVAL 31 DAY) AND iType='BOOK' 
ORDER BY dateaccessioned DESC";


There's some extra stuff in there, because our cover system generates 
"fake" covers for books that don't actually have an image available. (As 
you'll notice on our library page).

Hope this might be of at least *some* help!

God bless,
Nick

On 03/07/2012 05:50 AM, Cab Vinton wrote:
> Hi, All --
>
> For the purposes of creating a web-based carousel of book covers of
> our recent acquisitions, I'd like to run a report that generates a
> list of ISBNs of items added between 2 dates.
>
> Amazon&  therefore Koha rely on 10-digit ISBNs for book cover retrieval.
>
> However, when I run a report using biblioitems.isbn, this is the
> output I get. Many truncated ISBNs, presumably because the max length
> = 30 restriction.
>
> 9780425243244 (pbk.) | 0425243
> 9780307718099 | 0307718093
> 0804840288 | 9780804840286 (tr
> 9780811876377 : | 0811876373 :
> 1569244677
> 9781400064588 (acidfree paper)
> 9780061429255 | 0061429252
> 9781451661064 (hardcover) | 14
>
> Is there a way to run a report that outputs only the 10 digit ISBNs?
>
> Many thanks,
>
> Cab Vinton, Director
> Sanbornton Public Library
> Sanbornton, NH
> _______________________________________________
> 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 paul.poulain at biblibre.com  Thu Mar  8 09:49:40 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 08 Mar 2012 09:49:40 +0100
Subject: [Koha-devel] Bugs with patch& follow-up
Message-ID: <4F5872A4.1030108@biblibre.com>

Hello all,

Short version:
if you have a bug that has more than 1 patch, PLEASE, keep the in the
apply order

Long version:
As you all know (I hope!), i've developed a system to test patches
online. When you're a librarian, it's easy to try a patch in a few clics.

However, if a bug has more than one patch attached, the system will work
only if they are correctly ordered: the follow-up *must* be after the
initial patch, because the system is automatic, not very intelligent, so
can't detect it's a follow-up if it appears first.

St?phane Delaye wanted to test a bug this morning, and it failed because
of this. I showed him how to reorder patches by downloading/reuploading
patches, but it's better to keep them in the right order.
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From vanoudt at gmail.com  Thu Mar  8 05:58:21 2012
From: vanoudt at gmail.com (Nicholas van Oudtshoorn)
Date: Thu, 08 Mar 2012 12:58:21 +0800
Subject: [Koha-devel] Retrieving 10-digit ISBNs in a report
In-Reply-To: <CABW43UTMwBC7taGvfpWx-GfyR2UUYxuoAAtwdi=Y68JMCJDuYg@mail.gmail.com>
References: <CABW43UTMwBC7taGvfpWx-GfyR2UUYxuoAAtwdi=Y68JMCJDuYg@mail.gmail.com>
Message-ID: <jj9e9e$kfm$1@dough.gmane.org>

Hi Cab,

If it's of any help, the 'carousel of book covers' system we use at 
library.pbc.wa.edu.au is available. Rather than generating a report, we 
chose to extract the data directly from SQL...

A (slightly old - if you want the latest version I can get it when I'm 
back on site next week) version of our carousel-generating code is 
attached. (Also availabe in the newsgroup archives from 19 August 2011.) 
The changes that have been made since then are mostly cosmetic and to do 
with tidying the code... but I guess that's what important!

If all you're looking for is the SQL, this is what we were using:

SELECT items.biblionumber AS biblionumber, isbn, title, author, 
coverlocation FROM ((items JOIN biblio ON items.biblionumber = 
biblio.biblionumber) JOIN biblioitems on 
items.biblionumber=biblioitems.biblioitemnumber AND 
items.biblioitemnumber=biblioitems.biblioitemnumber) LEFT JOIN 
bibliocovers on items.biblionumber = bibliocovers.biblionumber WHERE 
dateaccessioned > SUBDATE(SYSDATE(), INTERVAL 31 DAY) AND iType='BOOK' 
ORDER BY dateaccessioned DESC";


There's some extra stuff in there, because our cover system generates 
"fake" covers for books that don't actually have an image available. (As 
you'll notice on our library page).

Hope this might be of at least *some* help!

God bless,
Nick
> Hi, All --
>
> For the purposes of creating a web-based carousel of book covers of
> our recent acquisitions, I'd like to run a report that generates a
> list of ISBNs of items added between 2 dates.
>
> Amazon & therefore Koha rely on 10-digit ISBNs for book cover retrieval.
>
> However, when I run a report using biblioitems.isbn, this is the
> output I get. Many truncated ISBNs, presumably because the max length
> = 30 restriction.
>
> 9780425243244 (pbk.) | 0425243
> 9780307718099 | 0307718093
> 0804840288 | 9780804840286 (tr
> 9780811876377 : | 0811876373 :
> 1569244677
> 9781400064588 (acidfree paper)
> 9780061429255 | 0061429252
> 9781451661064 (hardcover) | 14
>
> Is there a way to run a report that outputs only the 10 digit ISBNs?
>
> Many thanks,
>
> Cab Vinton, Director
> Sanbornton Public Library
> Sanbornton, NH
> _______________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: coversystem.tar.bz2
Type: application/x-bzip2
Size: 81424 bytes
Desc: not available
URL: </pipermail/koha-devel/attachments/20120308/05d58a05/attachment-0001.bin>

From paul.poulain at biblibre.com  Thu Mar  8 13:59:16 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 08 Mar 2012 13:59:16 +0100
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
Message-ID: <4F58AD24.4060701@biblibre.com>

Hello koha-devel,

I just updated the 3.8 release process with the schedule/planning of the
release: http://wiki.koha-community.org/wiki/Roadmap_to_3.8

Here it is:
March, 23th (1 month before the release) = feature freeze.
April, 6th = strong feature freeze, string freeze
April 20th = starting release process, everything frozen
April 23th = release of Koha 3.8.0

IMPORTANT = perltidy process

In january IRC meeting we spoke of perltidy thing. We have a coding
guideline rule that says code must be perltidied. However, all the
existing code is not perltidied, and it's hard to mix perltidied and non
perltidied code.
Thus, we have investigated the idea of doing a "perltidy big-bang" just
when releasing 3.8.0, for all the code.

Pro:
* the code will be perltidied, the coding guideline will be applicable
* all perltidy being made at the same time, it will be easier to read
the git log. (One of the argument against perltidying is that it's a
problem for reading git history)
* doing that for a release is better for future bugfixes means that
patches will apply on 3.8 as well as on master.

Cons:
* patches that are waiting may become "does not apply" because of the
perltidy thing
* patches submitted to fix bugs in 3.8 may not apply on 3.6 easily, that
will add more work for 3.6 releases.

All in one, our conclusion was that the best solution is to do that
during a release process.
So I plan do it during 3.8 release.

(I have a (small ?) question about that : do you think I should make
only one huge commit with perltidy ? one for each directory ? one for
each file ?)

-- 
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 Mar  8 14:02:12 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 08 Mar 2012 14:02:12 +0100
Subject: [Koha-devel] Google Apps integration
In-Reply-To: <CANL=k+GK5TXdb+gLW2Y3BS-GXWROtfji4AT84WPZbaf1HUhiYw@mail.gmail.com>
References: <CAKYb74kCbKTkrKCFzj8cd4XrgfKX_FyxcNEgqTyk6tbFFjMUNw@mail.gmail.com>
	<CACpVHfwjK6PxH=08eaypv4h9CTH0Jmb6T3U=bGp=KYL1972Tcw@mail.gmail.com>
	<CAKYb74koG1W-FHpvTg17LExaDd+zJ8TPE1C259_cXXbfL5sJiA@mail.gmail.com>
	<CAO4qe2PDNWJS2btwO5i-1mJ4x9UCUNJofMizc8qgPt9i96uAhA@mail.gmail.com>
	<CAN6cLAWzc8724cG7MF5DeisM3wJRR3SynRprnoxWv_6e+TKi-w@mail.gmail.com>
	<CABZfb=Wjqp7C1NwONF_ECKZ0k1UL-ZeM6hmH2GG-asTqn6UnBg@mail.gmail.com>
	<4F560B62.8030808@biblibre.com>
	<CANL=k+GK5TXdb+gLW2Y3BS-GXWROtfji4AT84WPZbaf1HUhiYw@mail.gmail.com>
Message-ID: <4F58ADD4.8030204@biblibre.com>

Le 06/03/2012 17:03, Ian Walls a ?crit :
> Paul,
Ian,
> Has the work on Shibboleth required a refactoring of C4/Auth?  
I don't think so, it's made like CAS auth afaik.

> It's sorely needed.
rewritting Auth IS something needed, definetly, but that won't be
through Shibboleth.

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

From M.de.Rooy at rijksmuseum.nl  Thu Mar  8 14:36:36 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 8 Mar 2012 13:36:36 +0000
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
In-Reply-To: <4F58AD24.4060701@biblibre.com>
References: <4F58AD24.4060701@biblibre.com>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310954B86F@S-MAIL-1B.rijksmuseum.intra>

Hi Paul,
What is the exact procedure? All patches submitted before March 23 or signed-off before March 23 are candidates for the 3.8 release?  If so, how do we separate them easily from the patches submitted later? What is strong feature freeze exactly here? 

About the commits: I would suggest to put multiple files in a perltidy commit, not per file.

Marcel

-----Oorspronkelijk bericht-----
Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Paul Poulain
Verzonden: donderdag 8 maart 2012 13:59
Aan: koha-devel at lists.koha-community.org
Onderwerp: [Koha-devel] Koha 3.8 release schedule & perltidy process

Hello koha-devel,

I just updated the 3.8 release process with the schedule/planning of the
release: http://wiki.koha-community.org/wiki/Roadmap_to_3.8

Here it is:
March, 23th (1 month before the release) = feature freeze.
April, 6th = strong feature freeze, string freeze April 20th = starting release process, everything frozen April 23th = release of Koha 3.8.0

IMPORTANT = perltidy process

In january IRC meeting we spoke of perltidy thing. We have a coding guideline rule that says code must be perltidied. However, all the existing code is not perltidied, and it's hard to mix perltidied and non perltidied code.
Thus, we have investigated the idea of doing a "perltidy big-bang" just when releasing 3.8.0, for all the code.

Pro:
* the code will be perltidied, the coding guideline will be applicable
* all perltidy being made at the same time, it will be easier to read the git log. (One of the argument against perltidying is that it's a problem for reading git history)
* doing that for a release is better for future bugfixes means that patches will apply on 3.8 as well as on master.

Cons:
* patches that are waiting may become "does not apply" because of the perltidy thing
* patches submitted to fix bugs in 3.8 may not apply on 3.6 easily, that will add more work for 3.6 releases.

All in one, our conclusion was that the best solution is to do that during a release process.
So I plan do it during 3.8 release.

(I have a (small ?) question about that : do you think I should make only one huge commit with perltidy ? one for each directory ? one for each file ?)

--
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 paul.poulain at biblibre.com  Thu Mar  8 15:22:19 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 08 Mar 2012 15:22:19 +0100
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310954B86F@S-MAIL-1B.rijksmuseum.intra>
References: <4F58AD24.4060701@biblibre.com>
	<809BE39CD64BFD4EB9036172EBCCFA310954B86F@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <4F58C09B.7050907@biblibre.com>

Le 08/03/2012 14:36, Marcel de Rooy a ?crit :
> Hi Paul,
Hi Marcel,

> What is the exact procedure?
> All patches submitted before March 23 or signed-off before March 23
are candidates for the 3.8 release?
> If so, how do we separate them easily from the patches submitted
later? What is strong feature freeze exactly here?
By "included" I mean "pushed to master". I don't mean "submitted" or
"signed-off".
A major feature that is submitted on march 22nd, signed-off on march 24
won't be in 3.8, it will be delayed to the next release.

[well, if something really cool is QAed on march 24 I may decide to
delay the feature freeze by a day. I'll check bugzilla in the days
before the string freeze and encourage ppl to sign-off/QA. Fortunatly,
the european hackfest take place this week, so we will have many ppl
available to test anything cool ;-) ]

After the 1st "feature freeze" I will still accept small enhancements.
that's why we can call it "soft FF".

After the "strong feature freeze" NO enhancements at all will be added,
to let translator and testers enough time to do their work.

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

From dpavlin at rot13.org  Thu Mar  8 15:53:50 2012
From: dpavlin at rot13.org (Dobrica Pavlinusic)
Date: Thu, 8 Mar 2012 15:53:50 +0100
Subject: [Koha-devel] Google Apps integration
In-Reply-To: <4F58ADD4.8030204@biblibre.com>
References: <CAKYb74kCbKTkrKCFzj8cd4XrgfKX_FyxcNEgqTyk6tbFFjMUNw@mail.gmail.com>
	<CACpVHfwjK6PxH=08eaypv4h9CTH0Jmb6T3U=bGp=KYL1972Tcw@mail.gmail.com>
	<CAKYb74koG1W-FHpvTg17LExaDd+zJ8TPE1C259_cXXbfL5sJiA@mail.gmail.com>
	<CAO4qe2PDNWJS2btwO5i-1mJ4x9UCUNJofMizc8qgPt9i96uAhA@mail.gmail.com>
	<CAN6cLAWzc8724cG7MF5DeisM3wJRR3SynRprnoxWv_6e+TKi-w@mail.gmail.com>
	<CABZfb=Wjqp7C1NwONF_ECKZ0k1UL-ZeM6hmH2GG-asTqn6UnBg@mail.gmail.com>
	<4F560B62.8030808@biblibre.com>
	<CANL=k+GK5TXdb+gLW2Y3BS-GXWROtfji4AT84WPZbaf1HUhiYw@mail.gmail.com>
	<4F58ADD4.8030204@biblibre.com>
Message-ID: <20120308145350.GD4447@rot13.org>

On Thu, Mar 08, 2012 at 02:02:12PM +0100, Paul Poulain wrote:
> Le 06/03/2012 17:03, Ian Walls a ?crit :
> > Paul,
> Ian,
> > Has the work on Shibboleth required a refactoring of C4/Auth?  
> I don't think so, it's made like CAS auth afaik.

I am very interesed in C4/Auth rewrite since it's... mess...

> > It's sorely needed.
> rewritting Auth IS something needed, definetly, but that won't be
> through Shibboleth.

I needed SAML for one of our libraries, so I made cludge to integrate
phpsimplesaml (since it is also used on provider's side), but that
solution if fragile and needs rewrite, so Shibboleth's SAML is probably
the way to go.

Is there code somewhere to take a look?

-- 
Dobrica Pavlinusic               2share!2flame            dpavlin at rot13.org
Unix addict. Internet consultant.             http://www.rot13.org/~dpavlin

From chris at bigballofwax.co.nz  Thu Mar  8 18:30:39 2012
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Fri, 9 Mar 2012 06:30:39 +1300
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
In-Reply-To: <4F58AD24.4060701@biblibre.com>
References: <4F58AD24.4060701@biblibre.com>
Message-ID: <CA+95qVQO1LwHpvQiwLLAs4d6wS9yLCQDMcY9r4j95G18rtWpvw@mail.gmail.com>

On Mar 9, 2012 1:59 AM, "Paul Poulain" <paul.poulain at biblibre.com> wrote:
>
> Hello koha-devel,
>
> I just updated the 3.8 release process with the schedule/planning of the
> release: http://wiki.koha-community.org/wiki/Roadmap_to_3.8
>
> Here it is:
> March, 23th (1 month before the release) = feature freeze.
> April, 6th = strong feature freeze, string freeze
> April 20th = starting release process, everything frozen
> April 23th = release of Koha 3.8.0
>
> IMPORTANT = perltidy process
>
> In january IRC meeting we spoke of perltidy thing. We have a coding
> guideline rule that says code must be perltidied. However, all the
> existing code is not perltidied, and it's hard to mix perltidied and non
> perltidied code.
> Thus, we have investigated the idea of doing a "perltidy big-bang" just
> when releasing 3.8.0, for all the code.
>
> Pro:
> * the code will be perltidied, the coding guideline will be applicable
> * all perltidy being made at the same time, it will be easier to read
> the git log. (One of the argument against perltidying is that it's a
> problem for reading git history)

Doing it in one hit only makes this better if it is possible to have git
blame ignore this commit.

I just want to go on record as disagreeing with this plan. But happy to
abide by community decision I just reserve the right to complain :-)

Chris
> * doing that for a release is better for future bugfixes means that
> patches will apply on 3.8 as well as on master.
>
> Cons:
> * patches that are waiting may become "does not apply" because of the
> perltidy thing
> * patches submitted to fix bugs in 3.8 may not apply on 3.6 easily, that
> will add more work for 3.6 releases.
>
> All in one, our conclusion was that the best solution is to do that
> during a release process.
> So I plan do it during 3.8 release.
>
> (I have a (small ?) question about that : do you think I should make
> only one huge commit with perltidy ? one for each directory ? one for
> each file ?)
>
> --
> 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/20120309/ac9de908/attachment.htm>

From paul.poulain at biblibre.com  Thu Mar  8 18:41:22 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 08 Mar 2012 18:41:22 +0100
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
In-Reply-To: <CA+95qVQO1LwHpvQiwLLAs4d6wS9yLCQDMcY9r4j95G18rtWpvw@mail.gmail.com>
References: <4F58AD24.4060701@biblibre.com>
	<CA+95qVQO1LwHpvQiwLLAs4d6wS9yLCQDMcY9r4j95G18rtWpvw@mail.gmail.com>
Message-ID: <4F58EF42.1020805@biblibre.com>

Le 08/03/2012 18:30, Chris Cormack a ?crit :

> Doing it in one hit only makes this better if it is possible to have git
> blame ignore this commit.

I don't think it's possible.

> I just want to go on record as disagreeing with this plan. But happy to
> abide by community decision I just reserve the right to complain :-)

Well, speaking with Katrin, it seems the decision was not that clear:
http://stats.workbuffer.org/irclog/koha/2012-01-04#i_857956

I'm OK to discuss of it again, but I'd like to have counter proposals.
And if we can't find an option that please everyone, then maybe do
nothing, and remove the rule from the coding guidelines and never
complain again or start a discussion about that (not speaking of new
files here, just existing ones)

I made a list of pro and cons of the "big bang" option, feel free
(everybody) to add another suggestion or complete my pro/cons list

(note: this encouragement is not for chris C. only, but for everybody)
-- 
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  Thu Mar  8 18:49:11 2012
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Fri, 9 Mar 2012 06:49:11 +1300
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
In-Reply-To: <4F58EF42.1020805@biblibre.com>
References: <4F58AD24.4060701@biblibre.com>
	<CA+95qVQO1LwHpvQiwLLAs4d6wS9yLCQDMcY9r4j95G18rtWpvw@mail.gmail.com>
	<4F58EF42.1020805@biblibre.com>
Message-ID: <CA+95qVTuw2SdC5UwnOKHJ2WLbfJvKFnDue1HpAusAr8qN2qpCA@mail.gmail.com>

On Mar 9, 2012 6:41 AM, "Paul Poulain" <paul.poulain at biblibre.com> wrote:
>
> Le 08/03/2012 18:30, Chris Cormack a ?crit :
>
> > Doing it in one hit only makes this better if it is possible to have git
> > blame ignore this commit.
>
> I don't think it's possible.
>
> > I just want to go on record as disagreeing with this plan. But happy to
> > abide by community decision I just reserve the right to complain :-)
>
> Well, speaking with Katrin, it seems the decision was not that clear:
> http://stats.workbuffer.org/irclog/koha/2012-01-04#i_857956
>
> I'm OK to discuss of it again, but I'd like to have counter proposals.
> And if we can't find an option that please everyone, then maybe do
> nothing, and remove the rule from the coding guidelines and never
> complain again or start a discussion about that (not speaking of new
> files here, just existing ones)
>
My counter proposal is tidy as you go. Fix code as you touch it.

With vim (and other editors) you can easily tidy a block, doing that as
code is changed would be my preference.

Chris

> I made a list of pro and cons of the "big bang" option, feel free
> (everybody) to add another suggestion or complete my pro/cons list
>
> (note: this encouragement is not for chris C. only, but for everybody)
> --
> 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/20120309/84e0ec1a/attachment-0001.htm>

From cnighswonger at foundations.edu  Thu Mar  8 19:26:07 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Thu, 8 Mar 2012 13:26:07 -0500
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
In-Reply-To: <CA+95qVTuw2SdC5UwnOKHJ2WLbfJvKFnDue1HpAusAr8qN2qpCA@mail.gmail.com>
References: <4F58AD24.4060701@biblibre.com>
	<CA+95qVQO1LwHpvQiwLLAs4d6wS9yLCQDMcY9r4j95G18rtWpvw@mail.gmail.com>
	<4F58EF42.1020805@biblibre.com>
	<CA+95qVTuw2SdC5UwnOKHJ2WLbfJvKFnDue1HpAusAr8qN2qpCA@mail.gmail.com>
Message-ID: <CAP3yOomLUwGavdr3xGsy_pTgR+HLv5RKJ36Wz+iUCDaPqs1XmQ@mail.gmail.com>

2012/3/8 Chris Cormack <chris at bigballofwax.co.nz>

> My counter proposal is tidy as you go. Fix code as you touch it.
>
> With vim (and other editors) you can easily tidy a block, doing that as
> code is changed would be my preference.
>

I'd prefer a "pay-as-you-go" approach as well. We could simply require all
work to be tidied before submitting.

Slow? Yes, but not nearly as messy and preserves the history.

Kind Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120308/662a6f3d/attachment.htm>

From cnighswonger at foundations.edu  Thu Mar  8 19:30:16 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Thu, 8 Mar 2012 13:30:16 -0500
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
In-Reply-To: <CA+95qVQO1LwHpvQiwLLAs4d6wS9yLCQDMcY9r4j95G18rtWpvw@mail.gmail.com>
References: <4F58AD24.4060701@biblibre.com>
	<CA+95qVQO1LwHpvQiwLLAs4d6wS9yLCQDMcY9r4j95G18rtWpvw@mail.gmail.com>
Message-ID: <CAP3yOom73gc5=yfVp5Q829F5zV6OrMH5KiX6-4uFOaY6t0jV1w@mail.gmail.com>

2012/3/8 Chris Cormack <chris at bigballofwax.co.nz>

> Doing it in one hit only makes this better if it is possible to have git
> blame ignore this commit.
>
>
>
Interestingly enough there seems to have been a patch submitted to GIT to
do just this sort of thing, but it got dropped along the way:

http://git.661346.n2.nabble.com/PATCH-blame-can-specify-shas-of-commits-to-ignore-on-command-line-td5001395.html

Kind Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120308/58ae4a00/attachment.htm>

From Katrin.Fischer at bsz-bw.de  Thu Mar  8 19:33:13 2012
From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin)
Date: Thu, 8 Mar 2012 19:33:13 +0100
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
References: <4F58AD24.4060701@biblibre.com><CA+95qVQO1LwHpvQiwLLAs4d6wS9yLCQDMcY9r4j95G18rtWpvw@mail.gmail.com><4F58EF42.1020805@biblibre.com><CA+95qVTuw2SdC5UwnOKHJ2WLbfJvKFnDue1HpAusAr8qN2qpCA@mail.gmail.com>
	<CAP3yOomLUwGavdr3xGsy_pTgR+HLv5RKJ36Wz+iUCDaPqs1XmQ@mail.gmail.com>
Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFD01626672@Bodensee.bsz-bw.de>

I agree with Chris C. and Chris N. - I think what we would win does not outweigh the loss of history.

Katrin

-----Urspr?ngliche Nachricht-----
Von: koha-devel-bounces at lists.koha-community.org im Auftrag von Chris Nighswonger
Gesendet: Do 08.03.2012 19:26
An: Chris Cormack
Cc: koha-devel at lists.koha-community.org
Betreff: Re: [Koha-devel] Koha 3.8 release schedule & perltidy process
 
2012/3/8 Chris Cormack <chris at bigballofwax.co.nz>

> My counter proposal is tidy as you go. Fix code as you touch it.
>
> With vim (and other editors) you can easily tidy a block, doing that as
> code is changed would be my preference.
>

I'd prefer a "pay-as-you-go" approach as well. We could simply require all
work to be tidied before submitting.

Slow? Yes, but not nearly as messy and preserves the history.

Kind Regards,
Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120308/887eef68/attachment.htm>

From bibliwho at gmail.com  Thu Mar  8 19:36:57 2012
From: bibliwho at gmail.com (Cab Vinton)
Date: Thu, 8 Mar 2012 13:36:57 -0500
Subject: [Koha-devel] Retrieving 10-digit ISBNs in a report
In-Reply-To: <jj9ha8$71s$1@dough.gmane.org>
References: <CABW43UTMwBC7taGvfpWx-GfyR2UUYxuoAAtwdi=Y68JMCJDuYg@mail.gmail.com>
	<jj9ha8$71s$1@dough.gmane.org>
Message-ID: <CABW43UQ5FeY4hK-QFwykX8EetV=wFOSd67WA8HJM3wJ3Dju6dg@mail.gmail.com>

Thank you, Nick!

We're hosted by Equinox, so getting that php code in place would take
a bit of extra work for us.

I'm now thinking that we may better off just using a custom field for
this purpose.

If we stick w/ Amazon, their ASIN would be the best way to go. This is
the ISBN for most books, but something else entirely when dealing with
movies & certain other items. Yet another step in our cataloging
workflow ...

Then again, there are other options for book covers, so I'll be
looking into Google Books, LibraryThing, etc. If folks have specific
thoughts on this, I'd be happy to hear them.

Many thanks again,

Cab Vinton, Director
Sanbornton Public Library
Sanbornton, NH

Life is short. Read fast!



On Thu, Mar 8, 2012 at 12:49 AM, Nicholas van Oudtshoorn
<vanoudt at gmail.com> wrote:
> A simple bit of code can be used to get the first valid 10-digit ISBN. This
> is the php code we use - it could be adapted to perl quite easily,
> though.... (Actually, if I recall correctly, there is a C4 function to get
> the Normalised ISBN...)
>
> // Normalise the ISBN
> $isbn = preg_replace('/(.*) \| (.*)/', '$1', $isbn); // Get first isbn
> $isbn = preg_replace('/(.*) (.*)/', '$1', $isbn); // Get rid of text
> if (strlen($isbn) == 11) {
> ?if ($debugging) { print "Chopping 11 digit ISBN to a 10 digit ISBN"; }
> ?$isbn = substr($isbn,1,10);
> } else if (strlen($isbn) == 13) {
> ?$isbn = substr($isbn,3,9);
> ?$checksum = 0;
> ?$weight = 10;
> ?$isbnCharArray = str_split($isbn);
> ?foreach($isbnCharArray as $char) {
> ? ?$checksum += $char * $weight;
> ? ?$weight--;
> ?}
> ?$checksum = 11-($checksum % 11);
> ?if ($checksum == 10) {
> ? ?$isbn += "X";
> ?} else if ($checksum == 11) {
> ? ?$isbn += "0";
> ?} else {
> ? ?$isbn .= $checksum;
> ?}
> } else if (strlen($isbn) != 10) {
> ?if ($debugging) { print "<p>Illegal ISBN Found: $isbn</p>"; }
> ? ?exit;
> }
> if ($debugging) { print "Normalised ISBN: $isbn"; exit; }
>
>
> -
> Nick
>
>
> On 03/07/2012 05:50 AM, Cab Vinton wrote:
>>
>> Hi, All --
>>
>> For the purposes of creating a web-based carousel of book covers of
>> our recent acquisitions, I'd like to run a report that generates a
>> list of ISBNs of items added between 2 dates.
>>
>> Amazon& ?therefore Koha rely on 10-digit ISBNs for book cover retrieval.
>>
>>
>> However, when I run a report using biblioitems.isbn, this is the
>> output I get. Many truncated ISBNs, presumably because the max length
>> = 30 restriction.
>>
>> 9780425243244 (pbk.) | 0425243
>> 9780307718099 | 0307718093
>> 0804840288 | 9780804840286 (tr
>> 9780811876377 : | 0811876373 :
>> 1569244677
>> 9781400064588 (acidfree paper)
>> 9780061429255 | 0061429252
>> 9781451661064 (hardcover) | 14
>>
>> Is there a way to run a report that outputs only the 10 digit ISBNs?
>>
>> Many thanks,
>>
>> Cab Vinton, Director
>> Sanbornton Public Library
>> Sanbornton, NH
>> _______________________________________________
>> 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/

From jcamins at cpbibliography.com  Thu Mar  8 19:37:47 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Thu, 8 Mar 2012 13:37:47 -0500
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
In-Reply-To: <028B1A54D03E7B4482CDCA4EC8F06BFD01626672@Bodensee.bsz-bw.de>
References: <4F58AD24.4060701@biblibre.com>
	<CA+95qVQO1LwHpvQiwLLAs4d6wS9yLCQDMcY9r4j95G18rtWpvw@mail.gmail.com>
	<4F58EF42.1020805@biblibre.com>
	<CA+95qVTuw2SdC5UwnOKHJ2WLbfJvKFnDue1HpAusAr8qN2qpCA@mail.gmail.com>
	<CAP3yOomLUwGavdr3xGsy_pTgR+HLv5RKJ36Wz+iUCDaPqs1XmQ@mail.gmail.com>
	<028B1A54D03E7B4482CDCA4EC8F06BFD01626672@Bodensee.bsz-bw.de>
Message-ID: <CALVDfQwvLgzWvwmjO1As=PYpKbGadARe6XFtPCHVavBZ_J0Yzw@mail.gmail.com>

+1 to a gradual perltidy

2012/3/8 Fischer, Katrin <Katrin.Fischer at bsz-bw.de>

> **
>
> I agree with Chris C. and Chris N. - I think what we would win does not
> outweigh the loss of history.
>
> Katrin
>
> -----Urspr?ngliche Nachricht-----
> Von: koha-devel-bounces at lists.koha-community.org im Auftrag von Chris
> Nighswonger
> Gesendet: Do 08.03.2012 19:26
> An: Chris Cormack
> Cc: koha-devel at lists.koha-community.org
> Betreff: Re: [Koha-devel] Koha 3.8 release schedule & perltidy process
>
>
> 2012/3/8 Chris Cormack <chris at bigballofwax.co.nz>
>
> > My counter proposal is tidy as you go. Fix code as you touch it.
> >
> > With vim (and other editors) you can easily tidy a block, doing that as
> > code is changed would be my preference.
> >
>
> I'd prefer a "pay-as-you-go" approach as well. We could simply require all
> work to be tidied before submitting.
>
> Slow? Yes, but not nearly as messy and preserves the history.
>
> Kind Regards,
> Chris
>
>
> _______________________________________________
> 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/
>



-- 
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/20120308/22a6f3ca/attachment.htm>

From koha.sekjal at gmail.com  Thu Mar  8 19:44:55 2012
From: koha.sekjal at gmail.com (Ian Walls)
Date: Thu, 8 Mar 2012 13:44:55 -0500
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
In-Reply-To: <CALVDfQwvLgzWvwmjO1As=PYpKbGadARe6XFtPCHVavBZ_J0Yzw@mail.gmail.com>
References: <4F58AD24.4060701@biblibre.com>
	<CA+95qVQO1LwHpvQiwLLAs4d6wS9yLCQDMcY9r4j95G18rtWpvw@mail.gmail.com>
	<4F58EF42.1020805@biblibre.com>
	<CA+95qVTuw2SdC5UwnOKHJ2WLbfJvKFnDue1HpAusAr8qN2qpCA@mail.gmail.com>
	<CAP3yOomLUwGavdr3xGsy_pTgR+HLv5RKJ36Wz+iUCDaPqs1XmQ@mail.gmail.com>
	<028B1A54D03E7B4482CDCA4EC8F06BFD01626672@Bodensee.bsz-bw.de>
	<CALVDfQwvLgzWvwmjO1As=PYpKbGadARe6XFtPCHVavBZ_J0Yzw@mail.gmail.com>
Message-ID: <CANL=k+GXrR-zszP7bwZWqf7+bZUXo5sSR47d4+3BbnyeXVxEEg@mail.gmail.com>

Doing a large updating commit does not cost us any history.  It just counts
as an "update" to the code, even though none of the logic has changed.
This change would alter SLOC counts and such, messing with our statistics,
since we only want to measure intellectually significant contributions
(tidying someone else's work doesn't make it yours).  There is no way for
Git to know if a change to a line of text is a logical change or just a
formatting change (aside from whitespace), because Git doesn't understand
Perl.  There isn't too much we can do about this.

So, best to keep cleaning up incrementally, I think.  As we move from C4 to
Koha, that'll be an opportunity to clean up all the modules


-Ian

2012/3/8 Jared Camins-Esakov <jcamins at cpbibliography.com>

> +1 to a gradual perltidy
>
> 2012/3/8 Fischer, Katrin <Katrin.Fischer at bsz-bw.de>
>
>> **
>>
>> I agree with Chris C. and Chris N. - I think what we would win does not
>> outweigh the loss of history.
>>
>> Katrin
>>
>> -----Urspr?ngliche Nachricht-----
>> Von: koha-devel-bounces at lists.koha-community.org im Auftrag von Chris
>> Nighswonger
>> Gesendet: Do 08.03.2012 19:26
>> An: Chris Cormack
>> Cc: koha-devel at lists.koha-community.org
>> Betreff: Re: [Koha-devel] Koha 3.8 release schedule & perltidy process
>>
>>
>> 2012/3/8 Chris Cormack <chris at bigballofwax.co.nz>
>>
>> > My counter proposal is tidy as you go. Fix code as you touch it.
>> >
>> > With vim (and other editors) you can easily tidy a block, doing that as
>> > code is changed would be my preference.
>> >
>>
>> I'd prefer a "pay-as-you-go" approach as well. We could simply require all
>> work to be tidied before submitting.
>>
>> Slow? Yes, but not nearly as messy and preserves the history.
>>
>> Kind Regards,
>> Chris
>>
>>
>> _______________________________________________
>> 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/
>>
>
>
>
> --
> 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/
>
>
> _______________________________________________
> 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/20120308/8071818a/attachment-0001.htm>

From chrisc at catalyst.net.nz  Thu Mar  8 19:50:23 2012
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Fri, 9 Mar 2012 07:50:23 +1300
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
In-Reply-To: <CANL=k+GXrR-zszP7bwZWqf7+bZUXo5sSR47d4+3BbnyeXVxEEg@mail.gmail.com>
References: <4F58AD24.4060701@biblibre.com>
	<CA+95qVQO1LwHpvQiwLLAs4d6wS9yLCQDMcY9r4j95G18rtWpvw@mail.gmail.com>
	<4F58EF42.1020805@biblibre.com>
	<CA+95qVTuw2SdC5UwnOKHJ2WLbfJvKFnDue1HpAusAr8qN2qpCA@mail.gmail.com>
	<CAP3yOomLUwGavdr3xGsy_pTgR+HLv5RKJ36Wz+iUCDaPqs1XmQ@mail.gmail.com>
	<028B1A54D03E7B4482CDCA4EC8F06BFD01626672@Bodensee.bsz-bw.de>
	<CALVDfQwvLgzWvwmjO1As=PYpKbGadARe6XFtPCHVavBZ_J0Yzw@mail.gmail.com>
	<CANL=k+GXrR-zszP7bwZWqf7+bZUXo5sSR47d4+3BbnyeXVxEEg@mail.gmail.com>
Message-ID: <20120308185023.GU6577@rorohiko.wgtn.cat-it.co.nz>

* Ian Walls (koha.sekjal at gmail.com) wrote:
>    Doing a large updating commit does not cost us any history.A  It just
>    counts as an "update" to the code, even though none of the logic has
>    changed.A A  This change would alter SLOC counts and such, messing with
>    our statistics, since we only want to measure intellectually significant
>    contributions (tidying someone else's work doesn't make it yours).A  There
>    is no way for Git to know if a change to a line of text is a logical
>    change or just a formatting change (aside from whitespace), because Git
>    doesn't understand Perl.A  There isn't too much we can do about this.

It's not so much statistics I care about, although I do. But also that
it makes it hard to to do a git blame to find which commit actually
changed the line. Since now every line is changed by the same commit.

Chris
> 
>    So, best to keep cleaning up incrementally, I think.A  As we move from C4
>    to Koha, that'll be an opportunity to clean up all the modules
> 
>    -Ian
> 
>    2012/3/8 Jared Camins-Esakov <jcamins at cpbibliography.com>
> 
>      +1 to a gradual perltidy
> 
>      2012/3/8 Fischer, Katrin <Katrin.Fischer at bsz-bw.de>
> 
>        I agree with Chris C. and Chris N. - I think what we would win does
>        not outweigh the loss of history.
> 
>        Katrin
> 
>        -----UrsprA 1/4ngliche Nachricht-----
>        Von: koha-devel-bounces at lists.koha-community.org im Auftrag von Chris
>        Nighswonger
>        Gesendet: Do 08.03.2012 19:26
>        An: Chris Cormack
>        Cc: koha-devel at lists.koha-community.org
>        Betreff: Re: [Koha-devel] Koha 3.8 release schedule & perltidy process
> 
>        2012/3/8 Chris Cormack <chris at bigballofwax.co.nz>
> 
>        > My counter proposal is tidy as you go. Fix code as you touch it.
>        >
>        > With vim (and other editors) you can easily tidy a block, doing that
>        as
>        > code is changed would be my preference.
>        >
> 
>        I'd prefer a "pay-as-you-go" approach as well. We could simply require
>        all
>        work to be tidied before submitting.
> 
>        Slow? Yes, but not nearly as messy and preserves the history.
> 
>        Kind Regards,
>        Chris
> 
>        _______________________________________________
>        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/
> 
>      --
>      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/
>      _______________________________________________
>      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/


-- 
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/20120309/3b57e443/attachment.pgp>

From koha.sekjal at gmail.com  Thu Mar  8 20:21:24 2012
From: koha.sekjal at gmail.com (Ian Walls)
Date: Thu, 8 Mar 2012 14:21:24 -0500
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
In-Reply-To: <20120308185023.GU6577@rorohiko.wgtn.cat-it.co.nz>
References: <4F58AD24.4060701@biblibre.com>
	<CA+95qVQO1LwHpvQiwLLAs4d6wS9yLCQDMcY9r4j95G18rtWpvw@mail.gmail.com>
	<4F58EF42.1020805@biblibre.com>
	<CA+95qVTuw2SdC5UwnOKHJ2WLbfJvKFnDue1HpAusAr8qN2qpCA@mail.gmail.com>
	<CAP3yOomLUwGavdr3xGsy_pTgR+HLv5RKJ36Wz+iUCDaPqs1XmQ@mail.gmail.com>
	<028B1A54D03E7B4482CDCA4EC8F06BFD01626672@Bodensee.bsz-bw.de>
	<CALVDfQwvLgzWvwmjO1As=PYpKbGadARe6XFtPCHVavBZ_J0Yzw@mail.gmail.com>
	<CANL=k+GXrR-zszP7bwZWqf7+bZUXo5sSR47d4+3BbnyeXVxEEg@mail.gmail.com>
	<20120308185023.GU6577@rorohiko.wgtn.cat-it.co.nz>
Message-ID: <CANL=k+F8teBenJ0Cqnr9AC0NE1rTu-oY+NP15+Yybo3doJBKug@mail.gmail.com>

Chris,


Right, with the colossal commit option, one could have to

   1. Know the commit id of the change
   2. git blame something
   3. if that id comes up, then git checkout -b temporary
   <<the_id_of_the_change>>^
   4. git blame again

The more history we pile on top of that, the longer it'll take git to
update the index, and then restore back to master when you're done.  If
you're tracing out lots of blames, then this can be a serious crimp in
workflow.

-Ian
On Thu, Mar 8, 2012 at 13:50, Chris Cormack <chrisc at catalyst.net.nz> wrote:

> * Ian Walls (koha.sekjal at gmail.com) wrote:
> >    Doing a large updating commit does not cost us any history.A  It just
> >    counts as an "update" to the code, even though none of the logic has
> >    changed.A A  This change would alter SLOC counts and such, messing
> with
> >    our statistics, since we only want to measure intellectually
> significant
> >    contributions (tidying someone else's work doesn't make it yours).A
>  There
> >    is no way for Git to know if a change to a line of text is a logical
> >    change or just a formatting change (aside from whitespace), because
> Git
> >    doesn't understand Perl.A  There isn't too much we can do about this.
>
> It's not so much statistics I care about, although I do. But also that
> it makes it hard to to do a git blame to find which commit actually
> changed the line. Since now every line is changed by the same commit.
>
> Chris
> >
> >    So, best to keep cleaning up incrementally, I think.A  As we move
> from C4
> >    to Koha, that'll be an opportunity to clean up all the modules
> >
> >    -Ian
> >
> >    2012/3/8 Jared Camins-Esakov <jcamins at cpbibliography.com>
> >
> >      +1 to a gradual perltidy
> >
> >      2012/3/8 Fischer, Katrin <Katrin.Fischer at bsz-bw.de>
> >
> >        I agree with Chris C. and Chris N. - I think what we would win
> does
> >        not outweigh the loss of history.
> >
> >        Katrin
> >
> >        -----UrsprA 1/4ngliche Nachricht-----
> >        Von: koha-devel-bounces at lists.koha-community.org im Auftrag von
> Chris
> >        Nighswonger
> >        Gesendet: Do 08.03.2012 19:26
> >        An: Chris Cormack
> >        Cc: koha-devel at lists.koha-community.org
> >        Betreff: Re: [Koha-devel] Koha 3.8 release schedule & perltidy
> process
> >
> >        2012/3/8 Chris Cormack <chris at bigballofwax.co.nz>
> >
> >        > My counter proposal is tidy as you go. Fix code as you touch it.
> >        >
> >        > With vim (and other editors) you can easily tidy a block, doing
> that
> >        as
> >        > code is changed would be my preference.
> >        >
> >
> >        I'd prefer a "pay-as-you-go" approach as well. We could simply
> require
> >        all
> >        work to be tidied before submitting.
> >
> >        Slow? Yes, but not nearly as messy and preserves the history.
> >
> >        Kind Regards,
> >        Chris
> >
> >        _______________________________________________
> >        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/
> >
> >      --
> >      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/
> >      _______________________________________________
> >      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/
>
>
> --
> Chris Cormack
> Catalyst IT Ltd.
> +64 4 803 2238
> PO Box 11-053, Manners St, Wellington 6142, New Zealand
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120308/5f476c4d/attachment.htm>

From savitra.sirohi at osslabs.biz  Fri Mar  9 05:09:31 2012
From: savitra.sirohi at osslabs.biz (savitra sirohi)
Date: Fri, 9 Mar 2012 09:39:31 +0530
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process --
	more time?
Message-ID: <CAOC8d3Ak=toxmxCQ7Wk_xU3zdeJh=iBhxzY8K8tAb9yiOUydOQ@mail.gmail.com>

Hi Paul, we have been caught off-guard by this schedule.

We have a lot of stuff to submit but March 23rd is too little time. If we
have 2 more weeks, we can get good stuff included. Possible?

Thanks,
Savitra Sirohi
Nucsoft OSS Labs
http://www.osslabs.biz

On Thu, Mar 8, 2012 at 6:29 PM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Hello koha-devel,
>
> I just updated the 3.8 release process with the schedule/planning of the
> release: http://wiki.koha-community.org/wiki/Roadmap_to_3.8
>
> Here it is:
> March, 23th (1 month before the release) = feature freeze.
> April, 6th = strong feature freeze, string freeze
> April 20th = starting release process, everything frozen
> April 23th = release of Koha 3.8.0
>
> IMPORTANT = perltidy process
>
> In january IRC meeting we spoke of perltidy thing. We have a coding
> guideline rule that says code must be perltidied. However, all the
> existing code is not perltidied, and it's hard to mix perltidied and non
> perltidied code.
> Thus, we have investigated the idea of doing a "perltidy big-bang" just
> when releasing 3.8.0, for all the code.
>
> Pro:
> * the code will be perltidied, the coding guideline will be applicable
> * all perltidy being made at the same time, it will be easier to read
> the git log. (One of the argument against perltidying is that it's a
> problem for reading git history)
> * doing that for a release is better for future bugfixes means that
> patches will apply on 3.8 as well as on master.
>
> Cons:
> * patches that are waiting may become "does not apply" because of the
> perltidy thing
> * patches submitted to fix bugs in 3.8 may not apply on 3.6 easily, that
> will add more work for 3.6 releases.
>
> All in one, our conclusion was that the best solution is to do that
> during a release process.
> So I plan do it during 3.8 release.
>
> (I have a (small ?) question about that : do you think I should make
> only one huge commit with perltidy ? one for each directory ? one for
> each file ?)
>
> --
> 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/
>



-- 
Thanks,
Savitra Sirohi
Nucsoft OSS Labs
Professional Support for Open Source Software
Ph: +91 89718 06111
Web: http://www.osslabs.biz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120309/53556c07/attachment-0001.htm>

From paul.poulain at biblibre.com  Fri Mar  9 09:38:52 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 09 Mar 2012 09:38:52 +0100
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process --
 more time?
In-Reply-To: <CAOC8d3Ak=toxmxCQ7Wk_xU3zdeJh=iBhxzY8K8tAb9yiOUydOQ@mail.gmail.com>
References: <CAOC8d3Ak=toxmxCQ7Wk_xU3zdeJh=iBhxzY8K8tAb9yiOUydOQ@mail.gmail.com>
Message-ID: <4F59C19C.9020107@biblibre.com>

Le 09/03/2012 05:09, savitra sirohi a ?crit :
> Hi Paul,
Hi Savitra,

> we have been caught off-guard by this schedule.
The schedule is the same as what we had for previous time-based-release.
I agree that my announcement could have be made a little bit earlier,
but you can, for future releases, consider the "1 month before the
release" as the "feature freeze" limit. We need time to do some tests,
translations,... so we can't freeze things only a few days before the
release.

> We have a lot of stuff to submit but March 23rd is too little time. If
> we have 2 more weeks, we can get good stuff included. Possible?
Well, I can't answer this question so easily, I'll start by asking more
questions:
* could you give us more details about the stuff that will be submitted ?
* are you aware that, even if you submit before march 23, it must also
be signed-off, QAed, and, if it's large change, that won't be made in a
second ? atm, there are 82 patches waiting for sign-off, 12 of them
being waiting for more than 2 months !
* Is there a really strong reason to have those features need for 3.8 ?
all/many of us have a lot of nice/cool stuff that is waiting for
inclusion (almost 50% of the patches waiting for signoff are coming from
BibLibre 39/82).

-- 
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 Mar  9 10:15:48 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 09 Mar 2012 10:15:48 +0100
Subject: [Koha-devel] Some changes to saved queries
Message-ID: <4F59CA44.1020002@biblibre.com>

Hello all (and 1st of all chris_c)

I'd like to have a different sort order for "passed QA" query: I push
usually from oldest to newest QAed patch, so, could you please update
the "passed QA" query to sort by last changed ?

Same thing for signed-off = I think it's better to QA things from oldest
to newest.
And I'd also like to have the same sort order for "needs signoff". This
way, old bugs needing attention will appear first. I think that will
encourage ppl to test them.

All of those queries are "owned" by you chris_c, so you're the one who
can do something about that !
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From M.de.Rooy at rijksmuseum.nl  Fri Mar  9 10:16:26 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Fri, 9 Mar 2012 09:16:26 +0000
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
In-Reply-To: <CANL=k+F8teBenJ0Cqnr9AC0NE1rTu-oY+NP15+Yybo3doJBKug@mail.gmail.com>
References: <4F58AD24.4060701@biblibre.com>
	<CA+95qVQO1LwHpvQiwLLAs4d6wS9yLCQDMcY9r4j95G18rtWpvw@mail.gmail.com>
	<4F58EF42.1020805@biblibre.com>
	<CA+95qVTuw2SdC5UwnOKHJ2WLbfJvKFnDue1HpAusAr8qN2qpCA@mail.gmail.com>
	<CAP3yOomLUwGavdr3xGsy_pTgR+HLv5RKJ36Wz+iUCDaPqs1XmQ@mail.gmail.com>
	<028B1A54D03E7B4482CDCA4EC8F06BFD01626672@Bodensee.bsz-bw.de>
	<CALVDfQwvLgzWvwmjO1As=PYpKbGadARe6XFtPCHVavBZ_J0Yzw@mail.gmail.com>
	<CANL=k+GXrR-zszP7bwZWqf7+bZUXo5sSR47d4+3BbnyeXVxEEg@mail.gmail.com>
	<20120308185023.GU6577@rorohiko.wgtn.cat-it.co.nz>,
	<CANL=k+F8teBenJ0Cqnr9AC0NE1rTu-oY+NP15+Yybo3doJBKug@mail.gmail.com>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310954BBF3@S-MAIL-1B.rijksmuseum.intra>

+1 for a gradual perl tidy too

Even then, still don't like the idea of blocking a patch for tabs and spaces ..



________________________________
Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Ian Walls [koha.sekjal at gmail.com]
Verzonden: donderdag 8 maart 2012 20:21
To: Chris Cormack
Cc: Fischer, Katrin; koha-devel at lists.koha-community.org
Onderwerp: Re: [Koha-devel] Koha 3.8 release schedule & perltidy process

Chris,


Right, with the colossal commit option, one could have to

  1.  Know the commit id of the change
  2.  git blame something
  3.  if that id comes up, then git checkout -b temporary <<the_id_of_the_change>>^
  4.  git blame again

The more history we pile on top of that, the longer it'll take git to update the index, and then restore back to master when you're done.  If you're tracing out lots of blames, then this can be a serious crimp in workflow.

-Ian

On Thu, Mar 8, 2012 at 13:50, Chris Cormack <chrisc at catalyst.net.nz<mailto:chrisc at catalyst.net.nz>> wrote:
* Ian Walls (koha.sekjal at gmail.com<mailto:koha.sekjal at gmail.com>) wrote:
>    Doing a large updating commit does not cost us any history.A  It just
>    counts as an "update" to the code, even though none of the logic has
>    changed.A A  This change would alter SLOC counts and such, messing with
>    our statistics, since we only want to measure intellectually significant
>    contributions (tidying someone else's work doesn't make it yours).A  There
>    is no way for Git to know if a change to a line of text is a logical
>    change or just a formatting change (aside from whitespace), because Git
>    doesn't understand Perl.A  There isn't too much we can do about this.

It's not so much statistics I care about, although I do. But also that
it makes it hard to to do a git blame to find which commit actually
changed the line. Since now every line is changed by the same commit.

Chris
>
>    So, best to keep cleaning up incrementally, I think.A  As we move from C4
>    to Koha, that'll be an opportunity to clean up all the modules
>
>    -Ian
>
>    2012/3/8 Jared Camins-Esakov <jcamins at cpbibliography.com<mailto:jcamins at cpbibliography.com>>
>
>      +1 to a gradual perltidy
>
>      2012/3/8 Fischer, Katrin <Katrin.Fischer at bsz-bw.de<mailto:Katrin.Fischer at bsz-bw.de>>
>
>        I agree with Chris C. and Chris N. - I think what we would win does
>        not outweigh the loss of history.
>
>        Katrin
>
>        -----UrsprA 1/4ngliche Nachricht-----
>        Von: koha-devel-bounces at lists.koha-community.org<mailto:koha-devel-bounces at lists.koha-community.org> im Auftrag von Chris
>        Nighswonger
>        Gesendet: Do 08.03.2012 19:26
>        An: Chris Cormack
>        Cc: koha-devel at lists.koha-community.org<mailto:koha-devel at lists.koha-community.org>
>        Betreff: Re: [Koha-devel] Koha 3.8 release schedule & perltidy process
>
>        2012/3/8 Chris Cormack <chris at bigballofwax.co.nz<mailto:chris at bigballofwax.co.nz>>
>
>        > My counter proposal is tidy as you go. Fix code as you touch it.
>        >
>        > With vim (and other editors) you can easily tidy a block, doing that
>        as
>        > code is changed would be my preference.
>        >
>
>        I'd prefer a "pay-as-you-go" approach as well. We could simply require
>        all
>        work to be tidied before submitting.
>
>        Slow? Yes, but not nearly as messy and preserves the history.
>
>        Kind Regards,
>        Chris
>
>        _______________________________________________
>        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/
>
>      --
>      Jared Camins-Esakov
>      Bibliographer, C & P Bibliography Services, LLC
>      (phone) +1 (917) 727-3445<tel:%2B1%20%28917%29%20727-3445>
>      (e-mail) jcamins at cpbibliography.com<mailto:jcamins at cpbibliography.com>
>      (web) http://www.cpbibliography.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/

> _______________________________________________
> 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/


--
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238<tel:%2B64%204%20803%202238>
PO Box 11-053, Manners St, Wellington 6142, New Zealand

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

From paul.poulain at biblibre.com  Fri Mar  9 11:41:32 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 09 Mar 2012 11:41:32 +0100
Subject: [Koha-devel] User configurable slips pushed (bug 7001,
	call for more testing)
Message-ID: <4F59DE5C.8020004@biblibre.com>

Hello all,

I just pushed bug 7001:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7001

It contains a great enhancement that has been tested by many people, and
resulted in a long long comments thread and fixes/changes.
In a few word:
 * notices can now be in HTML format (not only txt)
 * notices can be associated to a branch (with a default notice)
 * the CSS, in case of html, are defined in a syspref (NoticeCSS and
SlipCSS)

BUT, as it touches a lot of files, I call here for more testing by more
people !

Some usefull comments:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7001#c0
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7001#c60
(additional notes section)
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7001#c77
(additional notes section)

The list of files updated:
 C4/Circulation.pm
 C4/Letters.pm
 C4/Members.pm
 C4/Members/Attributes.pm
 C4/Message.pm
 C4/Print.pm
 C4/Reserves.pm
 C4/Suggestions.pm
 acqui/booksellers.pl
 circ/circulation.pl
 circ/hold-transfer-slip.pl
 circ/transfer-slip.pl
 members/memberentry.pl
 members/moremember.pl
 members/printslip.pl
 misc/cronjobs/advance_notices.pl
 misc/cronjobs/gather_print_notices.pl
 misc/cronjobs/overdue_notices.pl

(+ many templates, SQL default loadable data and updatedatabase)
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From sandeep.bhavsar at gmail.com  Fri Mar  9 12:07:05 2012
From: sandeep.bhavsar at gmail.com (SANDEEP BHAVSAR)
Date: Fri, 9 Mar 2012 16:37:05 +0530
Subject: [Koha-devel] Fwd: [LIS-Forum] Mysore University Koha OPAC on Mobile
Message-ID: <CA+3iuR6vWsDKh0B7BkjU5osHtmf=NsSf=LbrDXFNsZ6Jz6-imw@mail.gmail.com>

---------- Forwarded message ----------
From: Ishwar Goudar <goudarishwar at googlemail.com>
Date: Thu, Mar 8, 2012 at 7:39 PM
Subject: [LIS-Forum] Mysore University OPAC on Mobile
To: lis-forum at ncsi.iisc.ernet.in, francis at ncsi.iisc.ernet.in


Dear Professionals,

I am  happy inform you all that our University Library Web OPAC has gone the
* mobile way*.  We
have adopted open source library automation system KOHA for all our house
keeping activities
including OPAC and the same has been made available in cloud hosting
environment. Anybody
can access our  OPAC on *Mobile* at  site
http://mopac.mysore-univ.org/

To see what it looks like in a mobile phone, please use following site on
your desktop/laptop:
http://iphonetester.com/?url=http://mopac.mysore-univ.org/

Apple claims to have sold record number of Smart-phones smashing the the
record of PC sales.  The same has
been the fate with Laptops and notebooks.
(
http://www.digitaltrends.com/mobile/smartphone-sales-exceed-those-of-pcs-for-first-time-apple-smashes-record/
)
Internet access through Mobile has become the order of the day.  This being
the case, I strongly feel that all of us
should go the mobile way for our OPACs.

Our patrons can use their mobile for reserving, renewing the documents and
all related activities.
We are working towards using Mobile SMSs for overdue reminders, informing
the availability of
reserved documents, documents purchased against requests, broadcasting
important library
related messages, etc.

The automation model we have adopted is *-*  Centralised database,
decentralised inputting/
housekeeping activities and Universal access to OPAC. Once completed the
OPAC will
have > 10 Lakh records of documents available in colleges, institutes, PG
Centres and various
departments, which are directly under the control of Mysore University.

We acknowledge OSS Labs, Bangalore for having  given quality, timely and
cost effective service to us
in this matter. Probably ours is the first university library to go mobile
way for OPAC (?).  Please have a
 look at it and give your feedback, enabling us to improve the service.


Regards,

Dr. I.R.N. Goudar
Visiting professor and Library Adviser
University of Mysore

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://ncsi.iisc.ernet.in/pipermail/lis-forum/attachments/20120308/753cc29a/attachment.html
>
_______________________________________________
LIS-Forum mailing list
LIS-Forum at ncsi.iisc.ernet.in
http://ncsi.iisc.ernet.in/mailman/listinfo/lis-forum



-- 
Thanks and Regards

Sandeep Bhavsar
Librarian
Dr.V.N.Bedekar Institute of Management Studies
Thane(W) 400601
MUMBAI. INDIA
@@@@@@@@@@@@@@@@@@@@@@@@@@
email    : sandeep.bhavsar at gmail.com
Mob     : 9029 345777
elibrary :http://www.vpmthane.org/im/elib/main.htm
@@@@@@@@@@@@@@@@@@@@@@@@@@
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120309/8d35ddfa/attachment.htm>

From jonathan.druart at biblibre.com  Fri Mar  9 12:44:06 2012
From: jonathan.druart at biblibre.com (Jonathan Druart)
Date: Fri, 9 Mar 2012 12:44:06 +0100
Subject: [Koha-devel] User configurable slips pushed (bug 7001,
	call for more testing)
In-Reply-To: <4F59DE5C.8020004@biblibre.com>
References: <4F59DE5C.8020004@biblibre.com>
Message-ID: <CAJzKNY6qROBOWkS=Hr+iaPjWPq3RwnaonUFBojdEMvcgw+K-WQ@mail.gmail.com>

Hi all,

Arg :-/
This patch breaks the feature introduced by Bug 5347. In this patch, I have
already make a refactoring of C4::Letters::SendAlerts

Commit id is b8e9829be5a59c84ba699fc015820cd4eb3fbc0a and is already pushed
in Master.



2012/3/9 Paul Poulain <paul.poulain at biblibre.com>

> Hello all,
>
> I just pushed bug 7001:
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7001
>
> It contains a great enhancement that has been tested by many people, and
> resulted in a long long comments thread and fixes/changes.
> In a few word:
>  * notices can now be in HTML format (not only txt)
>  * notices can be associated to a branch (with a default notice)
>  * the CSS, in case of html, are defined in a syspref (NoticeCSS and
> SlipCSS)
>
> BUT, as it touches a lot of files, I call here for more testing by more
> people !
>
> Some usefull comments:
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7001#c0
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7001#c60
> (additional notes section)
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7001#c77
> (additional notes section)
>
> The list of files updated:
>  C4/Circulation.pm
>  C4/Letters.pm
>  C4/Members.pm
>  C4/Members/Attributes.pm
>  C4/Message.pm
>  C4/Print.pm
>  C4/Reserves.pm
>  C4/Suggestions.pm
>  acqui/booksellers.pl
>  circ/circulation.pl
>  circ/hold-transfer-slip.pl
>  circ/transfer-slip.pl
>  members/memberentry.pl
>  members/moremember.pl
>  members/printslip.pl
>  misc/cronjobs/advance_notices.pl
>  misc/cronjobs/gather_print_notices.pl
>  misc/cronjobs/overdue_notices.pl
>
> (+ many templates, SQL default loadable data and updatedatabase)
> --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120309/cc0826c4/attachment.htm>

From paul.poulain at biblibre.com  Fri Mar  9 13:33:38 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 09 Mar 2012 13:33:38 +0100
Subject: [Koha-devel] User configurable slips pushed (bug 7001,
	call for more testing)
In-Reply-To: <CAJzKNY6qROBOWkS=Hr+iaPjWPq3RwnaonUFBojdEMvcgw+K-WQ@mail.gmail.com>
References: <4F59DE5C.8020004@biblibre.com>
	<CAJzKNY6qROBOWkS=Hr+iaPjWPq3RwnaonUFBojdEMvcgw+K-WQ@mail.gmail.com>
Message-ID: <4F59F8A2.3050104@biblibre.com>

Le 09/03/2012 12:44, Jonathan Druart a ?crit :
> This patch breaks the feature introduced by Bug 5347. In this patch, I
> have already make a refactoring of C4::Letters::SendAlerts

Could you give some details about what is broken ?
I see the following changes:
* sending mails, the utf8 encoding is removed:
- Subject => Encode::encode( "utf8", "" . $innerletter->{title} ),
- Message => Encode::encode( "utf8", "" . $innerletter->{content} ),
* the order_infos stuff:
+ my @fields = map {
+ $sthorders->{mysql_table}[$_] . "." . $sthorders->{NAME}[$_] }
+            (0 .. $#{$sthorders->{NAME}} ) ;
+
+ my @orders_infos;
+ while ( my $row = $sthorders->fetchrow_arrayref() ) {
+    my %rec = ();
+    @rec{@fields} = @$row;
+    push @orders_infos, \%rec;
+ }

Is there more things ?

> Commit id is b8e9829be5a59c84ba699fc015820cd4eb3fbc0a and is already
> pushed in Master.

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

From Eric.Begin at inLibro.com  Fri Mar  9 13:36:29 2012
From: Eric.Begin at inLibro.com (=?ISO-8859-1?Q?Eric_B=E9gin?=)
Date: Fri, 09 Mar 2012 07:36:29 -0500
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310954BBF3@S-MAIL-1B.rijksmuseum.intra>
References: <4F58AD24.4060701@biblibre.com>
	<CA+95qVQO1LwHpvQiwLLAs4d6wS9yLCQDMcY9r4j95G18rtWpvw@mail.gmail.com>
	<4F58EF42.1020805@biblibre.com>
	<CA+95qVTuw2SdC5UwnOKHJ2WLbfJvKFnDue1HpAusAr8qN2qpCA@mail.gmail.com>
	<CAP3yOomLUwGavdr3xGsy_pTgR+HLv5RKJ36Wz+iUCDaPqs1XmQ@mail.gmail.com>
	<028B1A54D03E7B4482CDCA4EC8F06BFD01626672@Bodensee.bsz-bw.de>
	<CALVDfQwvLgzWvwmjO1As=PYpKbGadARe6XFtPCHVavBZ_J0Yzw@mail.gmail.com>
	<CANL=k+GXrR-zszP7bwZWqf7+bZUXo5sSR47d4+3BbnyeXVxEEg@mail.gmail.com>
	<20120308185023.GU6577@rorohiko.wgtn.cat-it.co.nz>,
	<CANL=k+F8teBenJ0Cqnr9AC0NE1rTu-oY+NP15+Yybo3doJBKug@mail.gmail.com>
	<809BE39CD64BFD4EB9036172EBCCFA310954BBF3@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <4F59F94D.4070802@inLibro.com>

Hello all,

Have we considered using git's hooks for tidifying the code before 
checking it in, or even on the server, this would ensure that whoever 
does the checkin, it will be tidified.

Also, if we consider going with a global tidifying, a good timing could 
be when creating a new branch.

My 2 cents !

Eric B?gin
www.inLibro.com



On 2012-03-09 04:16, Marcel de Rooy wrote:
>
> +1 for a gradual perl tidy too
>
> Even then, still don't like the idea of blocking a patch for tabs and 
> spaces ..
>
> ------------------------------------------------------------------------
> *Van:* koha-devel-bounces at lists.koha-community.org 
> [koha-devel-bounces at lists.koha-community.org] namens Ian Walls 
> [koha.sekjal at gmail.com]
> *Verzonden:* donderdag 8 maart 2012 20:21
> *To:* Chris Cormack
> *Cc:* Fischer, Katrin; koha-devel at lists.koha-community.org
> *Onderwerp:* Re: [Koha-devel] Koha 3.8 release schedule & perltidy process
>
> Chris,
>
>
> Right, with the colossal commit option, one could have to
>
>  1. Know the commit id of the change
>  2. git blame something
>  3. if that id comes up, then git checkout -b temporary
>     <<the_id_of_the_change>>^
>  4. git blame again
>
> The more history we pile on top of that, the longer it'll take git to 
> update the index, and then restore back to master when you're done.  
> If you're tracing out lots of blames, then this can be a serious crimp 
> in workflow.
>
> -Ian
>
> On Thu, Mar 8, 2012 at 13:50, Chris Cormack <chrisc at catalyst.net.nz 
> <mailto:chrisc at catalyst.net.nz>> wrote:
>
>     * Ian Walls (koha.sekjal at gmail.com <mailto:koha.sekjal at gmail.com>)
>     wrote:
>     >    Doing a large updating commit does not cost us any history.A
>      It just
>     >    counts as an "update" to the code, even though none of the
>     logic has
>     >    changed.A A  This change would alter SLOC counts and such,
>     messing with
>     >    our statistics, since we only want to measure intellectually
>     significant
>     >    contributions (tidying someone else's work doesn't make it
>     yours).A  There
>     >    is no way for Git to know if a change to a line of text is a
>     logical
>     >    change or just a formatting change (aside from whitespace),
>     because Git
>     >    doesn't understand Perl.A  There isn't too much we can do
>     about this.
>
>     It's not so much statistics I care about, although I do. But also that
>     it makes it hard to to do a git blame to find which commit actually
>     changed the line. Since now every line is changed by the same commit.
>
>     Chris
>     >
>     >    So, best to keep cleaning up incrementally, I think.A  As we
>     move from C4
>     >    to Koha, that'll be an opportunity to clean up all the modules
>     >
>     >    -Ian
>     >
>     >    2012/3/8 Jared Camins-Esakov <jcamins at cpbibliography.com
>     <mailto:jcamins at cpbibliography.com>>
>     >
>     >      +1 to a gradual perltidy
>     >
>     >      2012/3/8 Fischer, Katrin <Katrin.Fischer at bsz-bw.de
>     <mailto:Katrin.Fischer at bsz-bw.de>>
>     >
>     >        I agree with Chris C. and Chris N. - I think what we
>     would win does
>     >        not outweigh the loss of history.
>     >
>     >        Katrin
>     >
>     >        -----UrsprA 1/4ngliche Nachricht-----
>     >        Von: koha-devel-bounces at lists.koha-community.org
>     <mailto:koha-devel-bounces at lists.koha-community.org> im Auftrag
>     von Chris
>     >        Nighswonger
>     >        Gesendet: Do 08.03.2012 19:26
>     >        An: Chris Cormack
>     >        Cc: koha-devel at lists.koha-community.org
>     <mailto:koha-devel at lists.koha-community.org>
>     >        Betreff: Re: [Koha-devel] Koha 3.8 release schedule &
>     perltidy process
>     >
>     >        2012/3/8 Chris Cormack <chris at bigballofwax.co.nz
>     <mailto:chris at bigballofwax.co.nz>>
>     >
>     > > My counter proposal is tidy as you go. Fix code as you touch it.
>     > >
>     > > With vim (and other editors) you can easily tidy a block,
>     doing that
>     >        as
>     > > code is changed would be my preference.
>     > >
>     >
>     >        I'd prefer a "pay-as-you-go" approach as well. We could
>     simply require
>     >        all
>     >        work to be tidied before submitting.
>     >
>     >        Slow? Yes, but not nearly as messy and preserves the history.
>     >
>     >        Kind Regards,
>     >        Chris
>     >
>     >        _______________________________________________
>     >        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/
>     >
>     >      --
>     >      Jared Camins-Esakov
>     >      Bibliographer, C & P Bibliography Services, LLC
>     >      (phone) +1 (917) 727-3445 <tel:%2B1%20%28917%29%20727-3445>
>     >      (e-mail) jcamins at cpbibliography.com
>     <mailto:jcamins at cpbibliography.com>
>     >      (web) http://www.cpbibliography.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/
>
>     > _______________________________________________
>     > 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/
>
>
>     --
>     Chris Cormack
>     Catalyst IT Ltd.
>     +64 4 803 2238 <tel:%2B64%204%20803%202238>
>     PO Box 11-053, Manners St, Wellington 6142, New Zealand
>
>
>
>
> _______________________________________________
> 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/20120309/32a7eb93/attachment-0001.htm>

From paul.poulain at biblibre.com  Fri Mar  9 13:46:28 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 09 Mar 2012 13:46:28 +0100
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
In-Reply-To: <4F59F94D.4070802@inLibro.com>
References: <4F58AD24.4060701@biblibre.com>
	<CA+95qVQO1LwHpvQiwLLAs4d6wS9yLCQDMcY9r4j95G18rtWpvw@mail.gmail.com>
	<4F58EF42.1020805@biblibre.com>
	<CA+95qVTuw2SdC5UwnOKHJ2WLbfJvKFnDue1HpAusAr8qN2qpCA@mail.gmail.com>
	<CAP3yOomLUwGavdr3xGsy_pTgR+HLv5RKJ36Wz+iUCDaPqs1XmQ@mail.gmail.com>
	<028B1A54D03E7B4482CDCA4EC8F06BFD01626672@Bodensee.bsz-bw.de>
	<CALVDfQwvLgzWvwmjO1As=PYpKbGadARe6XFtPCHVavBZ_J0Yzw@mail.gmail.com>
	<CANL=k+GXrR-zszP7bwZWqf7+bZUXo5sSR47d4+3BbnyeXVxEEg@mail.gmail.com>
	<20120308185023.GU6577@rorohiko.wgtn.cat-it.co.nz>,
	<CANL=k+F8teBenJ0Cqnr9AC0NE1rTu-oY+NP15+Yybo3doJBKug@mail.gmail.com>
	<809BE39CD64BFD4EB9036172EBCCFA310954BBF3@S-MAIL-1B.rijksmuseum.intra>
	<4F59F94D.4070802@inLibro.com>
Message-ID: <4F59FBA4.1060702@biblibre.com>

Le 09/03/2012 13:36, Eric B?gin a ?crit :
> Hello all,
> 
> Have we considered using git's hooks for tidifying the code before
> checking it in, or even on the server, this would ensure that whoever
> does the checkin, it will be tidified.
> 
> Also, if we consider going with a global tidifying, a good timing could
> be when creating a new branch.

(this message is not for Eric specifically)
=> do you all have read the IRC discussion ?
http://stats.workbuffer.org/irclog/koha/2012-01-04#i_857956

Most of the points raised on this thread have been discussed,
side-effect, pro and cons explained.

For the "do it on the fly" path, I could be OK to go with it if I
understood how it can be done:
* perltidying only the lines you submit will result in unreadable code
* perltridying a whole file when you submit a patch will result in an
unreadable git blame, like the "big bang" perltidy option
* not everybody uses vim

so, how to achieve the "on the fly" path is still a mystery for me
-- 
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 Mar  9 14:28:17 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 09 Mar 2012 14:28:17 +0100
Subject: [Koha-devel] Fwd: Re:  Some changes to saved queries
In-Reply-To: <CANL=k+GVaQ62dg85eD00dSFAoTdufQXgt4f2pEOux7Qd09EtPA@mail.gmail.com>
References: <CANL=k+GVaQ62dg85eD00dSFAoTdufQXgt4f2pEOux7Qd09EtPA@mail.gmail.com>
Message-ID: <4F5A0571.5090205@biblibre.com>

fwding the discussion I just had with Ian, as I think what we wrote can
be usefull

-------- Message original --------
Sujet: 	Re: [Koha-devel] Some changes to saved queries
Date : 	Fri, 9 Mar 2012 07:49:58 -0500
De : 	Ian Walls <koha.sekjal at gmail.com>
Pour : 	Paul Poulain <paul.poulain at biblibre.com>



I would agree a default chronological sort for these reports would be
the best.  It doesn't affect how I do my QA, and can provide some
valuable extra info to everyone.

++

Ian

On Mar 9, 2012 6:28 AM, "Paul Poulain" <paul.poulain at biblibre.com
<mailto:paul.poulain at biblibre.com>> wrote:

    Le 09/03/2012 12:24, Ian Walls wrote:
    > For my end, I don't always QA in the order the report gives. Some
    > patches are much quicker to evaluate than others, and the blocks
    of time
    > I have to do QA are of varying lengths and intensities. So, I pick the
    > combination of bug reports that look like they'd fit into the time
    I have.
    >
    > Not the most systematic approach, but effective.
    I know, I understand and I agree. One could also say that a "BLO" bug
    must be QAed before an ENH.
    My main concern here is that everybody is aware that there are some
    patches that are waiting for a long period.

    If you look at the 10 patches that need signoff for more than 2 months,
    most of them are quite tricky (and probably boring). But at least we
    know that they're waiting. Otherwise, they're lost in the middle of
    other patches !

    PS: and i'm just asking for the DEFAULT order, that you can change in 1
    clic. I don't request a rule saying "one MUST signoff/QA/..." in last
    change date order (even if I think it would not be a silly rule, it's
    not an applicable one for our community)

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

From tajoli at cilea.it  Fri Mar  9 14:34:30 2012
From: tajoli at cilea.it (tajoli at cilea.it)
Date: Fri, 09 Mar 2012 14:34:30 +0100 (CET)
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
In-Reply-To: <4F58AD24.4060701@biblibre.com>
Message-ID: <ea192c08-3cd3-4647-863d-0970328c315e@esx-revenge>

Hi to all,

----- Messaggio originale -----
> Da: "Paul Poulain" <paul.poulain at biblibre.com>
> A: koha-devel at lists.koha-community.org
> Inviato: Gioved?, 8 marzo 2012 13:59:16
> Oggetto: [Koha-devel] Koha 3.8 release schedule & perltidy process
> 
> Hello koha-devel,
> 
> IMPORTANT = perltidy process
> 
> In january IRC meeting we spoke of perltidy thing. We have a coding
> guideline rule that says code must be perltidied. However, all the
> existing code is not perltidied, and it's hard to mix perltidied and
> non
> perltidied code.
> Thus, we have investigated the idea of doing a "perltidy big-bang"
> just
> when releasing 3.8.0, for all the code.

personaly speaking I'm for a "perltidy big-bang" during release.
If not, I think that to apply a perltidy we need to work on WHOLE
file.
I suggest to start from C4 libraries, with a specific commit that do only
a perltidy chage.

I we don't start we never do it.

Bye
Zeno Tajoli

From Anthony.Laquerre at ccsr.qc.ca  Fri Mar  9 14:35:26 2012
From: Anthony.Laquerre at ccsr.qc.ca (Laquerre, Anthony)
Date: Fri, 9 Mar 2012 13:35:26 +0000
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
In-Reply-To: <4F59FBA4.1060702@biblibre.com>
References: <4F58AD24.4060701@biblibre.com>
	<CA+95qVQO1LwHpvQiwLLAs4d6wS9yLCQDMcY9r4j95G18rtWpvw@mail.gmail.com>
	<4F58EF42.1020805@biblibre.com>
	<CA+95qVTuw2SdC5UwnOKHJ2WLbfJvKFnDue1HpAusAr8qN2qpCA@mail.gmail.com>
	<CAP3yOomLUwGavdr3xGsy_pTgR+HLv5RKJ36Wz+iUCDaPqs1XmQ@mail.gmail.com>
	<028B1A54D03E7B4482CDCA4EC8F06BFD01626672@Bodensee.bsz-bw.de>
	<CALVDfQwvLgzWvwmjO1As=PYpKbGadARe6XFtPCHVavBZ_J0Yzw@mail.gmail.com>
	<CANL=k+GXrR-zszP7bwZWqf7+bZUXo5sSR47d4+3BbnyeXVxEEg@mail.gmail.com>
	<20120308185023.GU6577@rorohiko.wgtn.cat-it.co.nz>,
	<CANL=k+F8teBenJ0Cqnr9AC0NE1rTu-oY+NP15+Yybo3doJBKug@mail.gmail.com>
	<809BE39CD64BFD4EB9036172EBCCFA310954BBF3@S-MAIL-1B.rijksmuseum.intra>
	<4F59F94D.4070802@inLibro.com> <4F59FBA4.1060702@biblibre.com>
Message-ID: <F680EA6566032E4E94FFBB064D4848631158409E@06FDSRV.fedecegeps.qc.ca>

Hi Paul, all,
We had to do exactly the same kind of process on another project couple of years ago ( in java ) 

We had decided, at that time, to go gradually and the way we did it was always by "function that you touch".

At the end our, QA team ask us to still be able to understand what is the change even if look of the code can be really different.

Anthony


-----Message d'origine-----
De : koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] De la part de Paul Poulain
Envoy? : 9 mars 2012 07:46
? : koha-devel at lists.koha-community.org
Objet : Re: [Koha-devel] Koha 3.8 release schedule & perltidy process

Le 09/03/2012 13:36, Eric B?gin a ?crit :
> Hello all,
> 
> Have we considered using git's hooks for tidifying the code before 
> checking it in, or even on the server, this would ensure that whoever 
> does the checkin, it will be tidified.
> 
> Also, if we consider going with a global tidifying, a good timing 
> could be when creating a new branch.

(this message is not for Eric specifically) => do you all have read the IRC discussion ?
http://stats.workbuffer.org/irclog/koha/2012-01-04#i_857956

Most of the points raised on this thread have been discussed, side-effect, pro and cons explained.

For the "do it on the fly" path, I could be OK to go with it if I understood how it can be done:
* perltidying only the lines you submit will result in unreadable code
* perltridying a whole file when you submit a patch will result in an unreadable git blame, like the "big bang" perltidy option
* not everybody uses vim

so, how to achieve the "on the fly" path is still a mystery for me
--
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 cnighswonger at foundations.edu  Fri Mar  9 14:44:41 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Fri, 9 Mar 2012 08:44:41 -0500
Subject: [Koha-devel] Fwd: [LIS-Forum] Mysore University Koha OPAC on
	Mobile
In-Reply-To: <CA+3iuR6vWsDKh0B7BkjU5osHtmf=NsSf=LbrDXFNsZ6Jz6-imw@mail.gmail.com>
References: <CA+3iuR6vWsDKh0B7BkjU5osHtmf=NsSf=LbrDXFNsZ6Jz6-imw@mail.gmail.com>
Message-ID: <CAP3yOo=7Ze115k=N-KN2Bnf1LoBrnHDQ3Y0KB+dS2cWdvpS37w@mail.gmail.com>

So is there any chance this will be contributed back to the community?

Kind Regards,
Chris


2012/3/9 SANDEEP BHAVSAR <sandeep.bhavsar at gmail.com>

>
>
> ---------- Forwarded message ----------
> From: Ishwar Goudar <goudarishwar at googlemail.com>
> Date: Thu, Mar 8, 2012 at 7:39 PM
> Subject: [LIS-Forum] Mysore University OPAC on Mobile
> To: lis-forum at ncsi.iisc.ernet.in, francis at ncsi.iisc.ernet.in
>
>
> Dear Professionals,
>
> I am  happy inform you all that our University Library Web OPAC has gone
> the
> * mobile way*.  We
> have adopted open source library automation system KOHA for all our house
> keeping activities
> including OPAC and the same has been made available in cloud hosting
> environment. Anybody
> can access our  OPAC on *Mobile* at  site
> http://mopac.mysore-univ.org/
>
> To see what it looks like in a mobile phone, please use following site on
> your desktop/laptop:
> http://iphonetester.com/?url=http://mopac.mysore-univ.org/
>
> Apple claims to have sold record number of Smart-phones smashing the the
> record of PC sales.  The same has
> been the fate with Laptops and notebooks.
> (
>
> http://www.digitaltrends.com/mobile/smartphone-sales-exceed-those-of-pcs-for-first-time-apple-smashes-record/
> )
> Internet access through Mobile has become the order of the day.  This being
> the case, I strongly feel that all of us
> should go the mobile way for our OPACs.
>
> Our patrons can use their mobile for reserving, renewing the documents and
> all related activities.
> We are working towards using Mobile SMSs for overdue reminders, informing
> the availability of
> reserved documents, documents purchased against requests, broadcasting
> important library
> related messages, etc.
>
> The automation model we have adopted is *-*  Centralised database,
> decentralised inputting/
> housekeeping activities and Universal access to OPAC. Once completed the
> OPAC will
> have > 10 Lakh records of documents available in colleges, institutes, PG
> Centres and various
> departments, which are directly under the control of Mysore University.
>
> We acknowledge OSS Labs, Bangalore for having  given quality, timely and
> cost effective service to us
> in this matter. Probably ours is the first university library to go mobile
> way for OPAC (?).  Please have a
>  look at it and give your feedback, enabling us to improve the service.
>
>
> Regards,
>
> Dr. I.R.N. Goudar
> Visiting professor and Library Adviser
> University of Mysore
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://ncsi.iisc.ernet.in/pipermail/lis-forum/attachments/20120308/753cc29a/attachment.html
> >
> _______________________________________________
> LIS-Forum mailing list
> LIS-Forum at ncsi.iisc.ernet.in
> http://ncsi.iisc.ernet.in/mailman/listinfo/lis-forum
>
>
>
> --
> Thanks and Regards
>
> Sandeep Bhavsar
> Librarian
> Dr.V.N.Bedekar Institute of Management Studies
> Thane(W) 400601
> MUMBAI. INDIA
> @@@@@@@@@@@@@@@@@@@@@@@@@@
> email    : sandeep.bhavsar at gmail.com
> Mob     : 9029 345777
> elibrary :http://www.vpmthane.org/im/elib/main.htm
> @@@@@@@@@@@@@@@@@@@@@@@@@@
>
> _______________________________________________
> 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/20120309/e072a278/attachment.htm>

From paul.poulain at biblibre.com  Fri Mar  9 16:41:12 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 09 Mar 2012 16:41:12 +0100
Subject: [Koha-devel] User configurable slips pushed (bug 7001,
 call for more testing)
In-Reply-To: <4F59F8A2.3050104@biblibre.com>
References: <4F59DE5C.8020004@biblibre.com>
	<CAJzKNY6qROBOWkS=Hr+iaPjWPq3RwnaonUFBojdEMvcgw+K-WQ@mail.gmail.com>
	<4F59F8A2.3050104@biblibre.com>
Message-ID: <4F5A2498.5070106@biblibre.com>

Le 09/03/2012 13:33, Paul Poulain a ?crit :
> Le 09/03/2012 12:44, Jonathan Druart a ?crit :
>> This patch breaks the feature introduced by Bug 5347. In this patch, I
>> have already make a refactoring of C4::Letters::SendAlerts
> 
> Could you give some details about what is broken ?

OK, I just spoke with Jonathan, and, definetly, the 7001 patch badly
break something that has been commited on january, 20th.
I'll revert it immediatly, srdjan, you'll have to work a little bit more
on it, sorry for that

-- 
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 Mar  9 16:47:46 2012
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Sat, 10 Mar 2012 04:47:46 +1300
Subject: [Koha-devel] User configurable slips pushed (bug 7001,
 call for more testing)
In-Reply-To: <4F5A2498.5070106@biblibre.com>
References: <4F59DE5C.8020004@biblibre.com>
	<CAJzKNY6qROBOWkS=Hr+iaPjWPq3RwnaonUFBojdEMvcgw+K-WQ@mail.gmail.com>
	<4F59F8A2.3050104@biblibre.com> <4F5A2498.5070106@biblibre.com>
Message-ID: <CA+95qVRSxB7pWBgM-+bVhU6dBu0c4-PWn1t=PFSMxtxU9g1rKw@mail.gmail.com>

You will need to provide much more info than that for it to be actually
useful.

Like what was broken and how.

Chris
On Mar 10, 2012 4:41 AM, "Paul Poulain" <paul.poulain at biblibre.com> wrote:

> Le 09/03/2012 13:33, Paul Poulain a ?crit :
> > Le 09/03/2012 12:44, Jonathan Druart a ?crit :
> >> This patch breaks the feature introduced by Bug 5347. In this patch, I
> >> have already make a refactoring of C4::Letters::SendAlerts
> >
> > Could you give some details about what is broken ?
>
> OK, I just spoke with Jonathan, and, definetly, the 7001 patch badly
> break something that has been commited on january, 20th.
> I'll revert it immediatly, srdjan, you'll have to work a little bit more
> on it, sorry for that
>
> --
> 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/20120310/3d88915f/attachment-0001.htm>

From claire.hernandez at biblibre.com  Fri Mar  9 16:51:02 2012
From: claire.hernandez at biblibre.com (Claire Hernandez)
Date: Fri, 09 Mar 2012 16:51:02 +0100
Subject: [Koha-devel] Rebasing Solr devs at Hackfest
Message-ID: <4F5A26E6.9050304@biblibre.com>

Hello,

Just to say I'm eager to do things for Solr integration in Koha 
community version during Hackfest in Marseille in 10 days! There are 5 
full days, I am not alone so we can start something usefull.

I would like to know who is interested to test things, give feedback to 
move forward this week (and after). I already have some names ;)

Feel free to write me to explain your vision (or encourage us :), give 
tips, offer help etc.!

Thanks!
Claire.

From marc.boivin at libeo.com  Fri Mar  9 17:05:16 2012
From: marc.boivin at libeo.com (Marc Boivin)
Date: Fri, 9 Mar 2012 11:05:16 -0500
Subject: [Koha-devel] Mobile friendly OPAC
Message-ID: <CF9BE4E3-592C-4866-957A-EFFE8237FADA@libeo.com>

Hi all,
          We've been working a mobile friendly OPAC, you can find it here https://dev3.koha.sys-tech.net/ (please be gently it's a development server, very little resources). I did not want to post it on en general list, because the server can't handle much. To test it, either use a mobile device or, in a modern browser, shrink the width of your window till around 700 pixels. 

What we've done, using CSS Media Queries, is:

* Remove as much noise as possible to focus on simple search and record consulting. 
* Simplified the advance research, only reachable if there is no search results
* Reformatted opac-detail

Next thing on our list is user login, we hope to have it done by the end of next week. We would like to give this feature back to the community. But first I'd like to get input on what would be nice, what's missing, what you generally think of the idea. 

TIA,

Marc

Marc Boivin
Charg? de projet Web

418 520-0739, poste 169
marc.boivin at libeo.com

Lib?o / Web et applications libres
6700, boulevard Pierre-Bertrand, bureau 209
Qu?bec (Qu?bec)  G2J 0B4

S. F. : 1 877 969-8324
T?l?c. : 418 520-4554
www.libeo.com

Aimez-nous sur Facebook : www.facebook.com/libeocom

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

From paul.poulain at biblibre.com  Fri Mar  9 17:26:49 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 09 Mar 2012 17:26:49 +0100
Subject: [Koha-devel] User configurable slips pushed (bug 7001,
 call for more testing)
In-Reply-To: <CA+95qVRSxB7pWBgM-+bVhU6dBu0c4-PWn1t=PFSMxtxU9g1rKw@mail.gmail.com>
References: <4F59DE5C.8020004@biblibre.com>
	<CAJzKNY6qROBOWkS=Hr+iaPjWPq3RwnaonUFBojdEMvcgw+K-WQ@mail.gmail.com>
	<4F59F8A2.3050104@biblibre.com> <4F5A2498.5070106@biblibre.com>
	<CA+95qVRSxB7pWBgM-+bVhU6dBu0c4-PWn1t=PFSMxtxU9g1rKw@mail.gmail.com>
Message-ID: <4F5A2F49.7030605@biblibre.com>

Le 09/03/2012 16:47, Chris Cormack a ?crit :
> You will need to provide much more info than that for it to be actually
> useful.

Jonathan justa added some information on the bug
(http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7001#c90)

Srdjan, let us know if that's not enough, it could be not that hard to fix.

PLUS : I realize not that easy to revert those patches, because they
include a DBREv (023), and I've already pushed the 024, so I would have
to revert it.
So I won't revert immediatly, but won't push anything more for today .
Srdjan (or anyone else), if I had a patch available on monday, I would
be very happy not to have to revert this great feature, (that would be a
pain for me too)


PS: for future reference = this patch was too large. It was making too
many things at once. I think it could have been validated more easily
and faster with smaller chunks. Like one for introducing html, one for
introducing branch letter, one for ...
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From savitra.sirohi at osslabs.biz  Sat Mar 10 09:15:06 2012
From: savitra.sirohi at osslabs.biz (savitra sirohi)
Date: Sat, 10 Mar 2012 13:45:06 +0530
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process --
	more time?
In-Reply-To: <4F59C19C.9020107@biblibre.com>
References: <CAOC8d3Ak=toxmxCQ7Wk_xU3zdeJh=iBhxzY8K8tAb9yiOUydOQ@mail.gmail.com>
	<4F59C19C.9020107@biblibre.com>
Message-ID: <CAOC8d3CJG-hA_gNj2HWUPEnT+ugJ-L2oi41K3ett_nFKQPtiSA@mail.gmail.com>

Thanks Paul, I guess we will go ahead and start submitting and hope some of
our submissions gets included. No strong reason to get this included in
3.8, other than us having to rebase multiple times.

In any case, here are some of the changes we want to submit at this stage,
some already have bugzilla entries, I will create new ones for others:

Major
Maintain exchange rate history, Indian libraries need to pay for items with
rates as on invoice date, which can be in the past
Events on OPAC - create events with date, description, images, and other
fields (similar to News) for display on OPAC
Mobile friendly site, modified template files
Capture photo, signature via webcam and electronic signature pad
Fees - registration, renewal, duplicate card, holds at library and category
level

Minor
Forgot password link, so users can request a new password to be sent to them
Fee receipts for printing, including auto receipt no. generation
Show links to possible duplicate orders/catalog records in order basket.
Staff can verify duplicate before issuing firm orders
Renew serials subscriptions in batch
Quick patron card print (from patron record after registration)
Show entitlements to members in OPAC, essentially make circ rules that
apply to a member visible to them via OPAC
Allow holds on "on display" items even when allowonshelfholds is off
(system pref based)
Based on a new system preference set email as default user name (instead of
combination of first and surnames) when member is created
Setup barcode and member card prefixes at branch level
Kid friendlly OPAC system preference, e.g. large call numbers, buttons for
search by title, author, subject instead of a drop down list
Allow search by Lexile no. and Accelerated reading point and level ranges
on OPAC and staff search filters
Better items.content for use in notices, e.g. due date, price to be added
Allow SIP authentication using userid or cardnumber (currently works only
with cardnumber)
Save or Export reports output in PDF and text formats (currently only
delimited files are exported)
Export/print new arrivals reports in ISBD formats
Add new tables, keys and criteria in guided reports wizards
Add several new fields such as statement of responsibility to normal view
(TT and XSLT) in catalog details page in OPAC/Staff
Capture suggestor's id when library staff create suggestions
More statuses when managing suggestions (e.g. duplicate)
Capture accepted, rejected date of suggestions for reporting purposes
Several new fields/tables available for use in notice templates
Display link to items in PROC (processing center) in cataloging home, this
will allow processing center staff to easily identify records they need to
work on
Include Syspref based Google (or other) Analytics JS code
Add more languages to Google Indic Transliteration tool availble with the
masthead search box
Allow extend patron attributes to be included in patron card templates
Syspref to not do remote ip check, this will allow uninterrupted Koha
access from locations where ip address changs dynamically
Change default password length to 7
Open Library - Larger image, Read, borrow and checked-out status
Send renewal notice
Send membership expiry reminder notices
Add Item availability status to cart
Batch userid, password generation and email
Display barcode on OPAC detail page

Thanks,
Savitra Sirohi
Nucsoft OSS Labs
http://www.osslabs.biz

On Fri, Mar 9, 2012 at 2:08 PM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Le 09/03/2012 05:09, savitra sirohi a ?crit :
> > Hi Paul,
> Hi Savitra,
>
> > we have been caught off-guard by this schedule.
> The schedule is the same as what we had for previous time-based-release.
> I agree that my announcement could have be made a little bit earlier,
> but you can, for future releases, consider the "1 month before the
> release" as the "feature freeze" limit. We need time to do some tests,
> translations,... so we can't freeze things only a few days before the
> release.
>
> > We have a lot of stuff to submit but March 23rd is too little time. If
> > we have 2 more weeks, we can get good stuff included. Possible?
> Well, I can't answer this question so easily, I'll start by asking more
> questions:
> * could you give us more details about the stuff that will be submitted ?
> * are you aware that, even if you submit before march 23, it must also
> be signed-off, QAed, and, if it's large change, that won't be made in a
> second ? atm, there are 82 patches waiting for sign-off, 12 of them
> being waiting for more than 2 months !
> * Is there a really strong reason to have those features need for 3.8 ?
> all/many of us have a lot of nice/cool stuff that is waiting for
> inclusion (almost 50% of the patches waiting for signoff are coming from
> BibLibre 39/82).
>
> --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
>



-- 
Thanks,
Savitra Sirohi
Nucsoft OSS Labs
Professional Support for Open Source Software
Ph: +91 89718 06111
Web: http://www.osslabs.biz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120310/d0c7a64a/attachment.htm>

From mtj at kohaaloha.com  Sat Mar 10 14:20:10 2012
From: mtj at kohaaloha.com (Mason James)
Date: Sun, 11 Mar 2012 02:20:10 +1300
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310954BBF3@S-MAIL-1B.rijksmuseum.intra>
References: <4F58AD24.4060701@biblibre.com>
	<CA+95qVQO1LwHpvQiwLLAs4d6wS9yLCQDMcY9r4j95G18rtWpvw@mail.gmail.com>
	<4F58EF42.1020805@biblibre.com>
	<CA+95qVTuw2SdC5UwnOKHJ2WLbfJvKFnDue1HpAusAr8qN2qpCA@mail.gmail.com>
	<CAP3yOomLUwGavdr3xGsy_pTgR+HLv5RKJ36Wz+iUCDaPqs1XmQ@mail.gmail.com>
	<028B1A54D03E7B4482CDCA4EC8F06BFD01626672@Bodensee.bsz-bw.de>
	<CALVDfQwvLgzWvwmjO1As=PYpKbGadARe6XFtPCHVavBZ_J0Yzw@mail.gmail.com>
	<CANL=k+GXrR-zszP7bwZWqf7+bZUXo5sSR47d4+3BbnyeXVxEEg@mail.gmail.com>
	<20120308185023.GU6577@rorohiko.wgtn.cat-it.co.nz>,
	<CANL=k+F8teBenJ0Cqnr9AC0NE1rTu-oY+NP15+Yybo3doJBKug@mail.gmail.com>
	<809BE39CD64BFD4EB9036172EBCCFA310954BBF3@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <BC5167B2-410C-4C84-B070-6687D23A973E@kohaaloha.com>


On 2012-03-9, at 10:16 PM, Marcel de Rooy wrote:

> +1 for a gradual perl tidy too

+1 to a gradual perltidy from me too



> >    So, best to keep cleaning up incrementally, I think.A  As we move from C4
> >    to Koha, that'll be an opportunity to clean up all the modules
> >
> >    -Ian
> >
> >    2012/3/8 Jared Camins-Esakov <jcamins at cpbibliography.com>
> >
> >      +1 to a gradual perltidy
> >
> >      2012/3/8 Fischer, Katrin <Katrin.Fischer at bsz-bw.de>
> >
> >        I agree with Chris C. and Chris N. - I think what we would win does
> >        not outweigh the loss of history.
> >
> >        Katrin
> >
> >        2012/3/8 Chris Cormack <chris at bigballofwax.co.nz>
> >
> >        > My counter proposal is tidy as you go. Fix code as you touch it.
> >        >
> >        > With vim (and other editors) you can easily tidy a block, doing that
> >        as
> >        > code is changed would be my preference.
> >        >


> >
> >        I'd prefer a "pay-as-you-go" approach as well. We could simply require
> >        all
> >        work to be tidied before submitting.
> >
> >        Slow? Yes, but not nearly as messy and preserves the history.
> >
> >        Kind Regards,
> >        Chris
> >

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20120311/8bbdf616/attachment.pgp>

From srdjan at catalyst.net.nz  Sun Mar 11 23:56:58 2012
From: srdjan at catalyst.net.nz (Srdjan)
Date: Mon, 12 Mar 2012 08:56:58 +1000
Subject: [Koha-devel] User configurable slips pushed (bug 7001,
 call for more testing)
In-Reply-To: <4F5A2F49.7030605@biblibre.com>
References: <4F59DE5C.8020004@biblibre.com>
	<CAJzKNY6qROBOWkS=Hr+iaPjWPq3RwnaonUFBojdEMvcgw+K-WQ@mail.gmail.com>
	<4F59F8A2.3050104@biblibre.com> <4F5A2498.5070106@biblibre.com>
	<CA+95qVRSxB7pWBgM-+bVhU6dBu0c4-PWn1t=PFSMxtxU9g1rKw@mail.gmail.com>
	<4F5A2F49.7030605@biblibre.com>
Message-ID: <4F5D2DBA.3070004@catalyst.net.nz>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 10/03/12 02:26, Paul Poulain wrote:
> PS: for future reference = this patch was too large. It was making too
many things at once. I think it could have been validated more easily
and faster with smaller chunks. Like one for introducing html, one for
introducing branch letter, one for ...

I agree with this and like to discuss it but not on the bug of course.
How do you usually discuss things here that are of general nature?

Srdjan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9dLboACgkQX6p/D9UE7dwRkQCgiDBDYu9LvMwDbw708xm21bKd
02MAnjQYc7AQbnO05fcw4atEDaYGCeGs
=3SeT
-----END PGP SIGNATURE-----


From srdjan at catalyst.net.nz  Mon Mar 12 01:29:19 2012
From: srdjan at catalyst.net.nz (Srdjan)
Date: Mon, 12 Mar 2012 10:29:19 +1000
Subject: [Koha-devel] User configurable slips pushed (bug 7001,
 call for more testing)
In-Reply-To: <4F5A2F49.7030605@biblibre.com>
References: <4F59DE5C.8020004@biblibre.com>
	<CAJzKNY6qROBOWkS=Hr+iaPjWPq3RwnaonUFBojdEMvcgw+K-WQ@mail.gmail.com>
	<4F59F8A2.3050104@biblibre.com> <4F5A2498.5070106@biblibre.com>
	<CA+95qVRSxB7pWBgM-+bVhU6dBu0c4-PWn1t=PFSMxtxU9g1rKw@mail.gmail.com>
	<4F5A2F49.7030605@biblibre.com>
Message-ID: <4F5D435F.4080905@catalyst.net.nz>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 10/03/12 02:26, Paul Poulain wrote:
> PLUS : I realize not that easy to revert those patches, because they
include a DBREv (023), and I've already pushed the 024, so I would have
to revert it. So I won't revert immediatly, but won't push anything more
for today .
I would ask for this not to be reverted please. Rebasing it is a
nightmare. The thing was all over the place, and now at least we have a
consistent interface. I'll do my best to fix all conflicts and bugs
found in testing, just don't revert it. I lost some hair in the process,
and I don't have much left...

> Srdjan (or anyone else), if I had a patch available on monday, I would
be very happy not to have to revert this great feature, (that would be a
pain for me too)

I cannot replicate the error, but I'll fix it as soon as I can. It is
just one alert, so should not be a show stopper.

Srdjan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9dQ18ACgkQX6p/D9UE7dyKWwCeJ/x5Q+yigvs86QYrvaGkR9Ky
1/QAnjAjz5Klij8IM8An161Zoez03fSk
=sJSQ
-----END PGP SIGNATURE-----


From fridolyn.somers at gmail.com  Mon Mar 12 09:19:59 2012
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Mon, 12 Mar 2012 09:19:59 +0100
Subject: [Koha-devel] Koha 3.8 release schedule & perltidy process
In-Reply-To: <BC5167B2-410C-4C84-B070-6687D23A973E@kohaaloha.com>
References: <4F58AD24.4060701@biblibre.com>
	<CA+95qVQO1LwHpvQiwLLAs4d6wS9yLCQDMcY9r4j95G18rtWpvw@mail.gmail.com>
	<4F58EF42.1020805@biblibre.com>
	<CA+95qVTuw2SdC5UwnOKHJ2WLbfJvKFnDue1HpAusAr8qN2qpCA@mail.gmail.com>
	<CAP3yOomLUwGavdr3xGsy_pTgR+HLv5RKJ36Wz+iUCDaPqs1XmQ@mail.gmail.com>
	<028B1A54D03E7B4482CDCA4EC8F06BFD01626672@Bodensee.bsz-bw.de>
	<CALVDfQwvLgzWvwmjO1As=PYpKbGadARe6XFtPCHVavBZ_J0Yzw@mail.gmail.com>
	<CANL=k+GXrR-zszP7bwZWqf7+bZUXo5sSR47d4+3BbnyeXVxEEg@mail.gmail.com>
	<20120308185023.GU6577@rorohiko.wgtn.cat-it.co.nz>
	<CANL=k+F8teBenJ0Cqnr9AC0NE1rTu-oY+NP15+Yybo3doJBKug@mail.gmail.com>
	<809BE39CD64BFD4EB9036172EBCCFA310954BBF3@S-MAIL-1B.rijksmuseum.intra>
	<BC5167B2-410C-4C84-B070-6687D23A973E@kohaaloha.com>
Message-ID: <CAN6cLAWig5CwbsXYTy=LiFR7wDAdw-k9uNXHdTzwbGiMjFDrnA@mail.gmail.com>

+1 to a gradual perltidy.

In this case, we should add a comment on processed files like :
"#format by perltidy" ie

-- 
Fridolyn SOMERS
fridolyn.somers at gmail.com
Marsillargues - France
<fridolyn.somers at gmail.com>

2012/3/10 Mason James <mtj at kohaaloha.com>

>
> On 2012-03-9, at 10:16 PM, Marcel de Rooy wrote:
>
> > +1 for a gradual perl tidy too
>
> +1 to a gradual perltidy from me too
>
>
>
> > >    So, best to keep cleaning up incrementally, I think.A  As we move
> from C4
> > >    to Koha, that'll be an opportunity to clean up all the modules
> > >
> > >    -Ian
> > >
> > >    2012/3/8 Jared Camins-Esakov <jcamins at cpbibliography.com>
> > >
> > >      +1 to a gradual perltidy
> > >
> > >      2012/3/8 Fischer, Katrin <Katrin.Fischer at bsz-bw.de>
> > >
> > >        I agree with Chris C. and Chris N. - I think what we would win
> does
> > >        not outweigh the loss of history.
> > >
> > >        Katrin
> > >
> > >        2012/3/8 Chris Cormack <chris at bigballofwax.co.nz>
> > >
> > >        > My counter proposal is tidy as you go. Fix code as you touch
> it.
> > >        >
> > >        > With vim (and other editors) you can easily tidy a block,
> doing that
> > >        as
> > >        > code is changed would be my preference.
> > >        >
>
>
> > >
> > >        I'd prefer a "pay-as-you-go" approach as well. We could simply
> require
> > >        all
> > >        work to be tidied before submitting.
> > >
> > >        Slow? Yes, but not nearly as messy and preserves the history.
> > >
> > >        Kind Regards,
> > >        Chris
> > >
>
>
> _______________________________________________
> 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/
>



<fridolyn.somers at gmail.com>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20120312/f8d2bfb2/attachment.htm>

From paul.poulain at biblibre.com  Mon Mar 12 09:38:21 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Mon, 12 Mar 2012 09:38:21 +0100
Subject: [Koha-devel] User configurable slips pushed (bug 7001,
 call for more testing)
In-Reply-To: <4F5D2DBA.3070004@catalyst.net.nz>
References: <4F59DE5C.8020004@biblibre.com>
	<CAJzKNY6qROBOWkS=Hr+iaPjWPq3RwnaonUFBojdEMvcgw+K-WQ@mail.gmail.com>
	<4F59F8A2.3050104@biblibre.com> <4F5A2498.5070106@biblibre.com>
	<CA+95qVRSxB7pWBgM-+bVhU6dBu0c4-PWn1t=PFSMxtxU9g1rKw@mail.gmail.com>
	<4F5A2F49.7030605@biblibre.com> <4F5D2DBA.3070004@catalyst.net.nz>
Message-ID: <4F5DB5FD.1050605@biblibre.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 11/03/2012 23:56, Srdjan a ?crit :
> I agree with this and like to discuss it but not on the bug of
> course. How do you usually discuss things here that are of general
> nature?

I'm not sure there's something to discuss.
We (BibLibre) made this mistake for 3.4 = we submitted a lot of new
features in very large bunches, that were very hard/impossible to
test. Most of them have been splitted in smaller chunks, and in
smallest chunks.
Almost everything is now included, except the changes to issuing rules
- -that was a great feature, that is live for many of our customers- :
it mixed changes in issuing rules, smart-rules entering, hold rules,
and conflicted with hard due date. At the end, we (BibLibre) have
abandonned rebases for this, because it was too hard. And the feature
is now lost, our customers are warned that, when migrating to 3.6
they'll loose some features.

If you look at our new submissions for acquisitions & serials, you can
see that we've learnt, and now submit only atomic features as much as
possible.

(If you have an idea of a discussion, feel free to start it here)
- -- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPXbX9AAoJEK81SonuhyGoUoYIALI1eK5CNif97LCB87l3VbBB
RZuijIkAUVw3PjOPg3T6O7KTXJRcXa2CYpMsoglqYEvM7Ye2Iwp/4JTrEpBGXtxn
x8e2HHXsxkKWD+jlaLDiAS8JT4eI0RIeuztOw56sEvfEnc0P2HxHWoA6RHl/yDWO
yRAHtRCDuIxof7L/Yvi2ajBbR1EVrvtU5htkSbVFgauhMepLiY9tmMLF3rfE8iMC
psGsDVdzIGjpzwLRmIJ6RJh+pTjip2POxzEv4sxh6qy59E74jCz9Gfh5P9aDASQc
HET0ns0hRJ/yrbL6rhircf5u8lUtsBki1NrU9EA+Cgc9s7xtWHvobo4eerCFg5o=
=EfFy
-----END PGP SIGNATURE-----

From srdjan at catalyst.net.nz  Mon Mar 12 23:12:48 2012
From: srdjan at catalyst.net.nz (Srdjan)
Date: Tue, 13 Mar 2012 11:12:48 +1300
Subject: [Koha-devel] User configurable slips pushed (bug 7001,
 call for more testing)
In-Reply-To: <4F5DB5FD.1050605@biblibre.com>
References: <4F59DE5C.8020004@biblibre.com>
	<CAJzKNY6qROBOWkS=Hr+iaPjWPq3RwnaonUFBojdEMvcgw+K-WQ@mail.gmail.com>
	<4F59F8A2.3050104@biblibre.com> <4F5A2498.5070106@biblibre.com>
	<CA+95qVRSxB7pWBgM-+bVhU6dBu0c4-PWn1t=PFSMxtxU9g1rKw@mail.gmail.com>
	<4F5A2F49.7030605@biblibre.com> <4F5D2DBA.3070004@catalyst.net.nz>
	<4F5DB5FD.1050605@biblibre.com>
Message-ID: <4F5E74E0.6090801@catalyst.net.nz>

I'd like to discuss the mechanics of it.
Let's say we split our change into 4 smaller changes, and have a 
following situation:
2 depends on 1
3 and 4 depend on 2

* how do we make sure they are applied in right order
* after a while 1 and 3 had to be reworked; again we need to make sure 
they are applied in order
* let's say we are lucky and 1 gets pushed to master, 2 and 3 are 
signed-off and 4 is being worked on; how do we manage status etc?

Waiting for sign-off in the order does not help, issues may arise after 
sign-off

Srdjan

On 12/03/12 21:38, Paul Poulain wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Le 11/03/2012 23:56, Srdjan a ?crit :
>> I agree with this and like to discuss it but not on the bug of
>> course. How do you usually discuss things here that are of general
>> nature?
>
> I'm not sure there's something to discuss.
> We (BibLibre) made this mistake for 3.4 = we submitted a lot of new
> features in very large bunches, that were very hard/impossible to
> test. Most of them have been splitted in smaller chunks, and in
> smallest chunks.
> Almost everything is now included, except the changes to issuing rules
> - -that was a great feature, that is live for many of our customers- :
> it mixed changes in issuing rules, smart-rules entering, hold rules,
> and conflicted with hard due date. At the end, we (BibLibre) have
> abandonned rebases for this, because it was too hard. And the feature
> is now lost, our customers are warned that, when migrating to 3.6
> they'll loose some features.
>
> If you look at our new submissions for acquisitions&  serials, you can
> see that we've learnt, and now submit only atomic features as much as
> possible.
>
> (If you have an idea of a discussion, feel free to start it here)
> - --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJPXbX9AAoJEK81SonuhyGoUoYIALI1eK5CNif97LCB87l3VbBB
> RZuijIkAUVw3PjOPg3T6O7KTXJRcXa2CYpMsoglqYEvM7Ye2Iwp/4JTrEpBGXtxn
> x8e2HHXsxkKWD+jlaLDiAS8JT4eI0RIeuztOw56sEvfEnc0P2HxHWoA6RHl/yDWO
> yRAHtRCDuIxof7L/Yvi2ajBbR1EVrvtU5htkSbVFgauhMepLiY9tmMLF3rfE8iMC
> psGsDVdzIGjpzwLRmIJ6RJh+pTjip2POxzEv4sxh6qy59E74jCz9Gfh5P9aDASQc
> HET0ns0hRJ/yrbL6rhircf5u8lUtsBki1NrU9EA+Cgc9s7xtWHvobo4eerCFg5o=
> =EfFy
> -----END PGP SIGNATURE-----
>


From paul.poulain at biblibre.com  Tue Mar 13 10:54:04 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 13 Mar 2012 10:54:04 +0100
Subject: [Koha-devel] small patches & dependencies (was: User
 configurable slips pushed (bug 7001) )
In-Reply-To: <4F5E74E0.6090801@catalyst.net.nz>
References: <4F59DE5C.8020004@biblibre.com>
	<CAJzKNY6qROBOWkS=Hr+iaPjWPq3RwnaonUFBojdEMvcgw+K-WQ@mail.gmail.com>
	<4F59F8A2.3050104@biblibre.com> <4F5A2498.5070106@biblibre.com>
	<CA+95qVRSxB7pWBgM-+bVhU6dBu0c4-PWn1t=PFSMxtxU9g1rKw@mail.gmail.com>
	<4F5A2F49.7030605@biblibre.com> <4F5D2DBA.3070004@catalyst.net.nz>
	<4F5DB5FD.1050605@biblibre.com> <4F5E74E0.6090801@catalyst.net.nz>
Message-ID: <4F5F193C.4090909@biblibre.com>

Le 12/03/2012 23:12, Srdjan a ?crit :
> I'd like to discuss the mechanics of it.
> Let's say we split our change into 4 smaller changes, and have a
> following situation:
> 2 depends on 1
> 3 and 4 depend on 2

My 2cts:
* you must use dependencies on bugzilla so clearly state that one
block/depend on another
* we (BibLibre) face this problem for acquisition and serials
improvements we are rebasing/submitting now. There are some things that
we don't submit until other things have made their way into Koha.

If the patch workflow goes smoothly, then I think it's a mechanics that
can work. However, we don't have, yet, a priority on signing-off a patch.
It means that a patch that is trivial to test is usually tested faster
than a patch that introduces a feature and requires a large testing.

Should we adopt a rule for the order of sign-off ? I'm not sure at all.
But I think we should find a way to encourage people to test/sign-off
things.

All in one, it's a tricky problem. I agree it adds some overhead on the
work required to submit an enhancement. Everybody must be aware of that.

If you look at this mailing list history (or speak with Chris_c, as we
had some strong discussions about that), you'll see I made some
suggestions to change the current workflow, to have things pushed
faster, to reduce the overhead. Others where afraid of introducing
instability, so my ideas where rejected.
I still think the overhead is something we should try to reduce, but
still haven't be successful in proposing a technical way that is
acceptable for our community.

If you can find a technical solution to reduce overhead without reducing
stability, I'll be the happiest man here probably ;-)


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

From koha.sekjal at gmail.com  Tue Mar 13 20:46:32 2012
From: koha.sekjal at gmail.com (Ian Walls)
Date: Tue, 13 Mar 2012 15:46:32 -0400
Subject: [Koha-devel] small patches & dependencies (was: User
 configurable slips pushed (bug 7001) )
In-Reply-To: <4F5F193C.4090909@biblibre.com>
References: <4F59DE5C.8020004@biblibre.com>
	<CAJzKNY6qROBOWkS=Hr+iaPjWPq3RwnaonUFBojdEMvcgw+K-WQ@mail.gmail.com>
	<4F59F8A2.3050104@biblibre.com> <4F5A2498.5070106@biblibre.com>
	<CA+95qVRSxB7pWBgM-+bVhU6dBu0c4-PWn1t=PFSMxtxU9g1rKw@mail.gmail.com>
	<4F5A2F49.7030605@biblibre.com> <4F5D2DBA.3070004@catalyst.net.nz>
	<4F5DB5FD.1050605@biblibre.com> <4F5E74E0.6090801@catalyst.net.nz>
	<4F5F193C.4090909@biblibre.com>
Message-ID: <CANL=k+GUrHrhhUkvY0gYovjAqX16tZf5FS4jC7QnTXnAZq90Fg@mail.gmail.com>

We've run up against this problem a few times in recent history.  Small
patches are easier to test, but harder to keep track of.  Large patches
make our paperwork simpler, but are much harder to test, and one broken
aspect can delay many functional ones.

I think the first part of the solution is to design your larger projects so
that their dependencies or steps are atomic enough to be broken out into
their own bug reports.  The reports can be linked with dependencies, and
each can be taken in turn.

For bug reports that are a single issue, but contain multiple patches, I
recommend prefixing the first line of the commit message with [STEP 1] or
[STEP 2] or the like.  This could be our internal heuristic for figuring
out in what order patches must be applied.  If two patches don't depend on
each other, either squish them into one, or break them out into separate
bug reports.

Many of us are using Git BZ now for signoff and QA, so it becomes
increasingly important for patches to remain in their proper order.  If you
have to rebase STEP 2, it'd be helpful to folks if you also rebased STEP 3
and beyond, so the patches stay in the right order.  But, when testing, if
this is not the case, it's only a little more work to type "n" in the patch
application dialog  until the right first patch comes up.

Another mechanism for improving turn-around time on patches is to build or
update automated test suites.  These kinds of tests can be built into git
aliases by testers, and run as part of the process.  The more advanced the
tests, the more nuances we can pick up on.

As a wise man once said, there's no silver bullet, but I think with
improved planning, a few community practices and some more test suites,
we'll be able strike the right balance of stability and innovation.


-Ian

On Tue, Mar 13, 2012 at 05:54, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Le 12/03/2012 23:12, Srdjan a ?crit :
> > I'd like to discuss the mechanics of it.
> > Let's say we split our change into 4 smaller changes, and have a
> > following situation:
> > 2 depends on 1
> > 3 and 4 depend on 2
>
> My 2cts:
> * you must use dependencies on bugzilla so clearly state that one
> block/depend on another
> * we (BibLibre) face this problem for acquisition and serials
> improvements we are rebasing/submitting now. There are some things that
> we don't submit until other things have made their way into Koha.
>
> If the patch workflow goes smoothly, then I think it's a mechanics that
> can work. However, we don't have, yet, a priority on signing-off a patch.
> It means that a patch that is trivial to test is usually tested faster
> than a patch that introduces a feature and requires a large testing.
>
> Should we adopt a rule for the order of sign-off ? I'm not sure at all.
> But I think we should find a way to encourage people to test/sign-off
> things.
>
> All in one, it's a tricky problem. I agree it adds some overhead on the
> work required to submit an enhancement. Everybody must be aware of that.
>
> If you look at this mailing list history (or speak with Chris_c, as we
> had some strong discussions about that), you'll see I made some
> suggestions to change the current workflow, to have things pushed
> faster, to reduce the overhead. Others where afraid of introducing
> instability, so my ideas where rejected.
> I still think the overhead is something we should try to reduce, but
> still haven't be successful in proposing a technical way that is
> acceptable for our community.
>
> If you can find a technical solution to reduce overhead without reducing
> stability, I'll be the happiest man here probably ;-)
>
>
> --
> 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/20120313/aa39b9cf/attachment.htm>

From mtj at kohaaloha.com  Wed Mar 14 07:24:59 2012
From: mtj at kohaaloha.com (Mason James)
Date: Wed, 14 Mar 2012 19:24:59 +1300
Subject: [Koha-devel] 2 duplicated commits in the kc.org repo,
	on master branch ?
In-Reply-To: <CANL=k+GUrHrhhUkvY0gYovjAqX16tZf5FS4jC7QnTXnAZq90Fg@mail.gmail.com>
References: <4F59DE5C.8020004@biblibre.com>
	<CAJzKNY6qROBOWkS=Hr+iaPjWPq3RwnaonUFBojdEMvcgw+K-WQ@mail.gmail.com>
	<4F59F8A2.3050104@biblibre.com> <4F5A2498.5070106@biblibre.com>
	<CA+95qVRSxB7pWBgM-+bVhU6dBu0c4-PWn1t=PFSMxtxU9g1rKw@mail.gmail.com>
	<4F5A2F49.7030605@biblibre.com> <4F5D2DBA.3070004@catalyst.net.nz>
	<4F5DB5FD.1050605@biblibre.com> <4F5E74E0.6090801@catalyst.net.nz>
	<4F5F193C.4090909@biblibre.com>
	<CANL=k+GUrHrhhUkvY0gYovjAqX16tZf5FS4jC7QnTXnAZq90Fg@mail.gmail.com>
Message-ID: <24D46D3B-F3D4-44C6-8952-7130C424F809@kohaaloha.com>

hi People


i believe there are 2 duplicated commits in the kc.org repo currently, that need to be corrected
(by deleting 1 commit?)

specifically, these 2 commits....
  http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=50585c34292b7aabfaabeba0db3f83612f55837e
  http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=da920b1da9f2f2895730758659d099245c2e64ba


one of these needs to be deleted?


i'm really a bit confused
the commits seem to be applied *sequentially* in the master branch, yet both commits are identical (how is that possible?)


fyi: the reason i spotted this, was because i was trying to cherry-pick a patch to master, and my merge keep failing on these 2 commits :/
when i deleted 1 of these commits, my merge worked!

anyone got any ideas on this enigmatic situation? :)

Mason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20120314/5f0984db/attachment.pgp>

From mtj at kohaaloha.com  Wed Mar 14 07:30:11 2012
From: mtj at kohaaloha.com (Mason James)
Date: Wed, 14 Mar 2012 19:30:11 +1300
Subject: [Koha-devel] 2 duplicated commits in the kc.org repo,
	on master branch ?
In-Reply-To: <24D46D3B-F3D4-44C6-8952-7130C424F809@kohaaloha.com>
References: <4F59DE5C.8020004@biblibre.com>
	<CAJzKNY6qROBOWkS=Hr+iaPjWPq3RwnaonUFBojdEMvcgw+K-WQ@mail.gmail.com>
	<4F59F8A2.3050104@biblibre.com> <4F5A2498.5070106@biblibre.com>
	<CA+95qVRSxB7pWBgM-+bVhU6dBu0c4-PWn1t=PFSMxtxU9g1rKw@mail.gmail.com>
	<4F5A2F49.7030605@biblibre.com> <4F5D2DBA.3070004@catalyst.net.nz>
	<4F5DB5FD.1050605@biblibre.com> <4F5E74E0.6090801@catalyst.net.nz>
	<4F5F193C.4090909@biblibre.com>
	<CANL=k+GUrHrhhUkvY0gYovjAqX16tZf5FS4jC7QnTXnAZq90Fg@mail.gmail.com>
	<24D46D3B-F3D4-44C6-8952-7130C424F809@kohaaloha.com>
Message-ID: <375EF97F-15E5-44F1-BF05-55937D7BCD9C@kohaaloha.com>


On 2012-03-14, at 7:24 PM, Mason James wrote:

> hi People
> 
> 
> i believe there are 2 duplicated commits in the kc.org repo currently, that need to be corrected
> (by deleting 1 commit?)
> 
> specifically, these 2 commits....
>  http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=50585c34292b7aabfaabeba0db3f83612f55837e
>  http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=da920b1da9f2f2895730758659d099245c2e64ba
> 



these two commits... (a bit more info) :)


commit 50585c34292b7aabfaabeba0db3f83612f55837e
Author: Jonathan Druart <jonathan.druart at biblibre.com>
Date:   Thu Mar 8 10:09:23 2012 +0100

    Bug 5341: Moves the "save" button to the top of the serial receiving
    
    Signed-off-by: Jared Camins-Esakov <jcamins at cpbibliography.com>
    Signed-off-by: Paul Poulain <paul.poulain at biblibre.com>


commit da920b1da9f2f2895730758659d099245c2e64ba
Author: Jonathan Druart <jonathan.druart at biblibre.com>
Date:   Thu Mar 8 10:09:23 2012 +0100

    Bug 5341: Moves the "save" button to the top of the serial receiving
    
    Signed-off-by: Jared Camins-Esakov <jcamins at cpbibliography.com>
    Signed-off-by: Paul Poulain <paul.poulain at biblibre.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20120314/bf824f8c/attachment.pgp>

From cnighswonger at foundations.edu  Wed Mar 14 12:54:38 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Wed, 14 Mar 2012 07:54:38 -0400
Subject: [Koha-devel] 2 duplicated commits in the kc.org repo,
 on master branch ?
In-Reply-To: <375EF97F-15E5-44F1-BF05-55937D7BCD9C@kohaaloha.com>
References: <4F59DE5C.8020004@biblibre.com>
	<CAJzKNY6qROBOWkS=Hr+iaPjWPq3RwnaonUFBojdEMvcgw+K-WQ@mail.gmail.com>
	<4F59F8A2.3050104@biblibre.com> <4F5A2498.5070106@biblibre.com>
	<CA+95qVRSxB7pWBgM-+bVhU6dBu0c4-PWn1t=PFSMxtxU9g1rKw@mail.gmail.com>
	<4F5A2F49.7030605@biblibre.com> <4F5D2DBA.3070004@catalyst.net.nz>
	<4F5DB5FD.1050605@biblibre.com> <4F5E74E0.6090801@catalyst.net.nz>
	<4F5F193C.4090909@biblibre.com>
	<CANL=k+GUrHrhhUkvY0gYovjAqX16tZf5FS4jC7QnTXnAZq90Fg@mail.gmail.com>
	<24D46D3B-F3D4-44C6-8952-7130C424F809@kohaaloha.com>
	<375EF97F-15E5-44F1-BF05-55937D7BCD9C@kohaaloha.com>
Message-ID: <CAP3yOok2HNbooh3tpyXhB9_3pqd9-6jwHO9=ApT3-xi7vDE=KQ@mail.gmail.com>

2012/3/14 Mason James <mtj at kohaaloha.com>

>
> On 2012-03-14, at 7:24 PM, Mason James wrote:
>
> > hi People
> >
> >
> > i believe there are 2 duplicated commits in the kc.org repo currently,
> that need to be corrected
> > (by deleting 1 commit?)
>

This has happened from time to time in the past in master. I seem to recall
it causing a problem with my local branch once, but I deleted and recreated
the branch and the problem disappeared.

Kind Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120314/643a94d3/attachment.htm>

From mtj at kohaaloha.com  Wed Mar 14 13:14:40 2012
From: mtj at kohaaloha.com (Mason James)
Date: Thu, 15 Mar 2012 01:14:40 +1300
Subject: [Koha-devel] 2 duplicated commits in the kc.org repo,
	on master branch ?
In-Reply-To: <CAP3yOok2HNbooh3tpyXhB9_3pqd9-6jwHO9=ApT3-xi7vDE=KQ@mail.gmail.com>
References: <4F59DE5C.8020004@biblibre.com>
	<CAJzKNY6qROBOWkS=Hr+iaPjWPq3RwnaonUFBojdEMvcgw+K-WQ@mail.gmail.com>
	<4F59F8A2.3050104@biblibre.com> <4F5A2498.5070106@biblibre.com>
	<CA+95qVRSxB7pWBgM-+bVhU6dBu0c4-PWn1t=PFSMxtxU9g1rKw@mail.gmail.com>
	<4F5A2F49.7030605@biblibre.com> <4F5D2DBA.3070004@catalyst.net.nz>
	<4F5DB5FD.1050605@biblibre.com> <4F5E74E0.6090801@catalyst.net.nz>
	<4F5F193C.4090909@biblibre.com>
	<CANL=k+GUrHrhhUkvY0gYovjAqX16tZf5FS4jC7QnTXnAZq90Fg@mail.gmail.com>
	<24D46D3B-F3D4-44C6-8952-7130C424F809@kohaaloha.com>
	<375EF97F-15E5-44F1-BF05-55937D7BCD9C@kohaaloha.com>
	<CAP3yOok2HNbooh3tpyXhB9_3pqd9-6jwHO9=ApT3-xi7vDE=KQ@mail.gmail.com>
Message-ID: <94C52C35-B7E7-4FEF-B5AE-34F87394ACA0@kohaaloha.com>


On 2012-03-15, at 12:54 AM, Chris Nighswonger wrote:

> 2012/3/14 Mason James <mtj at kohaaloha.com>
> 
> On 2012-03-14, at 7:24 PM, Mason James wrote:
> 
> > hi People
> >
> >
> > i believe there are 2 duplicated commits in the kc.org repo currently, that need to be corrected
> > (by deleting 1 commit?)
> 
> This has happened from time to time in the past in master. I seem to recall it causing a problem with my local branch once, but I deleted and recreated the branch and the problem disappeared.
> 
> Kind Regards,
> Chris


aaah, some good news... 
one (or three?) 'git reset --hard origin/master' later, my merge worked just fine... :)

so the duped commits are no longer a problem for me :)


paul.p, will you fix these commits in the kc.org repo?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20120315/db390cae/attachment.pgp>

From mtj at kohaaloha.com  Thu Mar 15 10:23:49 2012
From: mtj at kohaaloha.com (Mason James)
Date: Thu, 15 Mar 2012 22:23:49 +1300
Subject: [Koha-devel] 2 duplicated commits in the kc.org repo,
	on master branch ?
In-Reply-To: <94C52C35-B7E7-4FEF-B5AE-34F87394ACA0@kohaaloha.com>
References: <4F59DE5C.8020004@biblibre.com>
	<CAJzKNY6qROBOWkS=Hr+iaPjWPq3RwnaonUFBojdEMvcgw+K-WQ@mail.gmail.com>
	<4F59F8A2.3050104@biblibre.com> <4F5A2498.5070106@biblibre.com>
	<CA+95qVRSxB7pWBgM-+bVhU6dBu0c4-PWn1t=PFSMxtxU9g1rKw@mail.gmail.com>
	<4F5A2F49.7030605@biblibre.com> <4F5D2DBA.3070004@catalyst.net.nz>
	<4F5DB5FD.1050605@biblibre.com> <4F5E74E0.6090801@catalyst.net.nz>
	<4F5F193C.4090909@biblibre.com>
	<CANL=k+GUrHrhhUkvY0gYovjAqX16tZf5FS4jC7QnTXnAZq90Fg@mail.gmail.com>
	<24D46D3B-F3D4-44C6-8952-7130C424F809@kohaaloha.com>
	<375EF97F-15E5-44F1-BF05-55937D7BCD9C@kohaaloha.com>
	<CAP3yOok2HNbooh3tpyXhB9_3pqd9-6jwHO9=ApT3-xi7vDE=KQ@mail.gmail.com>
	<94C52C35-B7E7-4FEF-B5AE-34F87394ACA0@kohaaloha.com>
Message-ID: <24DBEFCC-BF2A-497B-9DB2-6947057F6CF7@kohaaloha.com>


On 2012-03-15, at 1:14 AM, Mason James wrote:

> 
> On 2012-03-15, at 12:54 AM, Chris Nighswonger wrote:
> 
>> 2012/3/14 Mason James <mtj at kohaaloha.com>
>> 
>> On 2012-03-14, at 7:24 PM, Mason James wrote:
>> 
>>> hi People
>>> 
>>> 
>>> i believe there are 2 duplicated commits in the kc.org repo currently, that need to be corrected
>>> (by deleting 1 commit?)
>> 
>> This has happened from time to time in the past in master. I seem to recall it causing a problem with my local branch once, but I deleted and recreated the branch and the problem disappeared.
>> 
>> Kind Regards,
>> Chris
> 
> 
> aaah, some good news... 
> one (or three?) 'git reset --hard origin/master' later, my merge worked just fine... :)
> 
> so the duped commits are no longer a problem for me :)
> 
> paul.p, will you fix these commits in the kc.org repo?
> 

actually, i take that back
i seem to be having more rebase problems with my local repo, that are resolved after deleting one of those duped commits...

so... its still a general problem, i think?

paul.p , please fix?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20120315/b8d396db/attachment.pgp>

From cnighswonger at foundations.edu  Thu Mar 15 13:53:46 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Thu, 15 Mar 2012 08:53:46 -0400
Subject: [Koha-devel] 2 duplicated commits in the kc.org repo,
 on master branch ?
In-Reply-To: <24DBEFCC-BF2A-497B-9DB2-6947057F6CF7@kohaaloha.com>
References: <4F59DE5C.8020004@biblibre.com>
	<CAJzKNY6qROBOWkS=Hr+iaPjWPq3RwnaonUFBojdEMvcgw+K-WQ@mail.gmail.com>
	<4F59F8A2.3050104@biblibre.com> <4F5A2498.5070106@biblibre.com>
	<CA+95qVRSxB7pWBgM-+bVhU6dBu0c4-PWn1t=PFSMxtxU9g1rKw@mail.gmail.com>
	<4F5A2F49.7030605@biblibre.com> <4F5D2DBA.3070004@catalyst.net.nz>
	<4F5DB5FD.1050605@biblibre.com> <4F5E74E0.6090801@catalyst.net.nz>
	<4F5F193C.4090909@biblibre.com>
	<CANL=k+GUrHrhhUkvY0gYovjAqX16tZf5FS4jC7QnTXnAZq90Fg@mail.gmail.com>
	<24D46D3B-F3D4-44C6-8952-7130C424F809@kohaaloha.com>
	<375EF97F-15E5-44F1-BF05-55937D7BCD9C@kohaaloha.com>
	<CAP3yOok2HNbooh3tpyXhB9_3pqd9-6jwHO9=ApT3-xi7vDE=KQ@mail.gmail.com>
	<94C52C35-B7E7-4FEF-B5AE-34F87394ACA0@kohaaloha.com>
	<24DBEFCC-BF2A-497B-9DB2-6947057F6CF7@kohaaloha.com>
Message-ID: <CAP3yOonH_dU5d0B0rfQzW-LzZOQmGsP_mDO1TvdaffcFo8wedA@mail.gmail.com>

2012/3/15 Mason James <mtj at kohaaloha.com>

>
>
> actually, i take that back
> i seem to be having more rebase problems with my local repo, that are
> resolved after deleting one of those duped commits...
>
> so... its still a general problem, i think?
>
> paul.p , please fix?
>
>
A fetch and rebase work fine here. As I mentioned previously, there are any
number of duplicate commits in the main repo at present. I think they occur
during merges. I'm not sure that Paul can "fix" it. I am sure that if it
was causing wide spread pain, we'd have heard quite a cry by now. :-)

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

From colin.campbell at ptfs-europe.com  Thu Mar 15 15:57:35 2012
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Thu, 15 Mar 2012 14:57:35 +0000
Subject: [Koha-devel] 2 duplicated commits in the kc.org repo,
 on master branch ?
In-Reply-To: <CAP3yOonH_dU5d0B0rfQzW-LzZOQmGsP_mDO1TvdaffcFo8wedA@mail.gmail.com>
References: <4F5DB5FD.1050605@biblibre.com> <4F5E74E0.6090801@catalyst.net.nz>
	<4F5F193C.4090909@biblibre.com>
	<CANL=k+GUrHrhhUkvY0gYovjAqX16tZf5FS4jC7QnTXnAZq90Fg@mail.gmail.com>
	<24D46D3B-F3D4-44C6-8952-7130C424F809@kohaaloha.com>
	<375EF97F-15E5-44F1-BF05-55937D7BCD9C@kohaaloha.com>
	<CAP3yOok2HNbooh3tpyXhB9_3pqd9-6jwHO9=ApT3-xi7vDE=KQ@mail.gmail.com>
	<94C52C35-B7E7-4FEF-B5AE-34F87394ACA0@kohaaloha.com>
	<24DBEFCC-BF2A-497B-9DB2-6947057F6CF7@kohaaloha.com>
	<CAP3yOonH_dU5d0B0rfQzW-LzZOQmGsP_mDO1TvdaffcFo8wedA@mail.gmail.com>
Message-ID: <20120315145735.GA31304@zazou.cscnet.co.uk>

On Thu, Mar 15, 2012 at 08:53:46AM -0400, Chris Nighswonger wrote:
> A fetch and rebase work fine here. As I mentioned previously, there are any
> number of duplicate commits in the main repo at present. I think they occur
> during merges. I'm not sure that Paul can "fix" it. I am sure that if it
> was causing wide spread pain, we'd have heard quite a cry by now. :-)
"Fixing" it will however cause pain for anyone trying to track that
branch. Rewriting history in published branches is always a cause for
grief. The duplicates occur when two branches with the same commit but
different histories are merged. Part of the commit is not just the
changes but what the parent commit is. Keeping topic branches small and
rebasing them  against master before merging into master allows the merges to be
fast-forwards and helps against generating effectively duplicate
commits.

Colin


-- 
Colin Campbell
Chief Software Engineer,
PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 800 756 6803 (phone)
+44 (0) 7759 633626  (mobile)
colin.campbell at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com

From kyle.m.hall at gmail.com  Thu Mar 15 18:08:08 2012
From: kyle.m.hall at gmail.com (Kyle Hall)
Date: Thu, 15 Mar 2012 13:08:08 -0400
Subject: [Koha-devel] Acquisitions, safe to modify a basket's booksellerid?
Message-ID: <CACpVHfwuuC2WYL0Vt_CcgL0Nite7ri2ySvkTr2Otn8L=tNuM+Q@mail.gmail.com>

Hello all,
  I have a librarian who would like to have the ability to modify a
basket's booksellerid in the Acquisitions module. They want to be able
to do this because they frequently have to change vendors after
beginning the initial ordering process. I don't feel I'm am very
knowledgeable about this module, and was hoping to get some opinions
on whether adding this feature would be safe, or would it cause
problems.

Thanks,
Kyle

From koha.sekjal at gmail.com  Thu Mar 15 18:20:32 2012
From: koha.sekjal at gmail.com (Ian Walls)
Date: Thu, 15 Mar 2012 13:20:32 -0400
Subject: [Koha-devel] Acquisitions,
	safe to modify a basket's booksellerid?
In-Reply-To: <CACpVHfwuuC2WYL0Vt_CcgL0Nite7ri2ySvkTr2Otn8L=tNuM+Q@mail.gmail.com>
References: <CACpVHfwuuC2WYL0Vt_CcgL0Nite7ri2ySvkTr2Otn8L=tNuM+Q@mail.gmail.com>
Message-ID: <CANL=k+F9qAdA0Xu27VGZYhcM-x-LtJVnz1hNHf_fDOAParWudQ@mail.gmail.com>

Kyle,


I can see several use cases where this could be a desirable change... which
is your partner looking for?

   1. The particular order was transferred from one vendor to an affiliate
   vendor through some partnership process or relationship
   2. The initial vendor was absorbed by another, existing (in Koha) vendor
   3. The initial vendor changed their name or was absorbed by a new (to
   Koha) vendor

The second two cases would be better handled by either merging or renaming
vendors; I think only in the first case would the order actually need to be
moved from one vendor to another.

Since the connection to the vendor lives at the basket level, not the
individual line item order level, you'd need to either create a new basket
with the new vendor, or move the entire basket, and then keep track of all
the pointers in the database.  It adds an additional level of complexity.

Perhaps someone from BibLibre could speak more to this, as they are the
original developers, and to the best of my knowledge, French libraries are
using Acquisitions most heavily so far.

Cheers,


-Ian
On Thu, Mar 15, 2012 at 13:08, Kyle Hall <kyle.m.hall at gmail.com> wrote:

> Hello all,
>  I have a librarian who would like to have the ability to modify a
> basket's booksellerid in the Acquisitions module. They want to be able
> to do this because they frequently have to change vendors after
> beginning the initial ordering process. I don't feel I'm am very
> knowledgeable about this module, and was hoping to get some opinions
> on whether adding this feature would be safe, or would it cause
> problems.
>
> Thanks,
> Kyle
> _______________________________________________
> 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/20120315/ca74676d/attachment.htm>

From cnighswonger at foundations.edu  Thu Mar 15 20:48:59 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Thu, 15 Mar 2012 15:48:59 -0400
Subject: [Koha-devel] Fwd: [Koha] rebooting git.koha-community.org and
	manual.bywatersolutions.com
In-Reply-To: <CACv9bVSV8PT2DE3cgZVUENBv4o7MQMSrQnUEHiQU8LHpCpPrnw@mail.gmail.com>
References: <CACv9bVSkUawN5THpUvboEX+So=Bz4kKGJ3dPBO3vTO=G6StMdA@mail.gmail.com>
	<CACv9bVSV8PT2DE3cgZVUENBv4o7MQMSrQnUEHiQU8LHpCpPrnw@mail.gmail.com>
Message-ID: <CAP3yOonxV-ZbMghn_6ih55G2oxcMD5hzQCVtfvf-Uuv=KR0tOw@mail.gmail.com>

Forwarding to the devel list also...


---------- Forwarded message ----------
From: Melia Meggs <melia at bywatersolutions.com>
Date: Thu, Mar 15, 2012 at 2:57 PM
Subject: [Koha] rebooting git.koha-community.org and
manual.bywatersolutions.com
To: koha at lists.katipo.co.nz


Hello Koha community,

We are undergoing some mandatory cloud maintenance and need to reboot a
couple of servers that are being used by the community, specifically
git.koha-community.org and manual.bywatersolutions.com.  We wanted to give
you advance notice that we will be rebooting these servers on Friday, March
16 at midnight EST, and we hope this doesn't cause you any inconvenience.

Thank you,

Melia
--
Melia Meggs
Chief Operations Officer
ByWater Solutions
bywatersolutions.com
_______________________________________________
Koha mailing list  http://koha-community.org
Koha at lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120315/60b06cd7/attachment.htm>

From melia at bywatersolutions.com  Thu Mar 15 19:55:46 2012
From: melia at bywatersolutions.com (Melia Meggs)
Date: Thu, 15 Mar 2012 11:55:46 -0700
Subject: [Koha-devel] rebooting git.koha-community.org and
	manual.bywatersolutions.com
Message-ID: <CACv9bVSkUawN5THpUvboEX+So=Bz4kKGJ3dPBO3vTO=G6StMdA@mail.gmail.com>

Hello Koha community,

We are undergoing some mandatory cloud maintenance and need to reboot a
couple of servers that are being used by the community, specifically
git.koha-community.org and manual.bywatersolutions.com.  We wanted to give
you advance notice that we will be rebooting these servers on Friday, March
16 at midnight EST, and we hope this doesn't cause you any inconvenience.

Thank you,

Melia
-- 
Melia Meggs
Chief Operations Officer
ByWater Solutions
bywatersolutions.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120315/fc3a3de3/attachment.htm>

From magnus at enger.priv.no  Fri Mar 16 10:47:19 2012
From: magnus at enger.priv.no (Magnus Enger)
Date: Fri, 16 Mar 2012 10:47:19 +0100
Subject: [Koha-devel] Next week is Global Bug Squashing Week!
Message-ID: <CABg6UYF2bc9aLXpsym_Z--Bs=vFugw7aV_wmFXNO3ji2f4DCKw@mail.gmail.com>

Dear Community,

The deadlines for getting stuff into version 3.8 are drawing near:
http://wiki.koha-community.org/wiki/Roadmap_to_3.8

As most of you are probably aware now, there will be a super cool
hackfest in Marseille next week:
http://drupal.biblibre.com/en/blog/entry/2012-hackfest-in-europe

For those of us who can't be there in person, it's still possible to
contribute to the fun, by joining the Global bug squashing week:
http://wiki.koha-community.org/wiki/2012-03-19_Global_bug_squashing_week

As far as I can tell, the beginning of this week will be the last
chance for having new features signed off with any hope of getting
them into 3.8. And there are bugfixes and minor improvements to look
after.

Not sure how you can help? Jump on the IRC channel (
http://koha-community.org/get-involved/irc/ ) and we will help you get
started! And with the sandboxes provided by BibLibre all you need in
order to join the fun is a web browser!

http://wiki.koha-community.org/wiki/2012-03-19_Global_bug_squashing_week

See you there!
Magnus Enger

From paul.poulain at biblibre.com  Fri Mar 16 11:11:47 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 16 Mar 2012 11:11:47 +0100
Subject: [Koha-devel] Next week is Global Bug Squashing Week!
In-Reply-To: <CABg6UYF2bc9aLXpsym_Z--Bs=vFugw7aV_wmFXNO3ji2f4DCKw@mail.gmail.com>
References: <CABg6UYF2bc9aLXpsym_Z--Bs=vFugw7aV_wmFXNO3ji2f4DCKw@mail.gmail.com>
Message-ID: <4F6311E3.50407@biblibre.com>

Le 16/03/2012 10:47, Magnus Enger a ?crit :
> As most of you are probably aware now, there will be a super cool
> hackfest in Marseille next week:
> http://drupal.biblibre.com/en/blog/entry/2012-hackfest-in-europe
Just to let everybody know: we will be 35 during this hackfest !!!

19 from BibLibre (including our 4 librarians), 12 librarians (including
the BibLibre 4), and ppl from Croatia, Spain, Italy, Germany,
Switzerland and US (have a nice trip all of you !)

BibLibre office will be a little bit too small, so we've booked an
additional room just the door in front of our office (thx to the NPO
that make it possible !)

We will split in 5 different groups :
* one (with most librarians) will work on signing-off, document,
translating (to french), bug squash,...
* one (with at least Owen, Katrin, Ga?tan, Julian & Adrien) will work on
interface & ergonomy things.
* one (with at least Claire, Jonathan, Zeno, Juan) working on solr stuff
-that won't be submitted for 3.8, definetly, but we hope to have a
detailled roadmap & some started work
* one (with at least hdl, dobrika & matthias) will work on persistency
* one (with at least marc & some other BibLibre ppl) will work on
database, trying to drop as many mySQL dependancies as possible, fix DB
mistakes,...

We will have a lot of fun, no doubt, and you're unlucky if you don't come :D
-- 
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  Fri Mar 16 18:18:52 2012
From: danielg.koha at gmail.com (Daniel Grobani)
Date: Fri, 16 Mar 2012 10:18:52 -0700
Subject: [Koha-devel] Call for News for the March Newsletter
Message-ID: <CAOeKewheNSKYV4Btt+RPqykq66s00MATeKrworDNh0Z3EmahHg@mail.gmail.com>

Dear Koha Kommunitarians,

I'm harvesting news for the March newsletter. Please send me by the
25th anything you think your fellow community members 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.

Thanks,
Daniel Grobani

From jcamins at cpbibliography.com  Sat Mar 17 12:53:21 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Sat, 17 Mar 2012 07:53:21 -0400
Subject: [Koha-devel] Bugzilla problem and a plea
Message-ID: <CALVDfQxYMjvbwHcxWWQxTKeo0mJiFU2uV5j+AUCoOpuNf-nBAw@mail.gmail.com>

Good morning.

Those of you subscribed to koha-bugs may notice something surprising in
your inbox today- a message that seems to indicate that a number of bugs
that still exist (such as bug 6875) have been resolved. When, in shock, you
go to look at the bug report and find out how this could be, you will see
that the status remains unchanged. There seems to be an issue with
dependencies in Bugzilla where the part of the message that says "This bug
depends on another bug, bug XXXX which changed state to..." is missing.
Just a heads-up on that, because it's a little disconcerting to see
"RESOLVED--FIXED" in an e-mail about a bug that you *know* isn't resolved.

That was the problem. My plea is this: if you see any bug reports (such as
reports that you filed yourself) that have a status of Pushed to Stable or
Pushed to Master (depending which is the final destination for the patch),
please test the bug, and, if it's fixed, mark it resolved. We have more
than 500 bugs with a pushed status, and most of the are probably no longer
issues. It would be nice to tidy up Bugzilla a bit and get the bugs that
are resolved off the "open bugs" list.

Regards,
Jared

-- 
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/20120317/5dc1b92b/attachment.htm>

From wrobertson1981 at yahoo.co.nz  Sun Mar 18 04:52:27 2012
From: wrobertson1981 at yahoo.co.nz (Waylon Robertson)
Date: Sat, 17 Mar 2012 20:52:27 -0700 (PDT)
Subject: [Koha-devel] [Koha] Next week is Global Bug Squashing Week!
In-Reply-To: <CABg6UYF2bc9aLXpsym_Z--Bs=vFugw7aV_wmFXNO3ji2f4DCKw@mail.gmail.com>
References: <CABg6UYF2bc9aLXpsym_Z--Bs=vFugw7aV_wmFXNO3ji2f4DCKw@mail.gmail.com>
Message-ID: <1332042747.80965.YahooMailNeo@web39402.mail.mud.yahoo.com>

is there a full koha anonymized test database available to squash bugs against?


________________________________
 From: Magnus Enger <magnus at enger.priv.no>
To: Koha list <koha at lists.katipo.co.nz>; koha-devel at lists.koha-community.org 
Sent: Friday, 16 March 2012 10:47 PM
Subject: [Koha] Next week is Global Bug Squashing Week!
 
Dear Community,

The deadlines for getting stuff into version 3.8 are drawing near:
http://wiki.koha-community.org/wiki/Roadmap_to_3.8

As most of you are probably aware now, there will be a super cool
hackfest in Marseille next week:
http://drupal.biblibre.com/en/blog/entry/2012-hackfest-in-europe

For those of us who can't be there in person, it's still possible to
contribute to the fun, by joining the Global bug squashing week:
http://wiki.koha-community.org/wiki/2012-03-19_Global_bug_squashing_week

As far as I can tell, the beginning of this week will be the last
chance for having new features signed off with any hope of getting
them into 3.8. And there are bugfixes and minor improvements to look
after.

Not sure how you can help? Jump on the IRC channel (
http://koha-community.org/get-involved/irc/ ) and we will help you get
started! And with the sandboxes provided by BibLibre all you need in
order to join the fun is a web browser!

http://wiki.koha-community.org/wiki/2012-03-19_Global_bug_squashing_week

See you there!
Magnus Enger
_______________________________________________
Koha mailing list? http://koha-community.org
Koha at lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120317/de323667/attachment.htm>

From mtj at kohaaloha.com  Mon Mar 19 07:50:31 2012
From: mtj at kohaaloha.com (Mason James)
Date: Mon, 19 Mar 2012 19:50:31 +1300
Subject: [Koha-devel] 2 duplicated commits in the kc.org repo,
	on master branch ?
In-Reply-To: <20120315145735.GA31304@zazou.cscnet.co.uk>
References: <4F5DB5FD.1050605@biblibre.com> <4F5E74E0.6090801@catalyst.net.nz>
	<4F5F193C.4090909@biblibre.com>
	<CANL=k+GUrHrhhUkvY0gYovjAqX16tZf5FS4jC7QnTXnAZq90Fg@mail.gmail.com>
	<24D46D3B-F3D4-44C6-8952-7130C424F809@kohaaloha.com>
	<375EF97F-15E5-44F1-BF05-55937D7BCD9C@kohaaloha.com>
	<CAP3yOok2HNbooh3tpyXhB9_3pqd9-6jwHO9=ApT3-xi7vDE=KQ@mail.gmail.com>
	<94C52C35-B7E7-4FEF-B5AE-34F87394ACA0@kohaaloha.com>
	<24DBEFCC-BF2A-497B-9DB2-6947057F6CF7@kohaaloha.com>
	<CAP3yOonH_dU5d0B0rfQzW-LzZOQmGsP_mDO1TvdaffcFo8wedA@mail.gmail.com>
	<20120315145735.GA31304@zazou.cscnet.co.uk>
Message-ID: <611F7A3A-5DC6-44CD-8CD3-7D6926F0E5C6@kohaaloha.com>


On 2012-03-16, at 3:57 AM, Colin Campbell wrote:

> On Thu, Mar 15, 2012 at 08:53:46AM -0400, Chris Nighswonger wrote:
>> A fetch and rebase work fine here. As I mentioned previously, there are any
>> number of duplicate commits in the main repo at present. I think they occur
>> during merges. I'm not sure that Paul can "fix" it. I am sure that if it
>> was causing wide spread pain, we'd have heard quite a cry by now. :-)
> "Fixing" it will however cause pain for anyone trying to track that
> branch. Rewriting history in published branches is always a cause for
> grief. The duplicates occur when two branches with the same commit but
> different histories are merged. Part of the commit is not just the
> changes but what the parent commit is.

yep, and its right there that i'm confused :)

both of these duplicated sequential commits have the *same* parent commit (aed0d8a63d5005e1c343def9a8ccbd9403ccd4aa)
thats a little bit odd?

http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=50585c34292b7aabfaabeba0db3f83612f55837e
http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=da920b1da9f2f2895730758659d099245c2e64ba


anyhoo, if the dupe commits aren't causing anyone else git-merge problems... i'm happy to let it go ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20120319/3c01adda/attachment.pgp>

From tajoli at cilea.it  Mon Mar 19 11:56:02 2012
From: tajoli at cilea.it (tajoli at cilea.it)
Date: Mon, 19 Mar 2012 11:56:02 +0100 (CET)
Subject: [Koha-devel] Bug 7430 and NoZebra
In-Reply-To: <dc97d511-779b-4c50-b1ba-cb933c30e379@esx-revenge>
Message-ID: <5b7d4140-bfd2-453f-9472-4f46b64b462f@esx-revenge>

Hi to all,

here at HackFest I'm working on bug 7430, to
commit it into master and so for 3.8.0

This patch was written from Jared Camins-Esakov

This patch entirely removes portions of the NoZebra code.

As I know now 'NoZebra' mode is not working now in 3.6.x

We need to write in documentation and setup that for 3.8 the only Serch Engine for
Koha is Zebra.

Cheers
Zeno Tajoli

From paul.poulain at biblibre.com  Tue Mar 20 18:37:30 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 20 Mar 2012 18:37:30 +0100
Subject: [Koha-devel] 4 patches i'll push tomorrow...
Message-ID: <4F68C05A.3070905@biblibre.com>

Hello koha-devel,

There are a few patches that are waiting for too long in my "passed QA"
list:
* 7144 	Floating collection
* 7092 	Complete-subfield searches TraceCompleteSubfields syspref not
working correctly
* 7310 	Improving permissions on lists (virtual shelves)
* 6831 	Enhanced Workflow for adding analytical records

For those 4 patches, I couldn't test them successfully:
* I took time trying to test them
* I could not made the feature work (for 7144/7092/6831), maybe it's
because of something i'm doing wrong or I can't reproduce correctly or
my database doesn't have a needed configuration (MARC21 ?)

I think it's unfair to block those patches because *I* can't test them
properly. Other ppl have signed them off already, all of them have been
examined in details.
What annoys me is also that the feature freeze is close, so I want to
push as many things as possible before.

SO = i'll push them tomorrow, asking for more tests after pushing !

Note = don't think i'll do that frequently ;-)
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From mtj at kohaaloha.com  Wed Mar 21 06:45:28 2012
From: mtj at kohaaloha.com (Mason James)
Date: Wed, 21 Mar 2012 18:45:28 +1300
Subject: [Koha-devel] is there a full koha anonymized test database
	available to squash bugs against?
In-Reply-To: <1332042747.80965.YahooMailNeo@web39402.mail.mud.yahoo.com>
References: <CABg6UYF2bc9aLXpsym_Z--Bs=vFugw7aV_wmFXNO3ji2f4DCKw@mail.gmail.com>
	<1332042747.80965.YahooMailNeo@web39402.mail.mud.yahoo.com>
Message-ID: <03179EB6-31F0-4453-9940-9377D8B2D3DB@kohaaloha.com>


On 2012-03-18, at 4:52 PM, Waylon Robertson wrote:

> is there a full koha anonymized test database available to squash bugs against?


as far as i know... no

does anyone else know better?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20120321/16b10ad1/attachment.pgp>

From bob at calyx.net.au  Wed Mar 21 08:01:44 2012
From: bob at calyx.net.au (Bob Birchall)
Date: Wed, 21 Mar 2012 18:01:44 +1100
Subject: [Koha-devel] is there a full koha anonymized test database
 available to squash bugs against?
In-Reply-To: <03179EB6-31F0-4453-9940-9377D8B2D3DB@kohaaloha.com>
References: <CABg6UYF2bc9aLXpsym_Z--Bs=vFugw7aV_wmFXNO3ji2f4DCKw@mail.gmail.com>	<1332042747.80965.YahooMailNeo@web39402.mail.mud.yahoo.com>
	<03179EB6-31F0-4453-9940-9377D8B2D3DB@kohaaloha.com>
Message-ID: <4F697CD8.60905@calyx.net.au>

On 21/03/12 16:45, Mason James wrote:
> On 2012-03-18, at 4:52 PM, Waylon Robertson wrote:
>
>> is there a full koha anonymized test database available to squash bugs against?
>
> as far as i know... no
>
> does anyone else know better?
>
Well, aren't the Biblibre sandboxes meant for that purpose?
http://wiki.koha-community.org/wiki/Sandboxes

The Calyx demo (demo.calyx.net.au) has only a small data base, but we 
could make it available if really needed.  Perhaps other companies demo 
DBs are larger?  But try the Biblibre ones first.

Hope that helps,
Bob


From fridolyn.somers at gmail.com  Wed Mar 21 13:35:31 2012
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Wed, 21 Mar 2012 13:35:31 +0100
Subject: [Koha-devel] Call for News for the March Newsletter
In-Reply-To: <CAOeKewheNSKYV4Btt+RPqykq66s00MATeKrworDNh0Z3EmahHg@mail.gmail.com>
References: <CAOeKewheNSKYV4Btt+RPqykq66s00MATeKrworDNh0Z3EmahHg@mail.gmail.com>
Message-ID: <CAN6cLAWs3Mm7NGJiBt-vfPOPpCZ+aSJPFrGs_=WNYHx9-DrzqQ@mail.gmail.com>

Hie,

I just found this article about GIT over HTTP :
http://progit.org/2010/03/04/smart-http.html
ProGit also provides a very good learning (e)book.

Best regards,

On Fri, Mar 16, 2012 at 6:18 PM, Daniel Grobani <danielg.koha at gmail.com>wrote:

> Dear Koha Kommunitarians,
>
> I'm harvesting news for the March newsletter. Please send me by the
> 25th anything you think your fellow community members 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.
>
> Thanks,
> Daniel Grobani
> _______________________________________________
> 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/
>



-- 
Fridolyn SOMERS
fridolyn.somers at gmail.com
Marsillargues - France
 <fridolyn.somers at gmail.com>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20120321/2bcb6c52/attachment.htm>

From lrea at nekls.org  Wed Mar 21 14:22:18 2012
From: lrea at nekls.org (Liz Rea)
Date: Wed, 21 Mar 2012 08:22:18 -0500
Subject: [Koha-devel] is there a full koha anonymized test database
	available to squash bugs against?
In-Reply-To: <03179EB6-31F0-4453-9940-9377D8B2D3DB@kohaaloha.com>
References: <CABg6UYF2bc9aLXpsym_Z--Bs=vFugw7aV_wmFXNO3ji2f4DCKw@mail.gmail.com>
	<1332042747.80965.YahooMailNeo@web39402.mail.mud.yahoo.com>
	<03179EB6-31F0-4453-9940-9377D8B2D3DB@kohaaloha.com>
Message-ID: <B164D238-7016-429A-8353-469793909941@nekls.org>

I have one that is a combo of sample data and MARC21 data - you can get it at https://github.com/wizzyrea/Scripts-and-Things/blob/master/kohadev-withbibs.sql.gz
(do note, it's possible the rules in there are not quite sane or not defined in a way that makes sense. Step through the administration when you get it imported.)

And just the marc data: https://github.com/wizzyrea/Scripts-and-Things/blob/master/MARC21.mrc

I've got an ongoing project to make a collection of sample data, and rule sets that developers can choose and import at install time, but they are not ready quite yet. :)

Liz Rea
lrea at nekls.org



On Mar 21, 2012, at 12:45 AM, Mason James wrote:

> 
> On 2012-03-18, at 4:52 PM, Waylon Robertson wrote:
> 
>> is there a full koha anonymized test database available to squash bugs against?
> 
> 
> as far as i know... no
> 
> does anyone else know better?
> 
> 
> _______________________________________________
> 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/20120321/47cdefad/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/20120321/47cdefad/attachment.jpeg>

From M.de.Rooy at rijksmuseum.nl  Thu Mar 22 09:57:16 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 22 Mar 2012 08:57:16 +0000
Subject: [Koha-devel] Translation question
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3109576242@S-MAIL-1B.rijksmuseum.intra>

Hi all,



Sorry for cross-posting ;) Something in between..



Does anyone of you foresee problems with translating a construction like this one just as in the sysprefs?



Allow/Do not allow (in combo)  -- followed by text like: -- anyone to delete items from the list

See screenshot:



http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8467





Thanks for your attention.



Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120322/5a86b97a/attachment.htm>

From samuel.desseaux at ecp.fr  Thu Mar 22 11:23:27 2012
From: samuel.desseaux at ecp.fr (Samuel desseaux)
Date: Thu, 22 Mar 2012 11:23:27 +0100
Subject: [Koha-devel] koha / installation
Message-ID: <4F6AFD9F.1000805@ecp.fr>

Hi,

My question is very short and easy: what sort of installation of koha 
could you advice? By git or by the tarball?
I work on a migration of our ILS for koha.

Best regards

samuel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: samuel_desseaux.vcf
Type: text/x-vcard
Size: 329 bytes
Desc: not available
URL: </pipermail/koha-devel/attachments/20120322/7b8f1e8f/attachment.vcf>

From paul.poulain at biblibre.com  Thu Mar 22 11:47:15 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 22 Mar 2012 11:47:15 +0100
Subject: [Koha-devel] koha / installation
In-Reply-To: <4F6AFD9F.1000805@ecp.fr>
References: <4F6AFD9F.1000805@ecp.fr>
Message-ID: <4F6B0333.3070405@biblibre.com>

Le 22/03/2012 11:23, Samuel desseaux a ?crit :
> Hi,
> 
> My question is very short and easy: what sort of installation of koha
> could you advice? By git or by the tarball?
> I work on a migration of our ILS for koha.
Hi Samuel,

it really depends on you... when you know git, it's really wonderful to
upgrade, apply patches,...
if you strictly just want released version, then the tarball is a good
option.

for me: I love git (don't tell my wife), so I'm biased ;-)
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From shakazu00 at gmail.com  Thu Mar 22 14:27:51 2012
From: shakazu00 at gmail.com (ZUULU COOPER)
Date: Thu, 22 Mar 2012 09:27:51 -0400
Subject: [Koha-devel] Koha patron import
Message-ID: <CAGquDEHjrW7N7CnR29_qSnXH66cwMan8a_wfocrqbOwt2mM-5A@mail.gmail.com>

Can anyone send me a copy a patron import file for me to try. I have run
out of options. I recently installed Koha 3.06.04 Live DVD and I am getting
errors the surname, borrowernumber, branchcode and categorycode. I do not
know what I am doing wrong. I installed the Koha GSDL and I get the same
error. I enter the some of sample data from the GSDL version into the LIVE
DVD and I still get the same error.

-- 
Zuulu Cooper
Founder & Executive Director
Libraries for Liberia Foundation
 5919 Dakar Road West
Suite 100
Westerville, OH 43081
 614 270 3464
Skype: Shaka_zu00

 website : http://librariesforliberiafoundation.com  email:
info at librariesforliberiafoundation.com


 *?Cause change and lead, accept change and survive, resist change and die.?
*

Ray Noorda - 1924-2006, technology pioneer, Novell Corporation CEO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120322/bd6d4c00/attachment.htm>

From paul.poulain at biblibre.com  Thu Mar 22 17:16:38 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 22 Mar 2012 17:16:38 +0100
Subject: [Koha-devel] For those running master
Message-ID: <4F6B5066.2020100@biblibre.com>

Hello koha-devel,

if any of you is running master, I pushed a large patch with a DB
revision mistake yesterday.
The 3.07.00.032 DBrev won't apply correctly.

If you've already updated and have applied this DBrev, I suggest you run
the following SQL commands:
ALTER TABLE virtualshelves MODIFY COLUMN owner int;
UPDATE virtualshelves vi LEFT JOIN borrowers bo ON
bo.borrowernumber=vi.owner SET vi.owner=NULL where bo.borrowernumber IS
NULL;
DELETE FROM virtualshelves WHERE owner IS NULL and category=1;
ALTER TABLE virtualshelves ADD COLUMN allow_add tinyint(1) DEFAULT 0,
ADD COLUMN allow_delete_own tinyint(1) DEFAULT 1, ADD COLUMN
allow_delete_other tinyint(1) DEFAULT 0, ADD CONSTRAINT
`virtualshelves_ibfk_1` FOREIGN KEY (`owner`) REFERENCES `borrowers`
(`borrowernumber`) ON DELETE SET NULL ON UPDATE SET NULL;
UPDATE virtualshelves SET allow_add=0, allow_delete_own=1,
allow_delete_other=0 WHERE category=1;
UPDATE virtualshelves SET allow_add=0, allow_delete_own=1,
allow_delete_other=0 WHERE category=2;
UPDATE virtualshelves SET allow_add=1, allow_delete_own=1,
allow_delete_other=1 WHERE category=3;
UPDATE virtualshelves SET category=2 WHERE category=3;

ALTER TABLE virtualshelfcontents ADD COLUMN borrowernumber int, ADD
CONSTRAINT `shelfcontents_ibfk_3` FOREIGN KEY (`borrowernumber`)
REFERENCES `borrowers` (`borrowernumber`) ON DELETE SET NULL ON UPDATE
SET NULL;
UPDATE virtualshelfcontents co LEFT JOIN virtualshelves sh USING
(shelfnumber) SET co.borrowernumber=sh.owner;

CREATE TABLE virtualshelfshares
    (id int AUTO_INCREMENT PRIMARY KEY, shelfnumber int NOT NULL,
    borrowernumber int, invitekey varchar(10), sharedate datetime,
    CONSTRAINT `virtualshelfshares_ibfk_1` FOREIGN KEY (`shelfnumber`)
REFERENCES `virtualshelves` (`shelfnumber`) ON DELETE CASCADE ON UPDATE
CASCADE,
        CONSTRAINT `virtualshelfshares_ibfk_2` FOREIGN KEY
(`borrowernumber`) REFERENCES `borrowers` (`borrowernumber`) ON DELETE
SET NULL ON UPDATE SET NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO systempreferences (variable,value,explanation,options,type)
VALUES('OpacAllowPublicListCreation',1,'If set, allows opac users to
create public lists',NULL,'YesNo');
INSERT INTO systempreferences (variable,value,explanation,options,type)
VALUES('OpacAllowSharingPrivateLists',0,'If set, allows opac users to
share private lists with other patrons',NULL,'YesNo');

If you haven't updated between yesterday and now, you have nothing to
do, i've pushed a fix that will make your update work smoothly

-- 
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 Mar 22 17:20:42 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 22 Mar 2012 17:20:42 +0100
Subject: [Koha-devel] For those running master
In-Reply-To: <4F6B5066.2020100@biblibre.com>
References: <4F6B5066.2020100@biblibre.com>
Message-ID: <4F6B515A.1050000@biblibre.com>

Le 22/03/2012 17:16, Paul Poulain a ?crit :
> Hello koha-devel,
> 
> if any of you is running master, I pushed a large patch with a DB
> revision mistake yesterday.
I should have specified = it's patch 7310 (virtual shelves improvements)

-- 
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 Mar 22 17:42:59 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 22 Mar 2012 17:42:59 +0100
Subject: [Koha-devel] Hourly loans -bug 5549- pushed, please test
Message-ID: <4F6B5693.4090601@biblibre.com>

Hello,

I just pushed a large patch that is related to hourly loans. It has been
tested by a lot of ppl (including at the hackfest), but it's worth more
tests, so feel free to update your git repositories and report the
result of your tests here !
-- 
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  Thu Mar 22 18:18:11 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Thu, 22 Mar 2012 13:18:11 -0400
Subject: [Koha-devel] Branch Specific System Preferences
Message-ID: <CAP3yOo=4AExz8jw-=M+V5OYsjyQbeuUy6c+T83c2h6DQA-eNsA@mail.gmail.com>

Recently the need has arisen locally to run the self-checkout (sco) under
multiple user accounts to accommodate multiple branches using the sco
module. To the best of my understanding this is not currently possible due
to the way in which the user for the sco module is defined using a system
preference. While there may be a number of ways to accomplish this, it
seems that it may be desirable to have a category of "branch specific"
system preferences. This would be an attempt to group system preferences
into one of two general categories of "global" or "branch." Before
launching out into writing such a feature, I thought I'd run it by both
lists to see if a) I'm way off base, b) if such a feature is desirable, and
c) if I'm off on an insanely hard project.

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

From koha.sekjal at gmail.com  Thu Mar 22 18:25:58 2012
From: koha.sekjal at gmail.com (Ian Walls)
Date: Thu, 22 Mar 2012 13:25:58 -0400
Subject: [Koha-devel] Branch Specific System Preferences
In-Reply-To: <CAP3yOo=4AExz8jw-=M+V5OYsjyQbeuUy6c+T83c2h6DQA-eNsA@mail.gmail.com>
References: <CAP3yOo=4AExz8jw-=M+V5OYsjyQbeuUy6c+T83c2h6DQA-eNsA@mail.gmail.com>
Message-ID: <CANL=k+G2Qwqj6zuTHmhgZT7sM_ZFOewSJErxGnE1Hq7xwgJtJA@mail.gmail.com>

Chris,


I've been meaning to write a Contextual Preferences Engine for Koha for a
while now, to solve the problems we have with the Circ Matrix, as well as
with global sysprefs that should really be more configurable.

The idea is that it will be a DB table with 5 main columns:  Branch, Patron
Category, Item Type, Key and Value.  Any of the first 3 can be a specific
value or "default".  If a contextual preference doesn't make sense to
factor in one of the 3 values, it'll be ignored.

This, along with a rewritten editor and rules tester tool, would solve a
bunch of our customizability problems in one go, without necessarily
introducing too much complexity for users (provided we make a good
interface).

I hope to have a patch for this started after 3.8 releases (and all our DB
revs are stable for a while).  Any help would be welcomed.


-Ian

2012/3/22 Chris Nighswonger <cnighswonger at foundations.edu>

> Recently the need has arisen locally to run the self-checkout (sco) under
> multiple user accounts to accommodate multiple branches using the sco
> module. To the best of my understanding this is not currently possible due
> to the way in which the user for the sco module is defined using a system
> preference. While there may be a number of ways to accomplish this, it
> seems that it may be desirable to have a category of "branch specific"
> system preferences. This would be an attempt to group system preferences
> into one of two general categories of "global" or "branch." Before
> launching out into writing such a feature, I thought I'd run it by both
> lists to see if a) I'm way off base, b) if such a feature is desirable, and
> c) if I'm off on an insanely hard project.
>
> Kind Regards,
> Chris
>
> _______________________________________________
> 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/20120322/635c666f/attachment.htm>

From paul.poulain at biblibre.com  Thu Mar 22 18:39:43 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 22 Mar 2012 18:39:43 +0100
Subject: [Koha-devel] [Koha] Branch Specific System Preferences
In-Reply-To: <CAP3yOo=4AExz8jw-=M+V5OYsjyQbeuUy6c+T83c2h6DQA-eNsA@mail.gmail.com>
References: <CAP3yOo=4AExz8jw-=M+V5OYsjyQbeuUy6c+T83c2h6DQA-eNsA@mail.gmail.com>
Message-ID: <4F6B63DF.1070403@biblibre.com>

Le 22/03/2012 18:18, Chris Nighswonger a ?crit :
> Recently the need has arisen locally to run the self-checkout (sco) under
> multiple user accounts to accommodate multiple branches using the sco
> module.

Hi chris,

I had the idea of just adding a "branchcode" column to the
systempreferences and let the library define systempreferences for ""
(default behaviour) or "specified branch"

In C4->context(preference)->{anysyspref}, we could just do:

SELECT * FROM systempreference WHERE variable="anysyspref" AND
branchcode=<userbranchcode>;
if no result
SELECT * FROM systempreference WHERE variable="anysyspref" AND
branchcode="";

Thus, any syspref could be not systemwide, but librarywide.

That could be very nice to have, for example, the default library
network logo if you're not logged in in OPAC, then your own library logo
once you're logged in.
Or css, or any syspref.

For a few sysprefs that would be totally irrelevant to have "local"
sysprefs (like MARC flavour or IndependantBRanches), but that's so
obvious that I don't think we even should care in the code, just warn in
the doc.

-- 
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  Thu Mar 22 18:44:21 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Thu, 22 Mar 2012 13:44:21 -0400
Subject: [Koha-devel] Branch Specific System Preferences
In-Reply-To: <CANL=k+G2Qwqj6zuTHmhgZT7sM_ZFOewSJErxGnE1Hq7xwgJtJA@mail.gmail.com>
References: <CAP3yOo=4AExz8jw-=M+V5OYsjyQbeuUy6c+T83c2h6DQA-eNsA@mail.gmail.com>
	<CANL=k+G2Qwqj6zuTHmhgZT7sM_ZFOewSJErxGnE1Hq7xwgJtJA@mail.gmail.com>
Message-ID: <CAP3yOom5jNXoxhR7Hyik_=G8ine=uiWbF4tB7BhONeNWS6FtgQ@mail.gmail.com>

Hi Ian,

On Thu, Mar 22, 2012 at 1:25 PM, Ian Walls <koha.sekjal at gmail.com> wrote:

> Chris,
>
>
> I've been meaning to write a Contextual Preferences Engine for Koha for a
> while now, to solve the problems we have with the Circ Matrix, as well as
> with global sysprefs that should really be more configurable.
>
> The idea is that it will be a DB table with 5 main columns:  Branch,
> Patron Category, Item Type, Key and Value.  Any of the first 3 can be a
> specific value or "default".  If a contextual preference doesn't make sense
> to factor in one of the 3 values, it'll be ignored.
>
>
Is the goal is to allow any or a defined set of system preferences to be
"contextualized" based on branch, patron category, and/or item type?


> This, along with a rewritten editor and rules tester tool, would solve a
> bunch of our customizability problems in one go, without necessarily
> introducing too much complexity for users (provided we make a good
> interface).
>
>
Agreed.


> I hope to have a patch for this started after 3.8 releases (and all our DB
> revs are stable for a while).  Any help would be welcomed.
>

Sounds good. I need this functionality to be in place by August of this
year, so I'm very interested in getting started as soon as possible. I will
be carving out time during my workday for it over the next several months.

Kind Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120322/a5f7e350/attachment-0001.htm>

From cnighswonger at foundations.edu  Thu Mar 22 18:46:15 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Thu, 22 Mar 2012 13:46:15 -0400
Subject: [Koha-devel] [Koha] Branch Specific System Preferences
In-Reply-To: <4F6B63DF.1070403@biblibre.com>
References: <CAP3yOo=4AExz8jw-=M+V5OYsjyQbeuUy6c+T83c2h6DQA-eNsA@mail.gmail.com>
	<4F6B63DF.1070403@biblibre.com>
Message-ID: <CAP3yOonzaAViAWxPr4itq-Cf2K48sc5=0Y=0Ggr7AWmXHe5WQw@mail.gmail.com>

On Thu, Mar 22, 2012 at 1:39 PM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Le 22/03/2012 18:18, Chris Nighswonger a ?crit :
> > Recently the need has arisen locally to run the self-checkout (sco) under
> > multiple user accounts to accommodate multiple branches using the sco
> > module.
>
> Hi chris,
>
> I had the idea of just adding a "branchcode" column to the
> systempreferences and let the library define systempreferences for ""
> (default behaviour) or "specified branch"
>
>
I like the "KISS" approach, although I'm interested to hear a Ian's
response to this thought.

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

From koha.sekjal at gmail.com  Thu Mar 22 20:46:18 2012
From: koha.sekjal at gmail.com (Ian Walls)
Date: Thu, 22 Mar 2012 15:46:18 -0400
Subject: [Koha-devel] Branch Specific System Preferences
In-Reply-To: <CAP3yOom5jNXoxhR7Hyik_=G8ine=uiWbF4tB7BhONeNWS6FtgQ@mail.gmail.com>
References: <CAP3yOo=4AExz8jw-=M+V5OYsjyQbeuUy6c+T83c2h6DQA-eNsA@mail.gmail.com>
	<CANL=k+G2Qwqj6zuTHmhgZT7sM_ZFOewSJErxGnE1Hq7xwgJtJA@mail.gmail.com>
	<CAP3yOom5jNXoxhR7Hyik_=G8ine=uiWbF4tB7BhONeNWS6FtgQ@mail.gmail.com>
Message-ID: <CANL=k+F5WAyEVWwLSZs=hQLvo9ubebBEWijE1p2i+EhAW06Dcw@mail.gmail.com>

Chris,


I'm seeing the Contextual Preferences Engine (CPE) as a replacement to the
issuingrules and related tables, first and foremost.  It would be put in
place, then be migrated into slowly over time by developers, since
switching the subroutine calls from issuingrules and sysprefs to the CPE
would be a good level change in a lot of different places.  Users would not
be able to contextualize a syspref on their own from the staff client; it
would need to be a separate enhancement.  The CPE just provides a unified
platform for the developers to work with, making adding new
context-sensitive behaviours easier to code.

One major bonus is that each rule is granular and independent of other
rules.  Instead of having to maintain a huge circ matrix of rules and
exceptions and exceptions to exceptions, you define you base case, then the
few things that are different can be made different.  The tester page will
let you quickly confirm which rules you'll be getting in any given
situation, so if there is any unexpected behaviour, you can trace it out.

Rough implementation plan:

Create new table in DB
Create interface to manipulate values in table (get basics of templates and
subroutines in place)
Create interface to test which rules are applied to any given combo of
Branch, Patron and Itemtype

--- Up to here can be done behind the scenes without changing any other
part of Koha ---

Migrate over issuing rules
Spruce up interface now that there is data
Begin changing Circ subroutines to use CPE instead of smart rules
Migrate over some sysprefs that need further contextualization (see bug for
some that have been identified)

--- much later ---

Drop the smart rules pages and database tables once the migration is
complete and stable.



The first section could be completed by June very easily; that'd give us
the CPE framework to work in, and it'd just be a matter of changing system
calls to use it instead of whatever they're currently using.  If that code
is committed to master, then your need for per-branch SCO settings could be
handled quickly before August.  It would still need to wait until the next
release in October before it's part of stable, but so would any kind of
change like this.

I hope this makes sense.  As I said, any assistance, either in design,
implementation or both, is welcome.   I've been meaning to do this for a
long while, but other things (like testing Hourly Loans) have taken
priority recently.  I'd love to have this in place for 3.10, to some degree
or another.

Cheers,


-Ian

On Thu, Mar 22, 2012 at 13:44, Chris Nighswonger <
cnighswonger at foundations.edu> wrote:

> Hi Ian,
>
> On Thu, Mar 22, 2012 at 1:25 PM, Ian Walls <koha.sekjal at gmail.com> wrote:
>
>> Chris,
>>
>>
>> I've been meaning to write a Contextual Preferences Engine for Koha for a
>> while now, to solve the problems we have with the Circ Matrix, as well as
>> with global sysprefs that should really be more configurable.
>>
>> The idea is that it will be a DB table with 5 main columns:  Branch,
>> Patron Category, Item Type, Key and Value.  Any of the first 3 can be a
>> specific value or "default".  If a contextual preference doesn't make sense
>> to factor in one of the 3 values, it'll be ignored.
>>
>>
> Is the goal is to allow any or a defined set of system preferences to be
> "contextualized" based on branch, patron category, and/or item type?
>
>
>> This, along with a rewritten editor and rules tester tool, would solve a
>> bunch of our customizability problems in one go, without necessarily
>> introducing too much complexity for users (provided we make a good
>> interface).
>>
>>
> Agreed.
>
>
>> I hope to have a patch for this started after 3.8 releases (and all our
>> DB revs are stable for a while).  Any help would be welcomed.
>>
>
> Sounds good. I need this functionality to be in place by August of this
> year, so I'm very interested in getting started as soon as possible. I will
> be carving out time during my workday for it over the next several months.
>
> Kind Regards,
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120322/6cbb454d/attachment.htm>

From marc at msys.ch  Fri Mar 23 11:12:24 2012
From: marc at msys.ch (Marc Balmer)
Date: Fri, 23 Mar 2012 11:12:24 +0100
Subject: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms, please
Message-ID: <4F6C4C88.3060500@msys.ch>

Dear Koha-Devels,

during the Marseille Hackfest 2012 I started together with Stephane and
Christophe from BibLibre to add support for the PostgreSQL database.
The ultimate goal of this work is that Koha can run on a PostgreSQL
server as as good as it does now on a MySQL server.

This mostly boils down to removing the MySQLisms in the current code,
which I am currently doing.  The collect-all-activity bug for this is
7365, it holds dependencies to the individual bugs like 7802, 7806 etc.
(more to come, obviously).  There is also a wiki page
wiki.koha-community/wiki/PostgreSQL which I update frequently.

This work also means that you must not add new MySQLisms in new code.
Especially don't use backuotes in column names, write

INSERT INTO foo (bar) VALUES (42);

instead of

INSERT INTO foo(`bar`) VALUES (42);

For more idioms, consult above mentioned Wiki page, and if in doubt you
can contact me, I am always willing to help with database issues.

And please be advised that adding MySQLisms in new code will fail in QA.

Thanks for your cooperation!  If all goes well, this work should be
concluded in a few months (but we are not in a hurry).

- Marc Balmer

From cnighswonger at foundations.edu  Fri Mar 23 13:27:46 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Fri, 23 Mar 2012 08:27:46 -0400
Subject: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms,
	please
In-Reply-To: <4F6C4C88.3060500@msys.ch>
References: <4F6C4C88.3060500@msys.ch>
Message-ID: <CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>

Hi Marc,

On Fri, Mar 23, 2012 at 6:12 AM, Marc Balmer <marc at msys.ch> wrote:

> Dear Koha-Devels,
>
> during the Marseille Hackfest 2012 I started together with Stephane and
> Christophe from BibLibre to add support for the PostgreSQL database.
> The ultimate goal of this work is that Koha can run on a PostgreSQL
> server as as good as it does now on a MySQL server.
>
> This mostly boils down to removing the MySQLisms in the current code,
> which I am currently doing.  The collect-all-activity bug for this is
> 7365, it holds dependencies to the individual bugs like 7802, 7806 etc.
> (more to come, obviously).  There is also a wiki page
> wiki.koha-community/wiki/PostgreSQL which I update frequently.
>
>
This is good work. I attempted to start this years ago, but soon dropped it
due to my schedule.


> This work also means that you must not add new MySQLisms in new code.
>

...


>
> And please be advised that adding MySQLisms in new code will fail in QA.
>
>
While I agree with this proposition, we are not in the habit as a community
of individual developers (or even groups of developers) "dictating" coding
practices. The accepted procedure to follow is to present the
change/addition via the list to solicit discussion and obtain consensus on
the proposition.

Furthermore, what "will" and "will not" pass QA is subject to
the discretion of the community appointed QA manager, not other individuals.

So I would suggest that we solicit some comment on this to give the
community the opportunity to express its desire.

Kind Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120323/59fa60ee/attachment.htm>

From paul.poulain at biblibre.com  Fri Mar 23 17:20:53 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 23 Mar 2012 17:20:53 +0100
Subject: [Koha-devel] Hackfest 2012 in Marseille feedback
Message-ID: <4F6CA2E5.9090307@biblibre.com>

Hello,

If you want to know what we made during the hackfest i've written an
entry in koha-community.org :
http://koha-community.org/marseille-hackfest-2012-feedback/

Happy reading & thanks to all of those who came !
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From koha.sekjal at gmail.com  Fri Mar 23 17:23:46 2012
From: koha.sekjal at gmail.com (Ian Walls)
Date: Fri, 23 Mar 2012 12:23:46 -0400
Subject: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms,
	please
In-Reply-To: <CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>
References: <4F6C4C88.3060500@msys.ch>
	<CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>
Message-ID: <CANL=k+GJRbhsW4LGjfwHRXg7nSzeZqoWvnVq=rnPiYZk2Jfcmw@mail.gmail.com>

According to rule SQL6 of our Coding Guidelines (
http://wiki.koha-community.org/wiki/Coding_Guidelines#Database), backquotes
are not acceptable, as they are a MySQL-ism.  Part of the duty of QA is to
verify that the coding guidelines are met, so it is reasonable to say that
such markings *should* be stripped out of any new incoming patches.  As to
whether having them results in a "Failed QA" or a followup/rebased patch
from a QA team member is up to the discretion and availability of that team
member.

I know I've been a little lax with this one, as we're still rife with
backquotes in our SQL, and one or two more lines aren't going to add any
significant additional work to our cleanup efforts.  My primary interest is
consistency, because it makes for easier to read and maintain code.  Once
we have done the majority of this cleanup, I'll become stricter about
backquotes.

The ultimate goal here, to the best of my understanding, is database
independence, of which PostgreSQL support is a consequence.  We should do
our best to adhere to standards in all regards; by following SQL standard
practices, we give ourselves more flexibility and adaptability, and
decrease the overall potential workload throughout time.

Cheers,


-Ian

2012/3/23 Chris Nighswonger <cnighswonger at foundations.edu>

> Hi Marc,
>
> On Fri, Mar 23, 2012 at 6:12 AM, Marc Balmer <marc at msys.ch> wrote:
>
>> Dear Koha-Devels,
>>
>> during the Marseille Hackfest 2012 I started together with Stephane and
>> Christophe from BibLibre to add support for the PostgreSQL database.
>> The ultimate goal of this work is that Koha can run on a PostgreSQL
>> server as as good as it does now on a MySQL server.
>>
>> This mostly boils down to removing the MySQLisms in the current code,
>> which I am currently doing.  The collect-all-activity bug for this is
>> 7365, it holds dependencies to the individual bugs like 7802, 7806 etc.
>> (more to come, obviously).  There is also a wiki page
>> wiki.koha-community/wiki/PostgreSQL which I update frequently.
>>
>>
> This is good work. I attempted to start this years ago, but soon dropped
> it due to my schedule.
>
>
>> This work also means that you must not add new MySQLisms in new code.
>>
>
> ...
>
>
>>
>> And please be advised that adding MySQLisms in new code will fail in QA.
>>
>>
> While I agree with this proposition, we are not in the habit as a
> community of individual developers (or even groups of developers)
> "dictating" coding practices. The accepted procedure to follow is to
> present the change/addition via the list to solicit discussion and obtain
> consensus on the proposition.
>
> Furthermore, what "will" and "will not" pass QA is subject to
> the discretion of the community appointed QA manager, not other individuals.
>
> So I would suggest that we solicit some comment on this to give the
> community the opportunity to express its desire.
>
> Kind Regards,
> Chris
>
> _______________________________________________
> 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/20120323/ed2e539e/attachment.htm>

From paul.poulain at biblibre.com  Fri Mar 23 17:37:46 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 23 Mar 2012 17:37:46 +0100
Subject: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms,
 please
In-Reply-To: <CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>
References: <4F6C4C88.3060500@msys.ch>
	<CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>
Message-ID: <4F6CA6DA.3030301@biblibre.com>

Le 23/03/2012 13:27, Chris Nighswonger a ?crit :
> Hi Marc,
Hi Chris,

> Furthermore, what "will" and "will not" pass QA is subject to
> the discretion of the community appointed QA manager, not other individuals.
Marc comment was made after a discussion we had during the hackfest,
where I said him a mysqlism won't pass QA.
The ` rule is in the coding guidelines, as Ian pointed, and I'll try to
be vigilent on this matter

Marc a suggestion= once you'll have listed all "mysqlism" we could add a
test to list them, and I could add some code to my pre-commit hook to
check that no mysqlism is introduced !

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

From marc at msys.ch  Fri Mar 23 18:43:55 2012
From: marc at msys.ch (Marc Balmer)
Date: Fri, 23 Mar 2012 18:43:55 +0100
Subject: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms,
 please
In-Reply-To: <CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>
References: <4F6C4C88.3060500@msys.ch>
	<CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>
Message-ID: <4F6CB65B.7000901@msys.ch>

Am 23.03.12 13:27, schrieb Chris Nighswonger:
> Hi Marc,
> 
> On Fri, Mar 23, 2012 at 6:12 AM, Marc Balmer <marc at msys.ch> wrote:
> 
>> Dear Koha-Devels,
>>
>> during the Marseille Hackfest 2012 I started together with Stephane and
>> Christophe from BibLibre to add support for the PostgreSQL database.
>> The ultimate goal of this work is that Koha can run on a PostgreSQL
>> server as as good as it does now on a MySQL server.
>>
>> This mostly boils down to removing the MySQLisms in the current code,
>> which I am currently doing.  The collect-all-activity bug for this is
>> 7365, it holds dependencies to the individual bugs like 7802, 7806 etc.
>> (more to come, obviously).  There is also a wiki page
>> wiki.koha-community/wiki/PostgreSQL which I update frequently.
>>
>>
> This is good work. I attempted to start this years ago, but soon dropped it
> due to my schedule.
> 
> 
>> This work also means that you must not add new MySQLisms in new code.
>>
> 
> ...
> 
> 
>>
>> And please be advised that adding MySQLisms in new code will fail in QA.
>>
>>
> While I agree with this proposition, we are not in the habit as a community
> of individual developers (or even groups of developers) "dictating" coding
> practices. The accepted procedure to follow is to present the
> change/addition via the list to solicit discussion and obtain consensus on
> the proposition.
> 
> Furthermore, what "will" and "will not" pass QA is subject to
> the discretion of the community appointed QA manager, not other individuals.
> 
> So I would suggest that we solicit some comment on this to give the
> community the opportunity to express its desire.

Supporting PostgreSQL is a stated goal of the Koha Community, so it is
by sheer nature of the fact that no code can be accepted that is in
violation with this goal.

It was, however, Paul Poulain, who told me that he will fail MySQLisms
in the future.  That was not my idea, I only communicated it.  And of
course it makes sense.


From marc at msys.ch  Fri Mar 23 18:48:24 2012
From: marc at msys.ch (Marc Balmer)
Date: Fri, 23 Mar 2012 18:48:24 +0100
Subject: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms,
 please
In-Reply-To: <CANL=k+GJRbhsW4LGjfwHRXg7nSzeZqoWvnVq=rnPiYZk2Jfcmw@mail.gmail.com>
References: <4F6C4C88.3060500@msys.ch>
	<CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>
	<CANL=k+GJRbhsW4LGjfwHRXg7nSzeZqoWvnVq=rnPiYZk2Jfcmw@mail.gmail.com>
Message-ID: <4F6CB768.7000300@msys.ch>

Am 23.03.12 17:23, schrieb Ian Walls:
> According to rule SQL6 of our Coding Guidelines (
> http://wiki.koha-community.org/wiki/Coding_Guidelines#Database), backquotes
> are not acceptable, as they are a MySQL-ism.  Part of the duty of QA is to
> verify that the coding guidelines are met, so it is reasonable to say that
> such markings *should* be stripped out of any new incoming patches.  As to
> whether having them results in a "Failed QA" or a followup/rebased patch
> from a QA team member is up to the discretion and availability of that team
> member.
> 
> I know I've been a little lax with this one, as we're still rife with
> backquotes in our SQL, and one or two more lines aren't going to add any
> significant additional work to our cleanup efforts.  My primary interest is
> consistency, because it makes for easier to read and maintain code.  Once
> we have done the majority of this cleanup, I'll become stricter about
> backquotes.
> 
> The ultimate goal here, to the best of my understanding, is database
> independence, of which PostgreSQL support is a consequence.  We should do
> our best to adhere to standards in all regards; by following SQL standard
> practices, we give ourselves more flexibility and adaptability, and
> decrease the overall potential workload throughout time.

It is on my todo lists to very soon go through the code and provide a
patch that removes the backquotes.  I think we are on a good road now,
and I try to provide small patches, that address one single problem each.

While database independence is a noble goal, it is not achievable.  You
can support some databases, but not all, at least if you want to use
some of the more advanced features a DB system has to offer you.  And in
an advanced and large application like Koha is, you probably want that.

My guess is, that adding support for a second database will show what
can be done and what not.


From koha.sekjal at gmail.com  Fri Mar 23 21:39:20 2012
From: koha.sekjal at gmail.com (Ian Walls)
Date: Fri, 23 Mar 2012 16:39:20 -0400
Subject: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms,
	please
In-Reply-To: <4F6CB768.7000300@msys.ch>
References: <4F6C4C88.3060500@msys.ch>
	<CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>
	<CANL=k+GJRbhsW4LGjfwHRXg7nSzeZqoWvnVq=rnPiYZk2Jfcmw@mail.gmail.com>
	<4F6CB768.7000300@msys.ch>
Message-ID: <CANL=k+EVrx2WqE0oEXNP6pLnG62F=yj_hGtGu2mtjsPodBgGOA@mail.gmail.com>

Marc,


Without concrete examples of what RDMS-specific features would be desirable
for us, I'm more inclined to reach for compliance with standards (and thus
any standards-based RDMS) than for adding support for specific new RDMS
systems.  Now, of course every RDMS is different, and will implement the
standard a little differently, so we can't code for every possible system,
but I do believe we can get most of the ones worth having if we stick with
the standards.

Are there any specific features of PostgreSQL that would lead to a
beneficial new feature for library patrons?  I know there is plenty of
literature on it's merits over MySQL, but how do those translate to
something that the users of Koha can benefit from?

Cheers,


-Ian

On Fri, Mar 23, 2012 at 13:48, Marc Balmer <marc at msys.ch> wrote:

> Am 23.03.12 17:23, schrieb Ian Walls:
> > According to rule SQL6 of our Coding Guidelines (
> > http://wiki.koha-community.org/wiki/Coding_Guidelines#Database),
> backquotes
> > are not acceptable, as they are a MySQL-ism.  Part of the duty of QA is
> to
> > verify that the coding guidelines are met, so it is reasonable to say
> that
> > such markings *should* be stripped out of any new incoming patches.  As
> to
> > whether having them results in a "Failed QA" or a followup/rebased patch
> > from a QA team member is up to the discretion and availability of that
> team
> > member.
> >
> > I know I've been a little lax with this one, as we're still rife with
> > backquotes in our SQL, and one or two more lines aren't going to add any
> > significant additional work to our cleanup efforts.  My primary interest
> is
> > consistency, because it makes for easier to read and maintain code.  Once
> > we have done the majority of this cleanup, I'll become stricter about
> > backquotes.
> >
> > The ultimate goal here, to the best of my understanding, is database
> > independence, of which PostgreSQL support is a consequence.  We should do
> > our best to adhere to standards in all regards; by following SQL standard
> > practices, we give ourselves more flexibility and adaptability, and
> > decrease the overall potential workload throughout time.
>
> It is on my todo lists to very soon go through the code and provide a
> patch that removes the backquotes.  I think we are on a good road now,
> and I try to provide small patches, that address one single problem each.
>
> While database independence is a noble goal, it is not achievable.  You
> can support some databases, but not all, at least if you want to use
> some of the more advanced features a DB system has to offer you.  And in
> an advanced and large application like Koha is, you probably want that.
>
> My guess is, that adding support for a second database will show what
> can be done and what not.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120323/0e4e5389/attachment.htm>

From marc at msys.ch  Fri Mar 23 22:38:57 2012
From: marc at msys.ch (Marc Balmer)
Date: Fri, 23 Mar 2012 22:38:57 +0100
Subject: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms,
 please
In-Reply-To: <CANL=k+EVrx2WqE0oEXNP6pLnG62F=yj_hGtGu2mtjsPodBgGOA@mail.gmail.com>
References: <4F6C4C88.3060500@msys.ch>
	<CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>
	<CANL=k+GJRbhsW4LGjfwHRXg7nSzeZqoWvnVq=rnPiYZk2Jfcmw@mail.gmail.com>
	<4F6CB768.7000300@msys.ch>
	<CANL=k+EVrx2WqE0oEXNP6pLnG62F=yj_hGtGu2mtjsPodBgGOA@mail.gmail.com>
Message-ID: <4F6CED71.1050906@msys.ch>

Am 23.03.12 21:39, schrieb Ian Walls:
> Marc,
> 
> 
> Without concrete examples of what RDMS-specific features would be desirable
> for us, I'm more inclined to reach for compliance with standards (and thus
> any standards-based RDMS) than for adding support for specific new RDMS
> systems.  Now, of course every RDMS is different, and will implement the
> standard a little differently, so we can't code for every possible system,
> but I do believe we can get most of the ones worth having if we stick with
> the standards.

The right thing to do is, in order,

1) Use standard SQL wherever possible
2) Use DBI wherever possible
3) Use DBQ if there is really no other solution

> Are there any specific features of PostgreSQL that would lead to a
> beneficial new feature for library patrons?  I know there is plenty of
> literature on it's merits over MySQL, but how do those translate to
> something that the users of Koha can benefit from?

Yes, of course.

> 
> Cheers,
> 
> 
> -Ian
> 
> On Fri, Mar 23, 2012 at 13:48, Marc Balmer <marc at msys.ch> wrote:
> 
>> Am 23.03.12 17:23, schrieb Ian Walls:
>>> According to rule SQL6 of our Coding Guidelines (
>>> http://wiki.koha-community.org/wiki/Coding_Guidelines#Database),
>> backquotes
>>> are not acceptable, as they are a MySQL-ism.  Part of the duty of QA is
>> to
>>> verify that the coding guidelines are met, so it is reasonable to say
>> that
>>> such markings *should* be stripped out of any new incoming patches.  As
>> to
>>> whether having them results in a "Failed QA" or a followup/rebased patch
>>> from a QA team member is up to the discretion and availability of that
>> team
>>> member.
>>>
>>> I know I've been a little lax with this one, as we're still rife with
>>> backquotes in our SQL, and one or two more lines aren't going to add any
>>> significant additional work to our cleanup efforts.  My primary interest
>> is
>>> consistency, because it makes for easier to read and maintain code.  Once
>>> we have done the majority of this cleanup, I'll become stricter about
>>> backquotes.
>>>
>>> The ultimate goal here, to the best of my understanding, is database
>>> independence, of which PostgreSQL support is a consequence.  We should do
>>> our best to adhere to standards in all regards; by following SQL standard
>>> practices, we give ourselves more flexibility and adaptability, and
>>> decrease the overall potential workload throughout time.
>>
>> It is on my todo lists to very soon go through the code and provide a
>> patch that removes the backquotes.  I think we are on a good road now,
>> and I try to provide small patches, that address one single problem each.
>>
>> While database independence is a noble goal, it is not achievable.  You
>> can support some databases, but not all, at least if you want to use
>> some of the more advanced features a DB system has to offer you.  And in
>> an advanced and large application like Koha is, you probably want that.
>>
>> My guess is, that adding support for a second database will show what
>> can be done and what not.
>>
>>
> 


From chris.nighswonger at gmail.com  Sat Mar 24 02:22:18 2012
From: chris.nighswonger at gmail.com (Christopher Nighswonger)
Date: Fri, 23 Mar 2012 21:22:18 -0400
Subject: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms,
	please
In-Reply-To: <4F6CED71.1050906@msys.ch>
References: <4F6C4C88.3060500@msys.ch>
	<CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>
	<CANL=k+GJRbhsW4LGjfwHRXg7nSzeZqoWvnVq=rnPiYZk2Jfcmw@mail.gmail.com>
	<4F6CB768.7000300@msys.ch>
	<CANL=k+EVrx2WqE0oEXNP6pLnG62F=yj_hGtGu2mtjsPodBgGOA@mail.gmail.com>
	<4F6CED71.1050906@msys.ch>
Message-ID: <CAA7=B8y_ePx+S0UgBQuO=1Ai8bDNZ5ywbW7W7T7NUakj5f7QxQ@mail.gmail.com>

On Fri, Mar 23, 2012 at 5:38 PM, Marc Balmer <marc at msys.ch> wrote:
> Am 23.03.12 21:39, schrieb Ian Walls:
>> Marc,

...

>
>> Are there any specific features of PostgreSQL that would lead to a
>> beneficial new feature for library patrons? ?I know there is plenty of
>> literature on it's merits over MySQL, but how do those translate to
>> something that the users of Koha can benefit from?
>
> Yes, of course.

Such as?

Kind Regards,
Chris

From mtj at kohaaloha.com  Sat Mar 24 10:18:54 2012
From: mtj at kohaaloha.com (Mason James)
Date: Sat, 24 Mar 2012 22:18:54 +1300
Subject: [Koha-devel] Fwd: [Koha-zebra] Apache issue
References: <CAPKxUoLckY5pL9LhcVj1aZ_1=CZGtJ=_UdWpQWgMnfXH7mo_CA@mail.gmail.com>
Message-ID: <4F15D05D-4505-4BE6-9689-9A12FF5D6732@kohaaloha.com>



Begin forwarded message:

> From: luis diaz <luisete2106 at gmail.com>
> Date: 24 March 2012 12:41:41 AM NZDT
> To: koha-zebra at lists.koha-community.org
> Subject: [Koha-zebra] Apache issue
> 
> Hello
>  
> I have a rhel6 server (Linux el6.x86_64 #1 SMP Fri Feb 10 15:22:22 EST 2012 x86_64 x86_64 x86_64 GNU/Linux)
> Red Hat Enterprise Linux Server release 6.2 (Santiago)
>  
> and I have install koha version 3.06.04
> So, all the steps have been done without errors, inclusive the compilation of all the perl packages.
> But, I have an error with the apache configuration, the web pages do not appear, and I have this error:
>  
> Internal Server Error
> 
> The server encountered an internal error or misconfiguration and was unable to complete your request.
> 
> Please contact the server administrator,  and inform them of the time the error occurred, and anything you might have done that may have caused the error.
> 
> More information about this error may be available in the server error log.
> 
> Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request
> 
>  
> I don't know what to look, the error_log do not helps here:
> 
> [Fri Mar 23 06:43:20 2012] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
> [Fri Mar 23 06:43:20 2012] [notice] Digest: generating secret for digest authentication ...
> [Fri Mar 23 06:43:20 2012] [notice] Digest: done
> [Fri Mar 23 06:43:20 2012] [notice] Apache/2.2.15 (Unix) DAV/2 PHP/5.3.3 mod_ssl/2.2.15 OpenSSL/1.0.0-fips mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming normal operations
> [Fri Mar 23 07:36:37 2012] [notice] caught SIGTERM, shutting down
> [Fri Mar 23 07:36:38 2012] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0
> [Fri Mar 23 07:36:38 2012] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
> [Fri Mar 23 07:36:38 2012] [notice] Digest: generating secret for digest authentication ...
> [Fri Mar 23 07:36:38 2012] [notice] Digest: done
> [Fri Mar 23 07:36:38 2012] [notice] Apache/2.2.15 (Unix) DAV/2 PHP/5.3.3 mod_ssl/2.2.15 OpenSSL/1.0.0-fips mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming normal operations
> The specidif koha error log is empty:
> 
>  koha]# tail -200f /var/log/koha/koha-error_log
> 
> Maybe I must disable this:
> 
> SELinux policy enabled?
> 
> Hope some one can help here.
> 
> Thanks a lot in advance
> 
>  
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120324/9ccd1905/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20120324/9ccd1905/attachment.pgp>

From mtj at kohaaloha.com  Sat Mar 24 14:10:58 2012
From: mtj at kohaaloha.com (Mason James)
Date: Sun, 25 Mar 2012 02:10:58 +1300
Subject: [Koha-devel] is there a full koha anonymized test database
	available to squash bugs against?
In-Reply-To: <B164D238-7016-429A-8353-469793909941@nekls.org>
References: <CABg6UYF2bc9aLXpsym_Z--Bs=vFugw7aV_wmFXNO3ji2f4DCKw@mail.gmail.com>
	<1332042747.80965.YahooMailNeo@web39402.mail.mud.yahoo.com>
	<03179EB6-31F0-4453-9940-9377D8B2D3DB@kohaaloha.com>
	<B164D238-7016-429A-8353-469793909941@nekls.org>
Message-ID: <5E72329C-49C6-4576-AD82-1B8A3200B7FB@kohaaloha.com>


On 2012-03-22, at 2:22 AM, Liz Rea wrote:

> I have one that is a combo of sample data and MARC21 data - you can get it at https://github.com/wizzyrea/Scripts-and-Things/blob/master/kohadev-withbibs.sql.gz
> (do note, it's possible the rules in there are not quite sane or not defined in a way that makes sense. Step through the administration when you get it imported.)
> 
> And just the marc data: https://github.com/wizzyrea/Scripts-and-Things/blob/master/MARC21.mrc
> 
> I've got an ongoing project to make a collection of sample data, and rule sets that developers can choose and import at install time, but they are not ready quite yet. :)
> 
> Liz Rea


oooh, nice one Liz :)

perhaps we could work towards using some standardized  data-sets for testing Koha 
we could have a set of UNIMARC, USMARC-MARC21 and NORMARC bibs, patrons, and a basically configured Koha database)

does anyone else have any UNIMARC, NORMARC (and other *MARC) data-sets they could contribute?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20120325/e8f16f00/attachment.pgp>

From tomascohen at gmail.com  Sat Mar 24 14:20:12 2012
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Sat, 24 Mar 2012 10:20:12 -0300
Subject: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms,
	please
In-Reply-To: <CAA7=B8y_ePx+S0UgBQuO=1Ai8bDNZ5ywbW7W7T7NUakj5f7QxQ@mail.gmail.com>
References: <4F6C4C88.3060500@msys.ch>
	<CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>
	<CANL=k+GJRbhsW4LGjfwHRXg7nSzeZqoWvnVq=rnPiYZk2Jfcmw@mail.gmail.com>
	<4F6CB768.7000300@msys.ch>
	<CANL=k+EVrx2WqE0oEXNP6pLnG62F=yj_hGtGu2mtjsPodBgGOA@mail.gmail.com>
	<4F6CED71.1050906@msys.ch>
	<CAA7=B8y_ePx+S0UgBQuO=1Ai8bDNZ5ywbW7W7T7NUakj5f7QxQ@mail.gmail.com>
Message-ID: <CABZfb=UbxBKcv_n1W1anAAaqi76Yvu63NxrqG9dze9HA_oR52A@mail.gmail.com>

El 23/03/2012 22:22, "Christopher Nighswonger" <chris.nighswonger at gmail.com>
escribi?:
>
> On Fri, Mar 23, 2012 at 5:38 PM, Marc Balmer <marc at msys.ch> wrote:
> > Am 23.03.12 21:39, schrieb Ian Walls:
> >> Marc,
>
> ...
>
> >
> >> Are there any specific features of PostgreSQL that would lead to a
> >> beneficial new feature for library patrons?  I know there is plenty of
> >> literature on it's merits over MySQL, but how do those translate to
> >> something that the users of Koha can benefit from?
> >
> > Yes, of course.
>
> Such as?

ExtractValue for custom reports?

To+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120324/ecbc7366/attachment.htm>

From jcamins at cpbibliography.com  Sat Mar 24 14:28:06 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Sat, 24 Mar 2012 09:28:06 -0400
Subject: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms,
	please
In-Reply-To: <CABZfb=UbxBKcv_n1W1anAAaqi76Yvu63NxrqG9dze9HA_oR52A@mail.gmail.com>
References: <4F6C4C88.3060500@msys.ch>
	<CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>
	<CANL=k+GJRbhsW4LGjfwHRXg7nSzeZqoWvnVq=rnPiYZk2Jfcmw@mail.gmail.com>
	<4F6CB768.7000300@msys.ch>
	<CANL=k+EVrx2WqE0oEXNP6pLnG62F=yj_hGtGu2mtjsPodBgGOA@mail.gmail.com>
	<4F6CED71.1050906@msys.ch>
	<CAA7=B8y_ePx+S0UgBQuO=1Ai8bDNZ5ywbW7W7T7NUakj5f7QxQ@mail.gmail.com>
	<CABZfb=UbxBKcv_n1W1anAAaqi76Yvu63NxrqG9dze9HA_oR52A@mail.gmail.com>
Message-ID: <CALVDfQyTW=+o8rBvn-WWzkgyY6AG5Dq7rZXMdeVDThN9MaT94g@mail.gmail.com>

Tomas,

> >> Are there any specific features of PostgreSQL that would lead to a
> > >> beneficial new feature for library patrons?  I know there is plenty of
> > >> literature on it's merits over MySQL, but how do those translate to
> > >> something that the users of Koha can benefit from?
> > >
> > > Yes, of course.
> >
> > Such as?
>
> ExtractValue for custom reports?
>

MySQL supports ExtractValue too. Is there something special in the Postgres
functionality that makes a difference for the end user?

Regards,
Jared

-- 
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/20120324/99895c88/attachment.htm>

From robin at catalyst.net.nz  Sat Mar 24 14:44:08 2012
From: robin at catalyst.net.nz (Robin Sheat)
Date: Sun, 25 Mar 2012 02:44:08 +1300
Subject: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms,
 please
In-Reply-To: <CALVDfQyTW=+o8rBvn-WWzkgyY6AG5Dq7rZXMdeVDThN9MaT94g@mail.gmail.com>
References: <4F6C4C88.3060500@msys.ch>
	<CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>
	<CANL=k+GJRbhsW4LGjfwHRXg7nSzeZqoWvnVq=rnPiYZk2Jfcmw@mail.gmail.com>
	<4F6CB768.7000300@msys.ch>
	<CANL=k+EVrx2WqE0oEXNP6pLnG62F=yj_hGtGu2mtjsPodBgGOA@mail.gmail.com>
	<4F6CED71.1050906@msys.ch>
	<CAA7=B8y_ePx+S0UgBQuO=1Ai8bDNZ5ywbW7W7T7NUakj5f7QxQ@mail.gmail.com>
	<CABZfb=UbxBKcv_n1W1anAAaqi76Yvu63NxrqG9dze9HA_oR52A@mail.gmail.com>
	<CALVDfQyTW=+o8rBvn-WWzkgyY6AG5Dq7rZXMdeVDThN9MaT94g@mail.gmail.com>
Message-ID: <4F6DCFA8.8080304@catalyst.net.nz>

Op 25-03-12 02:28, Jared Camins-Esakov schreef:
> MySQL supports ExtractValue too. Is there something special in the
> Postgres functionality that makes a difference for the end user?

Actually, this is something worth considering when supporting multiple
databases: some reports may require a different syntax/function names.
While it wouldn't be a blocker or anything like that, it's worth keeping
in mind.

Robin.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: </pipermail/koha-devel/attachments/20120325/da2aa86a/attachment.pgp>

From marc at msys.ch  Sat Mar 24 15:01:47 2012
From: marc at msys.ch (Marc Balmer)
Date: Sat, 24 Mar 2012 15:01:47 +0100
Subject: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms,
 please
In-Reply-To: <4F6DCFA8.8080304@catalyst.net.nz>
References: <4F6C4C88.3060500@msys.ch>
	<CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>
	<CANL=k+GJRbhsW4LGjfwHRXg7nSzeZqoWvnVq=rnPiYZk2Jfcmw@mail.gmail.com>
	<4F6CB768.7000300@msys.ch>
	<CANL=k+EVrx2WqE0oEXNP6pLnG62F=yj_hGtGu2mtjsPodBgGOA@mail.gmail.com>
	<4F6CED71.1050906@msys.ch>
	<CAA7=B8y_ePx+S0UgBQuO=1Ai8bDNZ5ywbW7W7T7NUakj5f7QxQ@mail.gmail.com>
	<CABZfb=UbxBKcv_n1W1anAAaqi76Yvu63NxrqG9dze9HA_oR52A@mail.gmail.com>
	<CALVDfQyTW=+o8rBvn-WWzkgyY6AG5Dq7rZXMdeVDThN9MaT94g@mail.gmail.com>
	<4F6DCFA8.8080304@catalyst.net.nz>
Message-ID: <4F6DD3CB.8030202@msys.ch>

Am 24.03.12 14:44, schrieb Robin Sheat:

> Op 25-03-12 02:28, Jared Camins-Esakov schreef:
>> MySQL supports ExtractValue too. Is there something special in the
>> Postgres functionality that makes a difference for the end user?
> 
> Actually, this is something worth considering when supporting multiple
> databases: some reports may require a different syntax/function names.
> While it wouldn't be a blocker or anything like that, it's worth keeping
> in mind.

We adress this problem with the DBQ module, which exists to produce
database specific SQL code when there is no standard way to express sth
and when there is no way to get it through DBI.  See the example we
bundled with the path in bug 7365.

- mb


From robin at catalyst.net.nz  Sat Mar 24 15:07:49 2012
From: robin at catalyst.net.nz (Robin Sheat)
Date: Sun, 25 Mar 2012 03:07:49 +1300
Subject: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms,
 please
In-Reply-To: <4F6DD3CB.8030202@msys.ch>
References: <4F6C4C88.3060500@msys.ch>
	<CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>
	<CANL=k+GJRbhsW4LGjfwHRXg7nSzeZqoWvnVq=rnPiYZk2Jfcmw@mail.gmail.com>
	<4F6CB768.7000300@msys.ch>
	<CANL=k+EVrx2WqE0oEXNP6pLnG62F=yj_hGtGu2mtjsPodBgGOA@mail.gmail.com>
	<4F6CED71.1050906@msys.ch>
	<CAA7=B8y_ePx+S0UgBQuO=1Ai8bDNZ5ywbW7W7T7NUakj5f7QxQ@mail.gmail.com>
	<CABZfb=UbxBKcv_n1W1anAAaqi76Yvu63NxrqG9dze9HA_oR52A@mail.gmail.com>
	<CALVDfQyTW=+o8rBvn-WWzkgyY6AG5Dq7rZXMdeVDThN9MaT94g@mail.gmail.com>
	<4F6DCFA8.8080304@catalyst.net.nz> <4F6DD3CB.8030202@msys.ch>
Message-ID: <4F6DD535.8040605@catalyst.net.nz>

Op 25-03-12 03:01, Marc Balmer schreef:
> We adress this problem with the DBQ module, which exists to produce
> database specific SQL code when there is no standard way to express sth
> and when there is no way to get it through DBI.  See the example we
> bundled with the path in bug 7365.

I'm not going to read the code because it's 3am, but does it rewrite the
reports people enter or something? That seems dangerous unless done
super-carefully.

(Also, the DBQ stuff seems to be quite underdocumented. It doesn't even
say what it is!)

Robin.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: </pipermail/koha-devel/attachments/20120325/ab876875/attachment.pgp>

From marc at msys.ch  Sat Mar 24 15:19:33 2012
From: marc at msys.ch (Marc Balmer)
Date: Sat, 24 Mar 2012 15:19:33 +0100
Subject: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms,
 please
In-Reply-To: <4F6DD535.8040605@catalyst.net.nz>
References: <4F6C4C88.3060500@msys.ch>
	<CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>
	<CANL=k+GJRbhsW4LGjfwHRXg7nSzeZqoWvnVq=rnPiYZk2Jfcmw@mail.gmail.com>
	<4F6CB768.7000300@msys.ch>
	<CANL=k+EVrx2WqE0oEXNP6pLnG62F=yj_hGtGu2mtjsPodBgGOA@mail.gmail.com>
	<4F6CED71.1050906@msys.ch>
	<CAA7=B8y_ePx+S0UgBQuO=1Ai8bDNZ5ywbW7W7T7NUakj5f7QxQ@mail.gmail.com>
	<CABZfb=UbxBKcv_n1W1anAAaqi76Yvu63NxrqG9dze9HA_oR52A@mail.gmail.com>
	<CALVDfQyTW=+o8rBvn-WWzkgyY6AG5Dq7rZXMdeVDThN9MaT94g@mail.gmail.com>
	<4F6DCFA8.8080304@catalyst.net.nz> <4F6DD3CB.8030202@msys.ch>
	<4F6DD535.8040605@catalyst.net.nz>
Message-ID: <4F6DD7F5.2070405@msys.ch>

Am 24.03.12 15:07, schrieb Robin Sheat:
> Op 25-03-12 03:01, Marc Balmer schreef:
>> We adress this problem with the DBQ module, which exists to produce
>> database specific SQL code when there is no standard way to express sth
>> and when there is no way to get it through DBI.  See the example we
>> bundled with the path in bug 7365.
> 
> I'm not going to read the code because it's 3am, but does it rewrite the
> reports people enter or something? That seems dangerous unless done
> super-carefully.

No, it does not rewrite any reports.  If users enter SQL somewhere, I
assume they enter proper SQL for their DB server.  Which leads to a
small problem:  Reports that people share should be flagged as MySQL
only, PostgreSQL only, or portable.  Well, at least once Koha runs on
sth different than MySQL...

I am considering to write a set of compatability functions for
PostgreSQL that add the most used MySQL functions, but I don't know yet
how to mimick server crashes and data loss that can occur in MySQL :>

> 
> (Also, the DBQ stuff seems to be quite underdocumented. It doesn't even
> say what it is!)

Id'd say it becomes clear once look at the bug and code.  DBQ stands for
Data Base Query and ir produces database specific SQL.  It must only be
used where there is no other way to get the job done (i.e. don't use it
to produce DB specific code when there is a standard SQL way of doing so
or when there is corresponding functionality in DBI).

- mb


From robin at catalyst.net.nz  Sat Mar 24 15:35:39 2012
From: robin at catalyst.net.nz (Robin Sheat)
Date: Sun, 25 Mar 2012 03:35:39 +1300
Subject: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms,
 please
In-Reply-To: <4F6DD7F5.2070405@msys.ch>
References: <4F6C4C88.3060500@msys.ch>
	<CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>
	<CANL=k+GJRbhsW4LGjfwHRXg7nSzeZqoWvnVq=rnPiYZk2Jfcmw@mail.gmail.com>
	<4F6CB768.7000300@msys.ch>
	<CANL=k+EVrx2WqE0oEXNP6pLnG62F=yj_hGtGu2mtjsPodBgGOA@mail.gmail.com>
	<4F6CED71.1050906@msys.ch>
	<CAA7=B8y_ePx+S0UgBQuO=1Ai8bDNZ5ywbW7W7T7NUakj5f7QxQ@mail.gmail.com>
	<CABZfb=UbxBKcv_n1W1anAAaqi76Yvu63NxrqG9dze9HA_oR52A@mail.gmail.com>
	<CALVDfQyTW=+o8rBvn-WWzkgyY6AG5Dq7rZXMdeVDThN9MaT94g@mail.gmail.com>
	<4F6DCFA8.8080304@catalyst.net.nz> <4F6DD3CB.8030202@msys.ch>
	<4F6DD535.8040605@catalyst.net.nz> <4F6DD7F5.2070405@msys.ch>
Message-ID: <4F6DDBBB.3000708@catalyst.net.nz>

Op 25-03-12 03:19, Marc Balmer schreef:
> No, it does not rewrite any reports.  If users enter SQL somewhere, I
> assume they enter proper SQL for their DB server.  Which leads to a

OK, so it doesn't address this (quite minor) problem.

> I am considering to write a set of compatability functions for
> PostgreSQL that add the most used MySQL functions, but I don't know yet
> how to mimick server crashes and data loss that can occur in MySQL :>

I'd have a look through the reports library on the wiki and see what
functions are in use. There won't be many. ExtractValue is the only
common one I know of, dunno if the pgsql equivalent is syntactically the
same.

> Id'd say it becomes clear once look at the bug and code.  DBQ stands for

The bug doesn't count once the code is in master. The code isn't clear
because the documentation doesn't say anything about what it does, so
there's no context. So no, not clear at all for someone trying to figure
out what a particular call's purpose is.

One particular example:

=head2 ifNull

$value = $dbq->ifNull($a, $b);

Returns $a if not null, else return $b

=cut

This is actually wrong if you take it at face value out of context. It
returns a string that does that in the database. That should be noted.
But more importantly, there's no documentation saying anything about the
purpose of all this. Don't assume people can work it out from the code
because that's a waste of their time. Make it explicit. You're creating
an API that can be produced by perldoc. (This said, it's nice to see
perldoc comments in there at all - so much of the code doesn't have
anything.)

As an aside, the lack of placeholder use in these functions is a little
scary. I know that's hard to do, but it'd be worth trying.

> Data Base Query and ir produces database specific SQL.  It must only be
> used where there is no other way to get the job done (i.e. don't use it
> to produce DB specific code when there is a standard SQL way of doing so
> or when there is corresponding functionality in DBI).

Then say this somewhere in the documentation.

Robin.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: </pipermail/koha-devel/attachments/20120325/ff67d073/attachment.pgp>

From marc at msys.ch  Sat Mar 24 16:05:17 2012
From: marc at msys.ch (Marc Balmer)
Date: Sat, 24 Mar 2012 16:05:17 +0100
Subject: [Koha-devel] Adding support for PostgreSQL, no new MySQLisms,
 please
In-Reply-To: <4F6DDBBB.3000708@catalyst.net.nz>
References: <4F6C4C88.3060500@msys.ch>
	<CAP3yOo=0hCP3_cX02Q5EW5N17iFyJLhcOj5_vg5yAUQmC7tE-Q@mail.gmail.com>
	<CANL=k+GJRbhsW4LGjfwHRXg7nSzeZqoWvnVq=rnPiYZk2Jfcmw@mail.gmail.com>
	<4F6CB768.7000300@msys.ch>
	<CANL=k+EVrx2WqE0oEXNP6pLnG62F=yj_hGtGu2mtjsPodBgGOA@mail.gmail.com>
	<4F6CED71.1050906@msys.ch>
	<CAA7=B8y_ePx+S0UgBQuO=1Ai8bDNZ5ywbW7W7T7NUakj5f7QxQ@mail.gmail.com>
	<CABZfb=UbxBKcv_n1W1anAAaqi76Yvu63NxrqG9dze9HA_oR52A@mail.gmail.com>
	<CALVDfQyTW=+o8rBvn-WWzkgyY6AG5Dq7rZXMdeVDThN9MaT94g@mail.gmail.com>
	<4F6DCFA8.8080304@catalyst.net.nz> <4F6DD3CB.8030202@msys.ch>
	<4F6DD535.8040605@catalyst.net.nz> <4F6DD7F5.2070405@msys.ch>
	<4F6DDBBB.3000708@catalyst.net.nz>
Message-ID: <4F6DE2AD.6020707@msys.ch>

Am 24.03.12 15:35, schrieb Robin Sheat:
> Op 25-03-12 03:19, Marc Balmer schreef:
>> No, it does not rewrite any reports.  If users enter SQL somewhere, I
>> assume they enter proper SQL for their DB server.  Which leads to a
> 
> OK, so it doesn't address this (quite minor) problem.

It would mean parsing the SQL and rewriting it.  I think - besides that
is hard to do right - it would be way over the top.

> 
>> I am considering to write a set of compatability functions for
>> PostgreSQL that add the most used MySQL functions, but I don't know yet
>> how to mimick server crashes and data loss that can occur in MySQL :>
> 
> I'd have a look through the reports library on the wiki and see what
> functions are in use. There won't be many. ExtractValue is the only
> common one I know of, dunno if the pgsql equivalent is syntactically the
> same.
> 
>> Id'd say it becomes clear once look at the bug and code.  DBQ stands for
> 
> The bug doesn't count once the code is in master. The code isn't clear
> because the documentation doesn't say anything about what it does, so
> there's no context. So no, not clear at all for someone trying to figure
> out what a particular call's purpose is.
> 
> One particular example:
> 
> =head2 ifNull
> 
> $value = $dbq->ifNull($a, $b);
> 
> Returns $a if not null, else return $b
> 
> =cut
> 
> This is actually wrong if you take it at face value out of context. It
> returns a string that does that in the database. That should be noted.
> But more importantly, there's no documentation saying anything about the
> purpose of all this. Don't assume people can work it out from the code
> because that's a waste of their time. Make it explicit. You're creating
> an API that can be produced by perldoc. (This said, it's nice to see
> perldoc comments in there at all - so much of the code doesn't have
> anything.)
> 
> As an aside, the lack of placeholder use in these functions is a little
> scary. I know that's hard to do, but it'd be worth trying.
> 
>> Data Base Query and ir produces database specific SQL.  It must only be
>> used where there is no other way to get the job done (i.e. don't use it
>> to produce DB specific code when there is a standard SQL way of doing so
>> or when there is corresponding functionality in DBI).
> 
> Then say this somewhere in the documentation.

FWIW, there is some explanations on the wiki at
wiki.koha-community.org/wiki/PostgreSQL.

It is work in progress, so see it in that context.  In the end, it will
be documented, it's just that we don't know yet which idioms exactly
need to go into DBQ (it will become more clear once we can install Koha
on PostgreSQL and are able to actually test the real functionality).

- mb


From fridolyn.somers at gmail.com  Mon Mar 26 10:46:57 2012
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Mon, 26 Mar 2012 10:46:57 +0200
Subject: [Koha-devel] Fwd: [Koha-zebra] Apache issue
In-Reply-To: <4F15D05D-4505-4BE6-9689-9A12FF5D6732@kohaaloha.com>
References: <CAPKxUoLckY5pL9LhcVj1aZ_1=CZGtJ=_UdWpQWgMnfXH7mo_CA@mail.gmail.com>
	<4F15D05D-4505-4BE6-9689-9A12FF5D6732@kohaaloha.com>
Message-ID: <CAN6cLAUJxxBK3zM1kDoxunJnUGKPwLpVp35q=1fCSmwmJ_UjrA@mail.gmail.com>

Hie,

What about apache's logs ?
I think Internal Server Error whitout perl error means there is a problem
between Apache and perl.

First, test if you activated Apache url rewrite module : mod_rewrite.
Second, i noticed you have mod_perl installed. Koha does not use it, it may
be a cause.

I think you must find in Apache conf how perl files (*.pl) are linked to
perl executor (/usr/bin/perl).
Look at : http://httpd.apache.org/docs/2.0/mod/mod_mime.html#addhandler

Best regards,

2012/3/24 Mason James <mtj at kohaaloha.com>

>
>
> Begin forwarded message:
>
> *From: *luis diaz <luisete2106 at gmail.com>
> *Date: *24 March 2012 12:41:41 AM NZDT
> *To: *koha-zebra at lists.koha-community.org
> *Subject: **[Koha-zebra] Apache issue*
>
> Hello
>
> I have a rhel6 server (Linux el6.x86_64 #1 SMP Fri Feb 10 15:22:22 EST
> 2012 x86_64 x86_64 x86_64 GNU/Linux)
> Red Hat Enterprise Linux Server release 6.2 (Santiago)
>
> and I have install koha version 3.06.04
> So, all the steps have been done without errors, inclusive the compilation
> of all the perl packages.
> But, I have an error with the apache configuration, the web pages do not
> appear, and I have this error:
>
>  Internal Server Error
>
> The server encountered an internal error or misconfiguration and was
> unable to complete your request.
>
> Please contact the server administrator,  and inform them of the time the
> error occurred, and anything you might have done that may have caused the
> error.
>
> More information about this error may be available in the server error log.
>
> Additionally, a 500 Internal Server Error error was encountered while
> trying to use an ErrorDocument to handle the request
>
>
> I don't know what to look, the error_log do not helps here:
>
> [Fri Mar 23 06:43:20 2012] [notice] suEXEC mechanism enabled (wrapper:
> /usr/sbin/suexec)
> [Fri Mar 23 06:43:20 2012] [notice] Digest: generating secret for digest
> authentication ...
> [Fri Mar 23 06:43:20 2012] [notice] Digest: done
> [Fri Mar 23 06:43:20 2012] [notice] Apache/2.2.15 (Unix) DAV/2 PHP/5.3.3
> mod_ssl/2.2.15 OpenSSL/1.0.0-fips mod_perl/2.0.4 Perl/v5.10.1 configured --
> resuming normal operations
> [Fri Mar 23 07:36:37 2012] [notice] caught SIGTERM, shutting down
> [Fri Mar 23 07:36:38 2012] [notice] SELinux policy enabled; httpd running
> as context unconfined_u:system_r:httpd_t:s0
> [Fri Mar 23 07:36:38 2012] [notice] suEXEC mechanism enabled (wrapper:
> /usr/sbin/suexec)
> [Fri Mar 23 07:36:38 2012] [notice] Digest: generating secret for digest
> authentication ...
> [Fri Mar 23 07:36:38 2012] [notice] Digest: done
> [Fri Mar 23 07:36:38 2012] [notice] Apache/2.2.15 (Unix) DAV/2 PHP/5.3.3
> mod_ssl/2.2.15 OpenSSL/1.0.0-fips mod_perl/2.0.4 Perl/v5.10.1 configured --
> resuming normal operations
>
> The specidif koha error log is empty:
>
>  koha]# tail -200f /var/log/koha/koha-error_log
>
> Maybe I must disable this:
>
> SELinux policy enabled?
>
> Hope some one can help here.
>
> Thanks a lot in advance
>
>
>
>
> _______________________________________________
> 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/
>



-- 
Fridolyn SOMERS
fridolyn.somers at gmail.com
Marsillargues - France
<fridolyn.somers at gmail.com>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20120326/3467d219/attachment.htm>

From paul.poulain at biblibre.com  Mon Mar 26 17:17:16 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Mon, 26 Mar 2012 17:17:16 +0200
Subject: [Koha-devel] 3.8 feature freeze
Message-ID: <4F70887C.2060501@biblibre.com>

Hello koha-devel,

2 weeks ago I posted a mail about the release schedule, saying:
March, 23th (1 month before the release) = feature freeze.
April, 6th = strong feature freeze, string freeze
April 20th = starting release process, everything frozen
April 23th = release of Koha 3.8.0

The "feature freeze" was explained a little bit more on the wiki page:
* No major enhancements will be included after this date for this
release. By "major" I mean an enhancement that has many string change(s)
and/or database change and/or introduce major changes in the core of
Koha, with an important risk of side-effect.
* other enhancements can still make their way into 3.8
* bugfixes can still make their way into 3.8

I couldn't push all what was passed QA on friday, so I pushed some
patches today, without taking care of the feature freeze, that I declare
for the end of today.

Some have aked me what I would consider as a "major ENH", and what I
would consider as a "not major enh" ? (that still can be pushed this or
next week)?

I've reviewed all the patches that are in "need signoff" or "signed off"
status, and could find only 2 that fit the definition of "major ENH"
* Bug 7710 - multiple holds per title
* Bug 7818 - support DOM mode for Zebra indexing of bibliographic records
Those bugs 1-are large 2-are related to the core of Koha 3- could have
side effect
So they will wait for 3.10.

All other patches can still continue their way for Koha 3.8

For the following bugs i'll be double checking, because there is a risk
of side effect that is not negligible, and I hesitated to put them in
the previous list:
* Bug 7420 - Add max fines to circulation matrix
* Bug 7641 - Add ability to suspend reserves
* Bug 7736 - Edifact QUOTE and ORDER functionality (the side effect of
this one is negligible, but the patch is huge !)

But if they have a strong signoff (or, better, 2) before the "strong
feature freeze", I'll push them.

Comment on some other bugs:
Bug 7759 - Use Koha-Contrib-Tamil to update Zebra data in background =>
would be an alternative, not a replacement, so could push it.

Also, as a conclusion: as the perltidy process has not reached a
consensus -which I sincerely thought it had !- I won't do anything about it.
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From gmc at esilibrary.com  Mon Mar 26 18:06:38 2012
From: gmc at esilibrary.com (Galen Charlton)
Date: Mon, 26 Mar 2012 12:06:38 -0400
Subject: [Koha-devel] 3.8 feature freeze
In-Reply-To: <4F70887C.2060501@biblibre.com>
References: <4F70887C.2060501@biblibre.com>
Message-ID: <4BC4E2F8-8AA8-4521-AB65-98BEC30CC99F@esilibrary.com>

Hi,

On Mar 26, 2012, at 11:17 AM, Paul Poulain wrote:
> * Bug 7818 - support DOM mode for Zebra indexing of bibliographic records
> Those bugs 1-are large 2-are related to the core of Koha 3- could have
> side effect
> So they will wait for 3.10.

I'd like to request that you reconsider this decision -- DOM filter indexing, while it does indeed represent a major enhancement, would not be a mandatory enhancement, since users would continue to be able to use the GRS-1 filter if they wish.  By design, the initial set of DOM rules for MARC21 closely match the records.abs definition.

In conjunction with the Solr work that BibLibre and others are undertaking, I'd like to toss another idea out -- of starting the process of deprecating GRS-1 use in 3.10.

Regards,

Galen
--
Galen Charlton
Director of Support and Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org


From koha.sekjal at gmail.com  Tue Mar 27 19:21:36 2012
From: koha.sekjal at gmail.com (Ian Walls)
Date: Tue, 27 Mar 2012 13:21:36 -0400
Subject: [Koha-devel] 3.8 feature freeze
In-Reply-To: <4BC4E2F8-8AA8-4521-AB65-98BEC30CC99F@esilibrary.com>
References: <4F70887C.2060501@biblibre.com>
	<4BC4E2F8-8AA8-4521-AB65-98BEC30CC99F@esilibrary.com>
Message-ID: <CANL=k+FsNX-=t-aVn583dyiJr3c6HfeWW99SChoPfiun=Jb6ug@mail.gmail.com>

Looking over the patches on the Equinox branch, it does seem that while
this is a significant feature in terms of it's meaning and utility, it has
very little impact on the existing code, and will sit benignly in the
corner until it is called upon.

One of the XSLTs for DOM authorities is moved so it can be used by both
biblios and authorities... we'd need to confirm that DOM authority indexing
still behaves itself on both upgraded and new installations.  Other than
that, we're pretty safe to include these files, even if they're still being
tested and developed (and what part of Koha isn't?)  Users can make the
choice to opt-in, or leave things as the default and experience no change.

If we can confirm the above mentioned tests and get signoff on it before
the beginning of April (such a quick signoff could be seen as community
interest), I'd say this is safe for inclusion in 3.8, even if we need to
mark it as still 'in beta' until 3.10.  Of course it's your call, Paul, but
that's my opinion on the matter.


-Ian

On Mon, Mar 26, 2012 at 12:06, Galen Charlton <gmc at esilibrary.com> wrote:

> Hi,
>
> On Mar 26, 2012, at 11:17 AM, Paul Poulain wrote:
> > * Bug 7818 - support DOM mode for Zebra indexing of bibliographic records
> > Those bugs 1-are large 2-are related to the core of Koha 3- could have
> > side effect
> > So they will wait for 3.10.
>
> I'd like to request that you reconsider this decision -- DOM filter
> indexing, while it does indeed represent a major enhancement, would not be
> a mandatory enhancement, since users would continue to be able to use the
> GRS-1 filter if they wish.  By design, the initial set of DOM rules for
> MARC21 closely match the records.abs definition.
>
> In conjunction with the Solr work that BibLibre and others are
> undertaking, I'd like to toss another idea out -- of starting the process
> of deprecating GRS-1 use in 3.10.
>
> Regards,
>
> Galen
> --
> Galen Charlton
> Director of Support and Implementation
> Equinox Software, Inc. / The Open Source Experts
> email:  gmc at esilibrary.com
> direct: +1 770-709-5581
> cell:   +1 404-984-4366
> skype:  gmcharlt
> web:    http://www.esilibrary.com/
> Supporting Koha and Evergreen: http://koha-community.org &
> http://evergreen-ils.org
>
> _______________________________________________
> Koha-devel mailing 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/20120327/0165edd4/attachment.htm>

From jcamins at cpbibliography.com  Tue Mar 27 19:43:01 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Tue, 27 Mar 2012 13:43:01 -0400
Subject: [Koha-devel] 3.8 feature freeze
In-Reply-To: <CANL=k+FsNX-=t-aVn583dyiJr3c6HfeWW99SChoPfiun=Jb6ug@mail.gmail.com>
References: <4F70887C.2060501@biblibre.com>
	<4BC4E2F8-8AA8-4521-AB65-98BEC30CC99F@esilibrary.com>
	<CANL=k+FsNX-=t-aVn583dyiJr3c6HfeWW99SChoPfiun=Jb6ug@mail.gmail.com>
Message-ID: <CALVDfQzjtxtr7DoThk3wE+2bDUp0FgrtfHMxqs+T-NumN2e67A@mail.gmail.com>

Ian,

A brief note in response to your concern:

One of the XSLTs for DOM authorities is moved so it can be used by both
> biblios and authorities... we'd need to confirm that DOM authority indexing
> still behaves itself on both upgraded and new installations.  Other than
> that, we're pretty safe to include these files, even if they're still being
> tested and developed (and what part of Koha isn't?)  Users can make the
> choice to opt-in, or leave things as the default and experience no change.
>

The XSLT in question, koha-indexdefs-to-zebra.xsl is not actually used by
Zebra in the day-to-day business of indexing. It's used by developers who
are revising their DOM index definitions themselves. As far as I know,
Galen and I are the only two people who have modified the authorities DOM
configuration, and therefore the only two people who have actually used
that conversion script, most likely. As an aside, Galen and I briefly
discussed the wisdom of storing the generated authority-zebra-indexdefs.xsl
in the git repository, but concluded that there was no reason to add a
dependency on xsltproc, given that the file rarely needs to be regenerated.

In conjunction with the Solr work that BibLibre and others are undertaking,
>> I'd like to toss another idea out -- of starting the process of deprecating
>> GRS-1 use in 3.10.
>>
>
Woohoo! +1 from me! Pursuant to that goal, Bug 7421 (by Fr?d?ric Demians)
implements DOM indexing for UNIMARC authorities (
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7421 ).

Regards,
Jared

-- 
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/20120327/b5905959/attachment.htm>

From brian at jhu.edu  Tue Mar 27 20:06:57 2012
From: brian at jhu.edu (Brian Harrington)
Date: Tue, 27 Mar 2012 14:06:57 -0400
Subject: [Koha-devel] 3.8 feature freeze
In-Reply-To: <CALVDfQzjtxtr7DoThk3wE+2bDUp0FgrtfHMxqs+T-NumN2e67A@mail.gmail.com>
References: <4F70887C.2060501@biblibre.com>
	<4BC4E2F8-8AA8-4521-AB65-98BEC30CC99F@esilibrary.com>
	<CANL=k+FsNX-=t-aVn583dyiJr3c6HfeWW99SChoPfiun=Jb6ug@mail.gmail.com>
	<CALVDfQzjtxtr7DoThk3wE+2bDUp0FgrtfHMxqs+T-NumN2e67A@mail.gmail.com>
Message-ID: <4F7201C1.7050102@jhu.edu>

On 3/27/12 1:43 PM, Jared Camins-Esakov wrote:
> The XSLT in question, koha-indexdefs-to-zebra.xsl is not actually used
> by Zebra in the day-to-day business of indexing. It's used by developers
> who are revising their DOM index definitions themselves. As far as I
> know, Galen and I are the only two people who have modified the
> authorities DOM configuration, and therefore the only two people who
> have actually used that conversion script, most likely. As an aside,
> Galen and I briefly discussed the wisdom of storing the generated
> authority-zebra-indexdefs.xsl in the git repository, but concluded that
> there was no reason to add a dependency on xsltproc, given that the file
> rarely needs to be regenerated.

I just wanted to mention that we also use a modified DOM authorities 
configuration.  We're a couple of versions behind, so it would be hard 
for me to test anything in timely manner this time around, but Jared's 
absolutely correct that moving koha-indexdefs-to-zebra.xsl should have 
no effect on day-to-day functionality.

Brian

-- 
Brian Harrington
Content Development Coordinator
Project MUSE
The Johns Hopkins University Press
brian at jhu.edu

From danielg.koha at gmail.com  Tue Mar 27 21:19:21 2012
From: danielg.koha at gmail.com (Daniel Grobani)
Date: Tue, 27 Mar 2012 12:19:21 -0700
Subject: [Koha-devel] Official Koha Newsletter: Volume 3, Issue 3: March 2012
Message-ID: <CAOeKewh76d=ELziD6zPHLCAGSNNu1b=EpbXMCwARNPFjGYuFDg@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-3-issue-3-march-2012]

Official Koha Newsletter (ISSN 2153-8328) Subscribe
Volume 3, Issue 3: March 2012

Edited by Daniel Grobani, Koha Community Newsletter Editor.

Please submit news items to danielg.koha at gmail.com.

Table of Contents

    Koha Development
        Koha 3.6.4 Released
        Koha 3.8 Status
        Koha 3.10 Roles
        Release Manager?s Newsletter
        Koha Statistics
    Koha Community
        New Koha Libraries
        Community Gossip
        New Zealand Meeting Call
        Meeting Logs
    Past Koha Events
        Marseille Hackfest
        March General IRC Meeting
        Global Bug Squashing Week
    Upcoming Koha Events
        April General IRC Meeting
        KohaCon12

Koha Development

Koha 3.6.4 Released
by Chris Nighswonger

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

The package can be retrieved from:

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

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

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

Release notes for 3.6.4 are at http://koha-community.org/koha-3-6-4.

Koha 3.8 Status

Koha 3.8.0 is scheduled to be released on 23 April 2012.

As of 26 March, 3.8 is in a feature freeze.

Paul Poulain, Koha 3.8 Release Manager, has posted a roadmap to 3.8.

Koha 3.10 Roles
by MJ Ray

With the release of Koha 3.8.0 scheduled for 23 April 2012, it?s time
to start thinking about roles for the 3.10 series.

We would like volunteers for:

    Release Manager
    Translation Manager
    Documentation Manager
    Database Documentation Manager
    Quality Assurance (QA) Manager
    Assistant QA Managers
    Specific Module maintainers
    Release Maintainers
    Packaging Manager (and grasshopper)
    Bug Wranglers (the more the merrier!)
    Meeting chair

Anyone who wants take on any of these roles is more than welcome to
write their name next to one on the Roles for 3.10 wiki page and
perhaps link to their proposal.

The community will vote on these during the April General IRC meeting,
4 April 2012 at 10:00 UTC +0000, straight after the release news.

Please, consider stepping forwards to help lead Koha?s development.

Release Manager?s Newsletter

Paul Poulain, Koha 3.8 Release Manager, is publishing a monthly
newsletter dedicated to Koha 3.8 development. It can be found on the
Koha Community website in the Koha News category. The fourth issue is
here.

Koha Statistics

Chris Cormack, statistician par excellence, has posted some recent
stats on Koha:

February bug/enhancement statistics
Statistics for Koha 3.6.4
Koha Community

New Koha Libraries

    Columbia County Rural Library District (via ByWater Solutions)
    Kalamaria Public Library (Thessaloniki, Greece) (via Union Catalog
of Academic Libraries)
    Plum Creek Library System (via ByWater Solutions)
    Southern NH Library Cooperative (via ByWater Solutions)
    Walla Walla Public Library (via ByWater Solutions)
    Washoe County Library System (via ByWater Solutions)
    Wilderness Coast Public Libraries (via ByWater Solutions)

Community Gossip

Marc Balmer reports that he has integrated the proprietary arcapos
point of sale system with Koha using the SIP protocol. This
combination enables the sale of items in the library with seamless
integration of fee processing and payment. More info is here.

Stefano Bargioni has developed a Perl script to generate authority
records from bibliographic records, which would be useful for
migrating data to Koha from an ILS that lacks authority records. You
can download the script and get more info here. Stefano would
appreciate help with replacing XML::Simple with YAML::Sick and with
preparing config files for non-MARC21.

Mysore University Library has implemented a mobile version of their Koha opac.

Kristina D.C. Hoeppner posted to her blog an account of her
introduction to squashing bugs during Global Bug Squashing Week.

Vimal Kumar V. has posted a survey to measure adoption and user
perceptions of potential Koha users in India.

Chris Cormack tweeted that by upgrading to Koha version 3.6.4,
Horowhenua Library Trust, the New Zealand library that sponsored the
original development of Koha, is now running a version of Koha
containing a contribution by the 14-year-old son of the Trust?s Head
of Libraries, Joann Ransom. Chris added that when the original Koha
first went live, it also contained a contribution by the son of the
Head of Libraries at that time.

Chris has also posted info on using Koha with citation managers
Zotero, Endnote, and RefWorks.

New Zealand Meeting Call
by Hannah Benbow

We?re keen for another Koha users group meeting here in New Zealand.
If you?d be interested in coming along, let me know so we can get an
idea of interest. Contact me on: +64 4 917 6103 or email
Hannah.benbow at treasury.govt.nz.

I?ve heard really great things about the last meeting hosted by the
Horowhenua Library Trust and would be keen for something similar?an
opportunity for users to talk about how to get the best out of Koha
and to share their knowledge and ideas.

If there?s enough interest for this to proceed, the Central Agencies
Shared Services Information Management team would be happy to host it
here at Treasury.

Meeting Logs
by Galen Charlton

Minutes and logs of community meetings that are recorded by MeetBot
can now be found at http://meetings.koha-community.org/. I?ve updated
all links to meeting minutes on the wiki and instituted a redirect
from the previous URL base. I ask any webmasters who link to meeting
logs to update their links accordingly.
Past Koha Events

Marseille Hackfest

Paul Poulain has posted an extensive report on the Hackfest that took
place in Marseille from 19-25 March.

Ga?tan Boisson posted an earlier report.

March General IRC Meeting

The March general IRC meeting was held on 21 March 2012.

More info, including the agenda and links to the minutes, is here.

Global Bug Squashing Week 2012-03-19
by Magnus Enger

Global bug squashing days are days designated to a concerted effort to
get bugs and patches moving along in the right direction. A global bug
squashing week is 5 global bug squashing days in a row. ;-)

The week of 19-23 March 2012 was a global bug squashing week,
coinciding with the Marseille Hackfest. More info is here.
Upcoming Koha Events

April General IRC Meeting

The April general IRC meeting will be held on Wednesday, 4 April 2012.

More info is here.

KohaCon12

KohaCon12 will be held in Edinburgh, Scotland, UK, 5-7 June 2012. A
hackfest will be held 9-11 June.

This is a free conference for everyone interested in the Koha library
system, which is Free and Open Source Software. There is no
registration fee, but we will ask that attendees pre-register. Further
calls, including calls for papers and registrations will be posted
soon.

Details (travel, hotels, agenda draft, etc) can be found linked from here.

KohaCon12 is the fifth KohaCon, following last year?s successful
conference in India which brought together users and developers
worldwide. KohaCon12 will feature an international slate of speakers
(both Koha users and active Koha contributors) conducting
presentations and workshops on a diverse range of topics. Talks will
cover a range of topics from general experiences of Koha through to
technical information on the various modules.

?We expect this event to have wide appeal,? said MJ Ray of host
organisation and Koha support provider software.coop. ?The conference
is for both techies and non-techies. In addition to presentations on
the technical side of Koha, the conference will be a demonstration of
how users and developers around the world cooperate to improve Free
and Open Source Software. software.coop is delighted to host KohaCon
in Edinburgh in our tenth anniversary year and this UN International
Year of Co-operatives.?

?Koha conferences are always an informative and uplifting event, I
have no doubt that this years conference in Edinburgh will be the best
conference yet.? said Chris Cormack, one of the original authors of
the Koha version 1.0.

From robin at catalyst.net.nz  Wed Mar 28 00:36:42 2012
From: robin at catalyst.net.nz (Robin Sheat)
Date: Wed, 28 Mar 2012 11:36:42 +1300
Subject: [Koha-devel] [Koha-patches] [PATCH] Bug 6701 - login timeout is
	in seconds
In-Reply-To: <1332854445-25242-1-git-send-email-dpavlin@rot13.org>
References: <1332854445-25242-1-git-send-email-dpavlin@rot13.org>
Message-ID: <1332887802.31791.14.camel@zarathud>

Dobrica Pavlinusic schreef op di 27-03-2012 om 15:20 [+0200]:
> +            - seconds of inactivity. Adding d will specify it in
> days, e.g. 1D is timeout of one day.

'd' or 'D'? Perhaps good to be consistent :)

(I spent a few days recently battling with an API because it turned out
the docs had used both 'ca' and 'CA', and only one was right. I picked
the wrong one.)

-- 
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/20120328/53e46115/attachment.pgp>

From dpavlin at rot13.org  Wed Mar 28 10:25:16 2012
From: dpavlin at rot13.org (Dobrica Pavlinusic)
Date: Wed, 28 Mar 2012 10:25:16 +0200
Subject: [Koha-devel] [Koha-patches] [PATCH] Bug 6701 - login timeout is
	in seconds
In-Reply-To: <1332887802.31791.14.camel@zarathud>
References: <1332854445-25242-1-git-send-email-dpavlin@rot13.org>
	<1332887802.31791.14.camel@zarathud>
Message-ID: <20120328082516.GA3203@rot13.org>

On Wed, Mar 28, 2012 at 11:36:42AM +1300, Robin Sheat wrote:
> Dobrica Pavlinusic schreef op di 27-03-2012 om 15:20 [+0200]:
> > +            - seconds of inactivity. Adding d will specify it in
> > days, e.g. 1D is timeout of one day.
> 
> 'd' or 'D'? Perhaps good to be consistent :)

Both upper and lowercase is supported since regex is (\d+)[dD] so I
wrote one in exmplainanation and another in example.

Do you have better phrase for this change since I'm not a native
speaker?

-- 
Dobrica Pavlinusic               2share!2flame            dpavlin at rot13.org
Unix addict. Internet consultant.             http://www.rot13.org/~dpavlin

From robin at catalyst.net.nz  Wed Mar 28 10:33:17 2012
From: robin at catalyst.net.nz (Robin Sheat)
Date: Wed, 28 Mar 2012 21:33:17 +1300
Subject: [Koha-devel] [Koha-patches] [PATCH] Bug 6701 - login timeout is
	in seconds
In-Reply-To: <20120328082516.GA3203@rot13.org>
References: <1332854445-25242-1-git-send-email-dpavlin@rot13.org>
	<1332887802.31791.14.camel@zarathud>
	<20120328082516.GA3203@rot13.org>
Message-ID: <4F72CCCD.8070608@catalyst.net.nz>

Op 28-03-12 21:25, Dobrica Pavlinusic schreef:
> Both upper and lowercase is supported since regex is (\d+)[dD] so I
> wrote one in exmplainanation and another in example.

It'll still confuse people, trust me :)

> Do you have better phrase for this change since I'm not a native
> speaker?

I'd just pick one and make them the same. That it'll work both ways can
be a pleasant surprise for them :)

Robin.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: </pipermail/koha-devel/attachments/20120328/9428c17a/attachment.pgp>

From serhijdubyk at gmail.com  Wed Mar 28 12:11:54 2012
From: serhijdubyk at gmail.com (=?UTF-8?B?0KHQtdGA0LPRltC5INCU0YPQsdC40Lo=?=)
Date: Wed, 28 Mar 2012 13:11:54 +0300
Subject: [Koha-devel] How to view Zebra indexes..?
Message-ID: <CAD_i8vtdWz=1fMaqj=-Kwz3-bf2FKFjjfpj4G=g8_nRBWc_ZmQ@mail.gmail.com>

Hi all!

Koha Wiki has an page
Understanding Zebra indexing
(http://wiki.koha-community.org/wiki/Understanding_Zebra_indexing)
about adding fileds/subfields to seach indexes.

In particular are indices for the some case:

Name-and-title = {"Goddard College"}
Name = {"Faculty publications"}
Subject = {"Faculty publications"}
Subject:p = {"Faculty publications"}
Corporate-name = {"Faculty publications"}

General question: how to see the generated indexes for a specific record?

...
For my case, I try to build the correct indexes for call numbers, UDC,
Dewey, BBK codes etc.
For ex. we have callnum = 222.12/4
I need a searches like next:
22*            - 223.14/1, 224.1/2 ...
222*          - all indexes start from 222 - 222.11/1, 222.12/2 ...
222.12*     - in result I need only 222.12/1, 222.12/2, 222.12/3 ...
During formation of index - point, space, parentheses or other mark
should not break the index into pieces.

From koha.sekjal at gmail.com  Wed Mar 28 21:59:04 2012
From: koha.sekjal at gmail.com (Ian Walls)
Date: Wed, 28 Mar 2012 15:59:04 -0400
Subject: [Koha-devel] [Koha] Call for Nominations: Roles for 3.10
In-Reply-To: <E1SARPE-00080k-Ie@petrol.towers.org.uk>
References: <E1SARPE-00080k-Ie@petrol.towers.org.uk>
Message-ID: <CANL=k+FT67mTNpBVkNB7NBpjv+xq2YE1CA17qxua7norOwVYSQ@mail.gmail.com>

Just a bump... we still need a Translation Manager (someone with a
non-English first language preferred), and specific module maintainers.
More bug wranglers are always welcome, too!

We have single candidates for the other single-person positions, which will
make the voting quite... limited.  Anyone interested in running for
Documentation Manager, Quality Assurance Manager or Release Manager should
add their names before next Wednesday, April 4, 2012.  A brief description
of your goals, philosophy or platform would be appreciated; we already know
what our incumbent candidates are planning to do.

Cheers,


-Ian


He aha te mea nui o te ao?
He tangata!
He tangata!
He tangata!

On Wed, Mar 21, 2012 at 15:41, MJ Ray <mjr at phonecoop.coop> wrote:

> With the release of Koha 3.8.0 scheduled for 23 April 2012, it's time
> to start thinking about roles for the 3.10 series.
>
> We would like volunteers for:
>
>    * Release Manager
>    * Translation Manager
>    * Documentation Manager
>    * Database Documentation Manager
>    * Quality Assurance (QA) Manager
>    * Assistant QA Managers
>    * Specific Module maintainers
>    * Release Maintainers
>    * Packaging Manager (and grasshopper)
>    * Bug Wranglers (the more the merrier!)
>    * Meeting chair
>
> Anyone who wants take on any of these roles is more than welcome to
> write their name next to one on
> http://wiki.koha-community.org/wiki/Roles_for_3.10 and perhaps link to
> their proposal.
>
> The community will vote on these during the General IRC meeting
> http://wiki.koha-community.org/wiki/General_IRC_meeting,_4_April_2012
> 4 April 2012 at 10:00 UTC +0000, straight after the release news.
>
> Please, consider stepping forwards to help lead Koha's development.
>
> Regards,
> --
> MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
> http://koha-community.org supporter, web and library systems developer.
> In My Opinion Only: see http://mjr.towers.org.uk/email.html
> Available for hire (including development) at http://www.software.coop/
> _______________________________________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120328/5464464f/attachment.htm>

From abesottedphoenix at yahoo.com  Wed Mar 28 22:10:19 2012
From: abesottedphoenix at yahoo.com (BWS Johnson)
Date: Wed, 28 Mar 2012 13:10:19 -0700 (PDT)
Subject: [Koha-devel] [Koha] Call for Nominations: Roles for 3.10
In-Reply-To: <CANL=k+FT67mTNpBVkNB7NBpjv+xq2YE1CA17qxua7norOwVYSQ@mail.gmail.com>
References: <E1SARPE-00080k-Ie@petrol.towers.org.uk>
	<CANL=k+FT67mTNpBVkNB7NBpjv+xq2YE1CA17qxua7norOwVYSQ@mail.gmail.com>
Message-ID: <1332965419.19935.YahooMailNeo@web114703.mail.gq1.yahoo.com>

Tena Koutou!


> Just a bump... we still need a Translation Manager (someone with a
> non-English first language preferred), and specific module maintainers.
> More bug wranglers are always welcome, too!
> 

??? *cough* Marjiana or Dorbica *cough*


> He aha te mea nui o te ao?
> He tangata!
> He tangata!
> He tangata!


??? Niyayo. :D

Cheers,
Brooke

From M.de.Rooy at rijksmuseum.nl  Thu Mar 29 08:49:53 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 29 Mar 2012 06:49:53 +0000
Subject: [Koha-devel] Call for Nominations: Roles for 3.10
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310DF13DA8@S-MAIL-1B.rijksmuseum.intra>

Did not even know that I was incumbent ;)
I was looking on the wiki for a description of module maintainer, but could not find it.
What should we expect from a module maintainer? (Anyone can have an idea about it, but we did not make that explicit.) How does (s)he fit in the work flow from sign-off to push ?
Should we also look at the default assignees and default cc?s in Bugzilla per category (a related topic, I suppose) ?

Marcel

Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Ian Walls
Verzonden: woensdag 28 maart 2012 21:59
Aan: koha at lists.katipo.co.nz; koha-devel at lists.koha-community.org
Onderwerp: Re: [Koha-devel] [Koha] Call for Nominations: Roles for 3.10

Just a bump... we still need a Translation Manager (someone with a non-English first language preferred), and specific module maintainers.  More bug wranglers are always welcome, too!

We have single candidates for the other single-person positions, which will make the voting quite... limited.  Anyone interested in running for Documentation Manager, Quality Assurance Manager or Release Manager should add their names before next Wednesday, April 4, 2012.  A brief description of your goals, philosophy or platform would be appreciated; we already know what our incumbent candidates are planning to do.

Cheers,


-Ian


He aha te mea nui o te ao?
He tangata!
He tangata!
He tangata!
On Wed, Mar 21, 2012 at 15:41, MJ Ray <mjr at phonecoop.coop<mailto:mjr at phonecoop.coop>> wrote:
With the release of Koha 3.8.0 scheduled for 23 April 2012, it's time
to start thinking about roles for the 3.10 series.

We would like volunteers for:

   * Release Manager
   * Translation Manager
   * Documentation Manager
   * Database Documentation Manager
   * Quality Assurance (QA) Manager
   * Assistant QA Managers
   * Specific Module maintainers
   * Release Maintainers
   * Packaging Manager (and grasshopper)
   * Bug Wranglers (the more the merrier!)
   * Meeting chair

Anyone who wants take on any of these roles is more than welcome to
write their name next to one on
http://wiki.koha-community.org/wiki/Roles_for_3.10 and perhaps link to
their proposal.

The community will vote on these during the General IRC meeting
http://wiki.koha-community.org/wiki/General_IRC_meeting,_4_April_2012
4 April 2012 at 10:00 UTC +0000, straight after the release news.

Please, consider stepping forwards to help lead Koha's development.

Regards,
--
MJ Ray (slef), member of www.software.coop<http://www.software.coop>, a for-more-than-profit co-op.
http://koha-community.org supporter, web and library systems developer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire (including development) at http://www.software.coop/
_______________________________________________
Koha mailing list  http://koha-community.org
Koha at lists.katipo.co.nz<mailto:Koha at lists.katipo.co.nz>
http://lists.katipo.co.nz/mailman/listinfo/koha

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

From samuel.desseaux at ecp.fr  Thu Mar 29 10:24:48 2012
From: samuel.desseaux at ecp.fr (Samuel desseaux)
Date: Thu, 29 Mar 2012 10:24:48 +0200
Subject: [Koha-devel] Call for Nominations: Roles for 3.10
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310DF13DA8@S-MAIL-1B.rijksmuseum.intra>
References: <809BE39CD64BFD4EB9036172EBCCFA310DF13DA8@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <4F741C50.3010607@ecp.fr>

Hi!

I've just added my name on the wiki for the translation manager. In the 
past, i've been involved in other translation project (kde)and i wanted 
to be now more involved in koha.

Cheers

Samuel

PS: i think too it would be a good idea  to add a description for each 
position.



Le 29/03/2012 08:49, Marcel de Rooy a ?crit :
>
> Did not even know that I was incumbent ;)
>
> I was looking on the wiki for a description of module maintainer, but 
> could not find it.
>
> What should we expect from a module maintainer? (Anyone can have an 
> idea about it, but we did not make that explicit.) How does (s)he fit 
> in the work flow from sign-off to push ?
>
> Should we also look at the default assignees and default cc?s in 
> Bugzilla per category (a related topic, I suppose) ?
>
> Marcel
>
> *Van:* koha-devel-bounces at lists.koha-community.org 
> [mailto:koha-devel-bounces at lists.koha-community.org] *Namens *Ian Walls
> *Verzonden:* woensdag 28 maart 2012 21:59
> *Aan:* koha at lists.katipo.co.nz; koha-devel at lists.koha-community.org
> *Onderwerp:* Re: [Koha-devel] [Koha] Call for Nominations: Roles for 3.10
>
> Just a bump... we still need a Translation Manager (someone with a 
> non-English first language preferred), and specific module 
> maintainers.  More bug wranglers are always welcome, too!
>
> We have single candidates for the other single-person positions, which 
> will make the voting quite... limited.  Anyone interested in running 
> for Documentation Manager, Quality Assurance Manager or Release 
> Manager should add their names before next Wednesday, April 4, 2012.  
> A brief description of your goals, philosophy or platform would be 
> appreciated; we already know what our incumbent candidates are 
> planning to do.
>
> Cheers,
>
>
> -Ian
>
>
> He aha te mea nui o te ao?
> He tangata!
> He tangata!
> He tangata!
>
> On Wed, Mar 21, 2012 at 15:41, MJ Ray <mjr at phonecoop.coop 
> <mailto:mjr at phonecoop.coop>> wrote:
>
> With the release of Koha 3.8.0 scheduled for 23 April 2012, it's time
> to start thinking about roles for the 3.10 series.
>
> We would like volunteers for:
>
>    * Release Manager
>    * Translation Manager
>    * Documentation Manager
>    * Database Documentation Manager
>    * Quality Assurance (QA) Manager
>    * Assistant QA Managers
>    * Specific Module maintainers
>    * Release Maintainers
>    * Packaging Manager (and grasshopper)
>    * Bug Wranglers (the more the merrier!)
>    * Meeting chair
>
> Anyone who wants take on any of these roles is more than welcome to
> write their name next to one on
> http://wiki.koha-community.org/wiki/Roles_for_3.10 and perhaps link to
> their proposal.
>
> The community will vote on these during the General IRC meeting
> http://wiki.koha-community.org/wiki/General_IRC_meeting,_4_April_2012
> 4 April 2012 at 10:00 UTC +0000, straight after the release news.
>
> Please, consider stepping forwards to help lead Koha's development.
>
> Regards,
> --
> MJ Ray (slef), member of www.software.coop <http://www.software.coop>, 
> a for-more-than-profit co-op.
> http://koha-community.org supporter, web and library systems developer.
> In My Opinion Only: see http://mjr.towers.org.uk/email.html
> Available for hire (including development) at http://www.software.coop/
> _______________________________________________
> Koha mailing list http://koha-community.org
> Koha at lists.katipo.co.nz <mailto:Koha at lists.katipo.co.nz>
> http://lists.katipo.co.nz/mailman/listinfo/koha
>
>
> _______________________________________________
> 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/20120329/11a476af/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: samuel_desseaux.vcf
Type: text/x-vcard
Size: 340 bytes
Desc: not available
URL: </pipermail/koha-devel/attachments/20120329/11a476af/attachment.vcf>

From M.de.Rooy at rijksmuseum.nl  Thu Mar 29 10:28:37 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 29 Mar 2012 08:28:37 +0000
Subject: [Koha-devel] Call for Nominations: Roles for 3.10
In-Reply-To: <4F741C50.3010607@ecp.fr>
References: <809BE39CD64BFD4EB9036172EBCCFA310DF13DA8@S-MAIL-1B.rijksmuseum.intra>
	<4F741C50.3010607@ecp.fr>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310DF13E36@S-MAIL-1B.rijksmuseum.intra>

Great !

Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Samuel desseaux
Verzonden: donderdag 29 maart 2012 10:25
Aan: koha-devel at lists.koha-community.org
Onderwerp: Re: [Koha-devel] Call for Nominations: Roles for 3.10

Hi!

I've just added my name on the wiki for the translation manager. In the past, i've been involved in other translation project (kde)and i wanted to be now more involved in koha.

Cheers

Samuel

PS: i think too it would be a good idea  to add a description for each position.



Le 29/03/2012 08:49, Marcel de Rooy a ?crit :
Did not even know that I was incumbent ;)
I was looking on the wiki for a description of module maintainer, but could not find it.
What should we expect from a module maintainer? (Anyone can have an idea about it, but we did not make that explicit.) How does (s)he fit in the work flow from sign-off to push ?
Should we also look at the default assignees and default cc?s in Bugzilla per category (a related topic, I suppose) ?

Marcel

Van: koha-devel-bounces at lists.koha-community.org<mailto:koha-devel-bounces at lists.koha-community.org> [mailto:koha-devel-bounces at lists.koha-community.org] Namens Ian Walls
Verzonden: woensdag 28 maart 2012 21:59
Aan: koha at lists.katipo.co.nz<mailto:koha at lists.katipo.co.nz>; koha-devel at lists.koha-community.org<mailto:koha-devel at lists.koha-community.org>
Onderwerp: Re: [Koha-devel] [Koha] Call for Nominations: Roles for 3.10

Just a bump... we still need a Translation Manager (someone with a non-English first language preferred), and specific module maintainers.  More bug wranglers are always welcome, too!

We have single candidates for the other single-person positions, which will make the voting quite... limited.  Anyone interested in running for Documentation Manager, Quality Assurance Manager or Release Manager should add their names before next Wednesday, April 4, 2012.  A brief description of your goals, philosophy or platform would be appreciated; we already know what our incumbent candidates are planning to do.

Cheers,


-Ian


He aha te mea nui o te ao?
He tangata!
He tangata!
He tangata!
On Wed, Mar 21, 2012 at 15:41, MJ Ray <mjr at phonecoop.coop<mailto:mjr at phonecoop.coop>> wrote:
With the release of Koha 3.8.0 scheduled for 23 April 2012, it's time
to start thinking about roles for the 3.10 series.

We would like volunteers for:

   * Release Manager
   * Translation Manager
   * Documentation Manager
   * Database Documentation Manager
   * Quality Assurance (QA) Manager
   * Assistant QA Managers
   * Specific Module maintainers
   * Release Maintainers
   * Packaging Manager (and grasshopper)
   * Bug Wranglers (the more the merrier!)
   * Meeting chair

Anyone who wants take on any of these roles is more than welcome to
write their name next to one on
http://wiki.koha-community.org/wiki/Roles_for_3.10 and perhaps link to
their proposal.

The community will vote on these during the General IRC meeting
http://wiki.koha-community.org/wiki/General_IRC_meeting,_4_April_2012
4 April 2012 at 10:00 UTC +0000, straight after the release news.

Please, consider stepping forwards to help lead Koha's development.

Regards,
--
MJ Ray (slef), member of www.software.coop<http://www.software.coop>, a for-more-than-profit co-op.
http://koha-community.org supporter, web and library systems developer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire (including development) at http://www.software.coop/
_______________________________________________
Koha mailing list  http://koha-community.org
Koha at lists.katipo.co.nz<mailto:Koha at lists.katipo.co.nz>
http://lists.katipo.co.nz/mailman/listinfo/koha






_______________________________________________

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/20120329/6f7e9ae1/attachment-0001.htm>

From chris at bigballofwax.co.nz  Thu Mar 29 10:37:21 2012
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Thu, 29 Mar 2012 21:37:21 +1300
Subject: [Koha-devel] Call for Nominations: Roles for 3.10
In-Reply-To: <4F741C50.3010607@ecp.fr>
References: <809BE39CD64BFD4EB9036172EBCCFA310DF13DA8@S-MAIL-1B.rijksmuseum.intra>
	<4F741C50.3010607@ecp.fr>
Message-ID: <CA+95qVSuR=b33Jua2Tt09BwGnk2uS1N1CvYHc4DDN7ihGa4Odg@mail.gmail.com>

2012/3/29 Samuel desseaux <samuel.desseaux at ecp.fr>:
> Hi!
>
> I've just added my name on the wiki for the translation manager. In the
> past, i've been involved in other translation project (kde)and i wanted to
> be now more involved in koha.
>
> Cheers
>
> Samuel
>
> PS: i think too it would be a good idea? to add a description for each
> position.
>
Hi Samuel

This might help you
http://wiki.koha-community.org/wiki/Translation_Manager_for_3.4_Proposal

Chris

From sandeep.bhavsar at gmail.com  Thu Mar 29 11:06:25 2012
From: sandeep.bhavsar at gmail.com (SANDEEP BHAVSAR)
Date: Thu, 29 Mar 2012 14:36:25 +0530
Subject: [Koha-devel] Survey : Use and Applications of Open Source Software
	in Libraries
Message-ID: <CA+3iuR7V8SvbmVW0dB9b2JuKPgYWET6Cq=YAQeSZdYQS_GKRzw@mail.gmail.com>

Respected All,


I am pursuing my  Ph.D and working on dissertation entitled ?Use and
Applications of Open Source Software in Libraries.?


I would like to invite you to participate in Survey which will take about
5-10 minutes to complete. All data entered will be kept confidential,
strictly protected and only be used for this research.


To participate in the survey please visit *http://tinyurl.com/bqepbd6*


Please feel free to share above link to your colleagues in your Institute /
Company which will help me to get good response.


Thank you in advance for your time and contribution. Looking forward to a
good response.

-- 
Thanks and Regards

Sandeep Bhavsar
Librarian
Dr.V.N.Bedekar Institute of Management Studies
Thane(W) 400601
MUMBAI. INDIA
@@@@@@@@@@@@@@@@@@@@@@@@@@
email    : sandeep.bhavsar at gmail.com
Mob     : 9029 345777
elibrary :http://www.vpmthane.org/im/elib/main.htm
@@@@@@@@@@@@@@@@@@@@@@@@@@

-- 
Thanks and Regards

Sandeep Bhavsar
Librarian
Dr.V.N.Bedekar Institute of Management Studies
Thane(W) 400601
MUMBAI. INDIA
@@@@@@@@@@@@@@@@@@@@@@@@@@
email    : sandeep.bhavsar at gmail.com
Mob     : 9029 345777
elibrary :http://www.vpmthane.org/im/elib/main.htm
@@@@@@@@@@@@@@@@@@@@@@@@@@
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120329/05286dd2/attachment.htm>

From bob at calyx.net.au  Thu Mar 29 13:07:50 2012
From: bob at calyx.net.au (Bob Birchall)
Date: Thu, 29 Mar 2012 22:07:50 +1100
Subject: [Koha-devel] Survey : Use and Applications of Open Source
 Software in Libraries
In-Reply-To: <CA+3iuR7V8SvbmVW0dB9b2JuKPgYWET6Cq=YAQeSZdYQS_GKRzw@mail.gmail.com>
References: <CA+3iuR7V8SvbmVW0dB9b2JuKPgYWET6Cq=YAQeSZdYQS_GKRzw@mail.gmail.com>
Message-ID: <4F744286.5000800@calyx.net.au>

On 29/03/12 20:06, SANDEEP BHAVSAR wrote:
>
> Respected All,
>
>
> I am pursuing my  Ph.D and working on dissertation entitled ?Use and 
> Applications of Open Source Software in Libraries.?
>
>
> I would like to invite you to participate in Survey which will take 
> about 5-10 minutes to complete. All data entered will be kept 
> confidential, strictly protected and only be used for this research.
>
>
> To participate in the survey please visit *http://tinyurl.com/bqepbd6*
>
>
> Please feel free to share above link to your colleagues in your 
> Institute / Company which will help me to get good response.
>
>
> Thank you in advance for your time and contribution. Looking forward 
> to a good response.
>
>
Sandeep was one of our hosts at KohaCon11 in Thane.  If anyone can help 
him by completing the survey, I'm sure it will be appreciated.
Thanks,
Bob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120329/5a9af523/attachment.htm>

From joseanjos at gmail.com  Wed Mar 28 12:33:10 2012
From: joseanjos at gmail.com (anjoze)
Date: Wed, 28 Mar 2012 03:33:10 -0700 (PDT)
Subject: [Koha-devel] How to view Zebra indexes..?
In-Reply-To: <CAD_i8vtdWz=1fMaqj=-Kwz3-bf2FKFjjfpj4G=g8_nRBWc_ZmQ@mail.gmail.com>
References: <CAD_i8vtdWz=1fMaqj=-Kwz3-bf2FKFjjfpj4G=g8_nRBWc_ZmQ@mail.gmail.com>
Message-ID: <1332930790229-5600051.post@n5.nabble.com>

I think this will help:
http://www.len.ro/work/koha-search-2/

--
View this message in context: http://koha.1045719.n5.nabble.com/How-to-view-Zebra-indexes-tp5600020p5600051.html
Sent from the Koha-devel mailing list archive at Nabble.com.

From frederic at tamil.fr  Thu Mar 29 14:45:04 2012
From: frederic at tamil.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Demians?=)
Date: Thu, 29 Mar 2012 14:45:04 +0200
Subject: [Koha-devel] Call for Nominations: Roles for 3.10
In-Reply-To: <4F741C50.3010607@ecp.fr>
References: <809BE39CD64BFD4EB9036172EBCCFA310DF13DA8@S-MAIL-1B.rijksmuseum.intra>
	<4F741C50.3010607@ecp.fr>
Message-ID: <4F745950.5070304@tamil.fr>

 > I've just added my name on the wiki for the translation manager. In
 > the past, i've been involved in other translation project (kde)and i
 > wanted to be now more involved in koha.

As translation manager, you would have at minimum:

   - to provide and administer a Pootle server, preferably a dedicated
     server
   - to deal with translators demands/questions
   - to manage a git repository on which pushing translation files for
     Release Maintainers


-- 
Fr?d?ric DEMIANS
http://www.tamil.fr/u/fdemians.html

From mtj at kohaaloha.com  Fri Mar 30 00:28:26 2012
From: mtj at kohaaloha.com (Mason James)
Date: Fri, 30 Mar 2012 11:28:26 +1300
Subject: [Koha-devel] [Koha] Koha Support provider
In-Reply-To: <FFAAA113-3B70-4F1A-9A66-6B8F74AC889A@keep.pt>
References: <FFAAA113-3B70-4F1A-9A66-6B8F74AC889A@keep.pt>
Message-ID: <D4BC8AE3-36D3-44A3-81AC-943DCD3235E9@kohaaloha.com>

forwarding to developers list...


On 2012-03-30, at 9:51 AM, Miguel Ferreira wrote:

> Dear Koha developers,
> 
> My name is Miguel Ferreira and I represent a Portuguese company called KEEP SOLUTIONS that offers services to institutions that want to adopt Koha in their libraries. For over 1.5 years we have been working actively in implementing Koha in higher education institutions, translating it into portuguese, fixing bugs and developing minor enhancements.
> 
> We would like to get listed as a Koha Support provider
> 
> For more information on our company and services please consult - http://www.keep.pt/en/node/186
> 
> --
> Company Name: KEEP SOLUTIONS, LDA.
> Contact Person: Miguel Ferreira
> Contact email: info at keep.pt
> Website: http://www.keep.pt
> Telephone: +351 253066735
> Address:
> KEEP SOLUTIONS, LDA.
> Rua Rosalvo de Almeida, n? 5
> 4710-429 Braga, Portugal
> 
> Short description of services:
> 
> Installation, maintenance and support
> This service aims to ensure the proper operation of the solution during the whole period of the maintenance contract. The service includes the implementation of Koha with custom design, installation of add-ons, hosting of application servers with SLA and helpdesk.
> 
> Data migration
> The migration service includes data extraction, processing and importing of information (e.g. catalogue, authority records, user information, etc.). from other library management systems.
> 
> Systems integration
> This service includes the integration of Koha with current systems available at the institution, e.g. acquisitions management software, user management systems (e.g. LDAP and others), chat-based helpdesk systems, invoicing systems, etc.
> 
> Training
> KEEP SOLUTIONS offers a training course entitled "Koha - training course for managers and librarians." The course has a duration of 6 hours and aims to enable trainees to efficiently operate and manage the Koha software.
> 
> --
> 
> Thank you for your concern.
> 
> Best regards,
> Miguel Ferreira
> 
> - -
> Head of R&D
> KEEP SOLUTIONS, LDA.
> Rua Rosalvo de Almeida, n? 5
> 4710-429 Braga, Portugal
> W www.keep.pt E info at keep.pt 
> T +351 253066735 F +351 253067248
> 
> _______________________________________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha


cheers, Mason
-- 
KohaAloha, NZ

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20120330/c79c9d2f/attachment.pgp>

From dpavlin at gmail.com  Fri Mar 30 01:02:21 2012
From: dpavlin at gmail.com (=?ISO-8859-2?Q?Dobrica_Pavlinu=B9i=E6?=)
Date: Fri, 30 Mar 2012 01:02:21 +0200
Subject: [Koha-devel] [Koha] Call for Nominations: Roles for 3.10
In-Reply-To: <1332965419.19935.YahooMailNeo@web114703.mail.gq1.yahoo.com>
References: <E1SARPE-00080k-Ie@petrol.towers.org.uk>
	<CANL=k+FT67mTNpBVkNB7NBpjv+xq2YE1CA17qxua7norOwVYSQ@mail.gmail.com>
	<1332965419.19935.YahooMailNeo@web114703.mail.gq1.yahoo.com>
Message-ID: <CAEhPeBDfT2OZhhHhgLUVsXibxu+0ZY7P25MRbBM9V7x4Tc-G=w@mail.gmail.com>

On Wed, Mar 28, 2012 at 22:10, BWS Johnson <abesottedphoenix at yahoo.com> wrote:
> ??? *cough* Marjiana or Dorbica *cough*

I signed up as bug wrangler for plack, localization, UTF-8, profiling, speedups.

I would also love to help PostgreSQL efforts during 3.10 cycle.

-- 
?...2share!2flame... http://blog.rot13.org

From marc at msys.ch  Fri Mar 30 08:37:47 2012
From: marc at msys.ch (Marc Balmer)
Date: Fri, 30 Mar 2012 08:37:47 +0200
Subject: [Koha-devel] [Koha] Call for Nominations: Roles for 3.10
In-Reply-To: <CAEhPeBDfT2OZhhHhgLUVsXibxu+0ZY7P25MRbBM9V7x4Tc-G=w@mail.gmail.com>
References: <E1SARPE-00080k-Ie@petrol.towers.org.uk>
	<CANL=k+FT67mTNpBVkNB7NBpjv+xq2YE1CA17qxua7norOwVYSQ@mail.gmail.com>
	<1332965419.19935.YahooMailNeo@web114703.mail.gq1.yahoo.com>
	<CAEhPeBDfT2OZhhHhgLUVsXibxu+0ZY7P25MRbBM9V7x4Tc-G=w@mail.gmail.com>
Message-ID: <4F7554BB.1040802@msys.ch>

Am 30.03.2012 01:02, schrieb Dobrica Pavlinu?i?:
> On Wed, Mar 28, 2012 at 22:10, BWS Johnson<abesottedphoenix at yahoo.com>  wrote:
>>      *cough* Marjiana or Dorbica *cough*
>
> I signed up as bug wrangler for plack, localization, UTF-8, profiling, speedups.
>
> I would also love to help PostgreSQL efforts during 3.10 cycle.

Cool!  Help with making Koha run on PostgreSQL is really appreciated 
(and needed).

- Marc



From fridolyn.somers at gmail.com  Fri Mar 30 09:29:19 2012
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Fri, 30 Mar 2012 09:29:19 +0200
Subject: [Koha-devel] How to view Zebra indexes..?
In-Reply-To: <1332930790229-5600051.post@n5.nabble.com>
References: <CAD_i8vtdWz=1fMaqj=-Kwz3-bf2FKFjjfpj4G=g8_nRBWc_ZmQ@mail.gmail.com>
	<1332930790229-5600051.post@n5.nabble.com>
Message-ID: <CAN6cLAW4VDXanhk=bQV4JiPv4SJQuxh7msnOYK9SmF=C-6x9-g@mail.gmail.com>

I've worked on Koha indexing on 2 projects.
Unfortunatly, I couldn't manage to create a new index type (in addition to
word, phrase, date and number), wich is what you need to index differently
your call numbers.
It may be impossible.

To view indexes, you should use YAZ : http://www.indexdata.com/yaz
I only know it by name.

Good luke.
Regards,

On Wed, Mar 28, 2012 at 12:33 PM, anjoze <joseanjos at gmail.com> wrote:

> I think this will help:
> http://www.len.ro/work/koha-search-2/
>
> --
> View this message in context:
> http://koha.1045719.n5.nabble.com/How-to-view-Zebra-indexes-tp5600020p5600051.html
> Sent from the Koha-devel mailing list archive at Nabble.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/
>



-- 
Fridolyn SOMERS
fridolyn.somers at gmail.com
Marsillargues - France
 <fridolyn.somers at gmail.com>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20120330/14de60dc/attachment.htm>

From claire.hernandez at biblibre.com  Fri Mar 30 10:10:08 2012
From: claire.hernandez at biblibre.com (Claire Hernandez)
Date: Fri, 30 Mar 2012 10:10:08 +0200
Subject: [Koha-devel] performance issues with mysql and koha on 2 physical
	servers
Message-ID: <4F756A60.4010705@biblibre.com>

Hello all,

I would like to better understand why when we put koha source on a 
different mysql physical server we have a performance problems.

If I put mysql on koha source server, an opac-search take 2 times less 
than if I separate mysql server and koha sources.

I don't really know why:
- perl libs? (CGI + DBH?)
- mysql setting?
- network setting?

Do you know thinks about this? did you work or remember works from others ?

(I am really not comfortable with hardware architecture or server 
settings and first I would like to collect your feedbacks.)

Claire;

From marc at msys.ch  Fri Mar 30 10:19:54 2012
From: marc at msys.ch (Marc Balmer)
Date: Fri, 30 Mar 2012 10:19:54 +0200
Subject: [Koha-devel] performance issues with mysql and koha on 2
 physical servers
In-Reply-To: <4F756A60.4010705@biblibre.com>
References: <4F756A60.4010705@biblibre.com>
Message-ID: <4F756CAA.8050403@msys.ch>

Am 30.03.12 10:10, schrieb Claire Hernandez:
> Hello all,
> 
> I would like to better understand why when we put koha source on a
> different mysql physical server we have a performance problems.
> 
> If I put mysql on koha source server, an opac-search take 2 times less
> than if I separate mysql server and koha sources.
> 
> I don't really know why:
> - perl libs? (CGI + DBH?)
> - mysql setting?
> - network setting?
> 
> Do you know thinks about this? did you work or remember works from others ?
> 
> (I am really not comfortable with hardware architecture or server
> settings and first I would like to collect your feedbacks.)

When a server and client process are on the same machine, they can
communicate over a local socket (also called a Unix socket) which is a
lot faster than a TCP network socket which has to be used when the two
processes are on the same machine.

Careful tuning and refactoring of the SQL commands should minimize the
effect, though.  And when designed properly, a distributed application
can actually be a lot faster, but this depends on the design (the key is
that both parts, the DB and the application, can do some meaningful work
in parallel, which, of course, is not the case when the application
merely waits for the DB results).

-mb


From chrisc at catalyst.net.nz  Fri Mar 30 10:27:34 2012
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Fri, 30 Mar 2012 21:27:34 +1300
Subject: [Koha-devel] performance issues with mysql and koha on 2
 physical servers
In-Reply-To: <4F756A60.4010705@biblibre.com>
References: <4F756A60.4010705@biblibre.com>
Message-ID: <20120330082734.GH24879@rorohiko.wgtn.cat-it.co.nz>

* Claire Hernandez (claire.hernandez at biblibre.com) wrote:
> Hello all,
> 
> I would like to better understand why when we put koha source on a
> different mysql physical server we have a performance problems.
> 
> If I put mysql on koha source server, an opac-search take 2 times
> less than if I separate mysql server and koha sources.
> 
> I don't really know why:
> - perl libs? (CGI + DBH?)

Unlikely
> - mysql setting?

Possible, I would run mysqltuner on the database server and follow
its' suggestions.

> - network setting?

Also possible.

I would test for network latency, (often failing reverse dns can
introduce this) or simple packet loss.

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/20120330/af2f0598/attachment.pgp>

From chrisc at catalyst.net.nz  Fri Mar 30 10:30:49 2012
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Fri, 30 Mar 2012 21:30:49 +1300
Subject: [Koha-devel] performance issues with mysql and koha on 2
 physical servers
In-Reply-To: <4F756CAA.8050403@msys.ch>
References: <4F756A60.4010705@biblibre.com>
 <4F756CAA.8050403@msys.ch>
Message-ID: <20120330083049.GI24879@rorohiko.wgtn.cat-it.co.nz>

* Marc Balmer (marc at msys.ch) wrote:
> Am 30.03.12 10:10, schrieb Claire Hernandez:
> > Hello all,
> > 
> > I would like to better understand why when we put koha source on a
> > different mysql physical server we have a performance problems.
> > 
> > If I put mysql on koha source server, an opac-search take 2 times less
> > than if I separate mysql server and koha sources.
> > 
> > I don't really know why:
> > - perl libs? (CGI + DBH?)
> > - mysql setting?
> > - network setting?
> > 
> > Do you know thinks about this? did you work or remember works from others ?
> > 
> > (I am really not comfortable with hardware architecture or server
> > settings and first I would like to collect your feedbacks.)
> 
> When a server and client process are on the same machine, they can
> communicate over a local socket (also called a Unix socket) which is a
> lot faster than a TCP network socket which has to be used when the two
> processes are on the same machine.
> 
We run almost all our applications with dedicated database servers,
including our Koha servers, but those database servers are specced to
function fast as database machines. Quite a different profile to a web
server.

Is your database server at least as powerful if not more powerful than
the webserver?

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/20120330/40183135/attachment.pgp>

From bargioni at pusc.it  Fri Mar 30 11:07:51 2012
From: bargioni at pusc.it (Stefano Bargioni)
Date: Fri, 30 Mar 2012 11:07:51 +0200
Subject: [Koha-devel] How to view Zebra indexes..?
In-Reply-To: <mailman.2197.1333003502.15480.koha-devel@lists.koha-community.org>
References: <mailman.2197.1333003502.15480.koha-devel@lists.koha-community.org>
Message-ID: <C2E91965-F212-4E3D-8BFB-A5AEC4A5D09F@pusc.it>

Maybe the page
http://www.indexdata.com/zebra/doc/tutorial-oai-sru-zebra-indexes.html
can help you.
Bye. Stefano

> 
> From: ?????? ????? <serhijdubyk at gmail.com>
> Subject: [Koha-devel] How to view Zebra indexes..?
> To: koha-devel <koha-devel at lists.koha-community.org>
> Message-ID:
> 	<CAD_i8vtdWz=1fMaqj=-Kwz3-bf2FKFjjfpj4G=g8_nRBWc_ZmQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> Hi all!
> 
> Koha Wiki has an page
> Understanding Zebra indexing
> (http://wiki.koha-community.org/wiki/Understanding_Zebra_indexing)
> about adding fileds/subfields to seach indexes.
> 
> In particular are indices for the some case:
> 
> Name-and-title = {"Goddard College"}
> Name = {"Faculty publications"}
> Subject = {"Faculty publications"}
> Subject:p = {"Faculty publications"}
> Corporate-name = {"Faculty publications"}
> 
> General question: how to see the generated indexes for a specific record?
> 
> ...
> For my case, I try to build the correct indexes for call numbers, UDC,
> Dewey, BBK codes etc.
> For ex. we have callnum = 222.12/4
> I need a searches like next:
> 22*            - 223.14/1, 224.1/2 ...
> 222*          - all indexes start from 222 - 222.11/1, 222.12/2 ...
> 222.12*     - in result I need only 222.12/1, 222.12/2, 222.12/3 ...
> During formation of index - point, space, parentheses or other mark
> should not break the index into pieces.

From paul.poulain at biblibre.com  Fri Mar 30 16:56:36 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 30 Mar 2012 16:56:36 +0200
Subject: [Koha-devel] Hackfest12 in Marseille, photos
Message-ID: <4F75C9A4.1030106@biblibre.com>

Hello,
If you were with us at the hackfest, you will probably find pictures of
yourself at: https://depot.biblibre.com/ppoulain/hackfest12/

If you were not with us at the hackfest, you maybe interested too guess
who's who ;-)
(all names from left to right)
DSC03249.JPG: Katrin, Marijana, Owen, Adrien
DSC03252.JPG: Adrien, Julian, Sophie
DSC03253.JPG: Matts, Alex
DSC03254.JPG: Dobrika
DSC03255.JPG: Jonathan, Claire
DSC03256.JPG: Juan, Zeno, Henri-Damien
DSC03258.JPG: Marc, Paul (me)
DSC03259.JPG: St?phane, Christophe
DSC03265.JPG: Laurent, Kim
DSC03279.JPG: everybody !
DSC03308.JPG: Jean Manuel, Leila
DSC03238.JPG: Mathilde, Julien


(DSC03230.JPG and DSC03231.JPG will show you some french cheese that
were really delicious ;-) )

PS: low quality picture, I know :(

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

From glawson at rhcl.org  Fri Mar 30 16:56:45 2012
From: glawson at rhcl.org (G. Laws)
Date: Fri, 30 Mar 2012 09:56:45 -0500
Subject: [Koha-devel] performance issues with mysql and koha on 2
 physical servers
In-Reply-To: <4F756A60.4010705@biblibre.com>
References: <4F756A60.4010705@biblibre.com>
Message-ID: <4F75C9AD.2000909@rhcl.org>

In a related matter, has anyone looked at separating the user login
credentials (the passwords) from the rest of the database (putting the
passwords on a separate server) for security?

-- 

Greg Lawson
Rolling Hills Consolidated Library
1912 N. Belt Highway
St. Joseph, MO 64506

--------------------------

On 03/30/2012 03:10 AM, Claire Hernandez wrote:
> Hello all,
>
> I would like to better understand why when we put koha source on a
> different mysql physical server we have a performance problems.
>
> If I put mysql on koha source server, an opac-search take 2 times less
> than if I separate mysql server and koha sources.
>
> I don't really know why:
> - perl libs? (CGI + DBH?)
> - mysql setting?
> - network setting?
>
> Do you know thinks about this? did you work or remember works from
> others ?
>
> (I am really not comfortable with hardware architecture or server
> settings and first I would like to collect your feedbacks.)
>
> Claire;
> _______________________________________________
> 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/
>

-- 

Greg Lawson
Rolling Hills Consolidated Library
1912 N. Belt Highway
St. Joseph, MO 64506
816-232-5479


From cnighswonger at foundations.edu  Fri Mar 30 17:20:32 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Fri, 30 Mar 2012 11:20:32 -0400
Subject: [Koha-devel] performance issues with mysql and koha on 2
	physical servers
In-Reply-To: <4F75C9AD.2000909@rhcl.org>
References: <4F756A60.4010705@biblibre.com> <4F75C9AD.2000909@rhcl.org>
Message-ID: <CAP3yOomth7CFy4FtfSk=Q-trpu+VdHjvbMtdHOs4aaAKYEjUFw@mail.gmail.com>

On Fri, Mar 30, 2012 at 10:56 AM, G. Laws <glawson at rhcl.org> wrote:

> In a related matter, has anyone looked at separating the user login
> credentials (the passwords) from the rest of the database (putting the
> passwords on a separate server) for security?
>
>
I think this is essentially what the LDAP stuff does.

OpenId integration would be a nice feature, though.

I seem to recall that Biblibre did some work on SSO type services...

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

From paul.poulain at biblibre.com  Fri Mar 30 18:15:14 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 30 Mar 2012 18:15:14 +0200
Subject: [Koha-devel] Solr / zebra / search in Koha 3.10 => starting a
	workgroup
Message-ID: <4F75DC12.2090201@biblibre.com>

Hello all,

As you know, our main goal for the oct12 release of Koha is to introduce
solr as an alternate search engine.
BibLibre already explained which improvements will be added by this
search engine on the blog page:
http://drupal.biblibre.com/en/blog/entry/solr-developments-for-koha

During the hackfest in Marseille, a group of 4 persons (Claire,
Henri-Damien, Juan and Zeno) worked on how this work should be done to
be introduced smoothly. The first goal being that a library wanting to
run zebra still could. As some librarians could want to use another
search engine than zebra or solr, we want to follow a path that would
result in a better modularity.
I also think that most of us agree that current search code is ugly &
very hard to maintain/improve.

The hackfesters have produced a drawing explaining how we could name the
different packages:
https://docs.google.com/a/biblibre.com/drawings/d/1ZdsQsoThYgIVSgH3LqgRZy17xm9X7XkLT6RG3fDYCzs/edit,
with a page on the wiki:
http://wiki.koha-community.org/wiki/Switch_to_Solr_RFC#.23kohahack12

In this drawing (read from bottom to top), there are 2 main layers
"Search" and "Index", that are reponsible of doing searches and doing
indexing. The "Conf" object will be responsible to retrieve the
configuration (current getIndexes), the "Query" object would be
responsible to build the query in SearchEngine grammar, the "Plugin"
object would be reponsible to deal with records before indexing (like
normalizing data)

Claire (from BibLibre) made a first implementation of this organization
on github:
https://github.com/clrh/wip-searchengine-layer/tree/master/lib/SearchEngine.
Juan (from xercode), also worked on this organization, on the zebra
side. His code is available also on github:
https://github.com/xercode/Data-SearchEngine-Zebra. Now, Henri-Damien is
continuing the work for implementing zebra with this global structure.

In the meantime, 2 other directions have been followed:
* Fr?d?ric (Demians, from Tamil) wrote a daemon for zebra indexing (see
http://git.tamil.fr/?p=Koha-Contrib-Tamil;a=summary), that resulted in
bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7759, that
document how to introduce this daemon for indexing. Liz (and maybe
others) are using it without any problem. This git repository introduces
some other tools, but what they effectively do is not completely clear
to me (Fr?d?ric, if you want, to add some info...)
* Galen (Charlton, from Equinox) wrote some code that you can see in
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7818 and is in
"needs signoff" status. The description of the bug includes a lot of
things: DOM indexing for biblios (and a tool to automatically write the
DOM xsl from the record.abs), and a normalizer for datas, an indexer
(Koha::Indexer). Unless I've missed something (Galen, tell if I'm
wrong): for now, only the DOM indexing is submitted, normalizer and
indexer are not.

What we all agree about: we should have a clearer way to: Normalize /
Index / Search in Koha. That's great !

The structure described by the hackfester is great because it's
independent from the SearchEngine you use.
I think large portions (if not all) of Koha::Contrib::Tamil could be
used to write the zebra indexing layer.
I also think that The DOM indexing part of what Galen has submitted can
be signed-off & pushed without any risk, but the normalize and indexer
parts will need coordination to avoid having BibLibre/xercode working in
a direction, and Galen working in another. I really like the idea of
having normalizer not necessary being MARC; that could be useful in the
future.

That's why I propose to organize an IRC meeting (date and time to
define, but that will be in Europe afternoon / US morning) with all
volunteers to coordinate their efforts. I think this meeting should be
regular (monthly ?)
After each meeting, a summary of the conclusions would be made on the
wiki and posted on this mailing-list.

My proposition: if you're interested by participating to this effort,
please answer to this mail. (I'll then start a doodle to find a proper
time. I propose 2 hours for the duration of the 1st meeting, then,
hopefully, shorter meetings) -Juan/Galen/Zeno, you're considered as
being interested by this topic ;-)
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From bargioni at pusc.it  Fri Mar 30 18:23:05 2012
From: bargioni at pusc.it (Stefano Bargioni)
Date: Fri, 30 Mar 2012 18:23:05 +0200
Subject: [Koha-devel] MARC tab shortcuts
Message-ID: <CD9026E8-B44C-4987-9B85-B5EA6971A428@pusc.it>

Something similar was discussed some years ago in
http://koha.1045719.n5.nabble.com/Staff-client-keyboard-shortcuts-td3066327.html

Koha Staff has four pages where MARC tags are grouped under tabs:

catalogue/MARCdetail.pl
cataloguing/addbiblio.pl
authorities/detail.pl
authorities/authorities.pl

I successfully proposed to my cataloguers a way to pass from tab to tab pressing numbers (keyboard or keypad).
The solution (this is for catalogue/MARCdetail.pl):

$(document).ready(function() {

if (location.pathname.indexOf('catalogue/MARCdetail.pl')>-1) {
 $(document).keydown(function(e) {
  if (e.target.tagName == 'INPUT') return;
  if (e.target.tagName == 'TEXTAREA') return;
  var f = 0; // flag
  var c = e.which; // code key pressed
  if (c >= 48 && c <= 57)  {f=1; c -= 48;} // 0..9 keyboard
  if (c >= 96 && c <= 105) {f=1; c -= 96;} // 0..9 keypad
  if (f == 0) return;
  var marc_sections = $('#bibliotabs ul li a').text().replace(/[^0-9]/g,'');
  var marc_section = marc_sections.indexOf(c);
  if (marc_section == -1) return;
  $($('#bibliotabs ul li a')[marc_section]).click();
 });
};

});

We tested it in a lot of Mac browsers, also a very old one like Firefox 3.6.6. It works fine with Koha 3.2.7 and Koha 3.6.1.
I'd like to share the code but I think that we need more testing on Linux and Windows -- keyboard events are managed in a lot of manners by browsers.
To test it, open a record like
http://your_koha.org:8080/cgi-bin/koha/catalogue/MARCdetail.pl?biblionumber=12345
open the Firebug console, paste the code and try to skip from tab to tab pressing numbers. 
Changing or reloading the record will lose the event capture: paste the code again.
And please let me know.
Thanks. Stefano

From dpavlin at rot13.org  Fri Mar 30 18:33:34 2012
From: dpavlin at rot13.org (Dobrica Pavlinusic)
Date: Fri, 30 Mar 2012 18:33:34 +0200
Subject: [Koha-devel] performance issues with mysql and koha on 2
 physical servers
In-Reply-To: <4F756A60.4010705@biblibre.com>
References: <4F756A60.4010705@biblibre.com>
Message-ID: <20120330163334.GC3230@rot13.org>

On Fri, Mar 30, 2012 at 10:10:08AM +0200, Claire Hernandez wrote:
> Hello all,
> 
> I would like to better understand why when we put koha source on a
> different mysql physical server we have a performance problems.
> 
> If I put mysql on koha source server, an opac-search take 2 times
> less than if I separate mysql server and koha sources.
> 
> I don't really know why:
> - perl libs? (CGI + DBH?)
> - mysql setting?
> - network setting?

I would add another reason:

- too many database queries coupled with TCP overhead

How do I know that?

When running OPAC under plack with plack in bug 7848[1] with debug pannels
which lately include very useful DBI profile[2] feature I get following:

4.730399 s for whole request
2.106 s (44%) for DBI

So I could guess that half of page load time is load on the database.

My personal favourite is this:

Profile Path: SELECT tagfield,tagsubfield,liblibrarian,libopac,tab,mandatory,repeatable,authorised_value,authtypecode,value_builder,kohafield,seealso,hidden,isurl,link,defaultvalue,maxlength FROM marc_subfield_structure WHERE frameworkcode=? ORDER BY tagfield,tagsubfield
Profile Data: 0.183024s / 10673 = 0.000017s avg (first 0.000037s, min 0.000004s, max 0.064041s)

That's 10673 SQL queries to retrive framework for one search page!

How many frameworks do you have? What about caching or memoize
(which I plan to implement in bug 7177[3], which now needs re-works since
we have plack and nice profiling tools).

In fact, I plan to use most of my time fixing problems like this. To be
honest, plack didn't bring all performance we can squeeze from current
code - bug 7846[4] is my favourite example.

List of bugs mentioned in this mail, waiting for sign off :-)

1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7847
2: PLACK_DEBUG=1 ./opac-plack.sh srvgit
3: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7177
4: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7846

-- 
Dobrica Pavlinusic               2share!2flame            dpavlin at rot13.org
Unix addict. Internet consultant.             http://www.rot13.org/~dpavlin

From chris at bigballofwax.co.nz  Fri Mar 30 20:40:38 2012
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Sat, 31 Mar 2012 07:40:38 +1300
Subject: [Koha-devel] Call for papers for Kohacon12
Message-ID: <CA+95qVTq9GoJijh4DRPfJqTBhHPknC9dShcQTmKR9SwaBe4BhA@mail.gmail.com>

The call for conference papers is open. We?d love to see presentations
from librarians for librarians, sharing their experiences, tricks and
tips. Talk times are flexible, with long and short options, so please
consider registering as a speaker.

We are particularly keen to receive proposals about archives/special
libraries using Koha, Resource Description Framework/Semantic
Web/Linked Data and the Koha packages, in both the main conference and
the later hackfest.

Please complete the form at
http://koha-community.org/kohacon12/call-papers/

We will prefer vendor-neutral talks, in English or with English
translation, with copyright licensed under GPLv2+, CC-By, CC-By-SA or
something similar. Examples from a previous conference can be viewed
at http://www.kohacon10.org.nz/

The deadline for talk proposals is April 20, so please go submit one now

Chris

From frederic at tamil.fr  Sat Mar 31 17:22:04 2012
From: frederic at tamil.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Demians?=)
Date: Sat, 31 Mar 2012 17:22:04 +0200
Subject: [Koha-devel] Solr / zebra / search in Koha 3.10 => starting a
 workgroup
In-Reply-To: <4F75DC12.2090201@biblibre.com>
References: <4F75DC12.2090201@biblibre.com>
Message-ID: <4F77211C.4080405@tamil.fr>

 > The hackfesters have produced a drawing explaining how we could name
 > the different packages:

The classes hierarchy seems to rely on Data::SearchEngine module as
abstraction layer:

https://metacpan.org/release/Data-SearchEngine

Are you it touch with the module author? He could give us interesting
feedback on his module. What kind of implementation has he done? Is
there any other implementation done by someone else than his author? Is
it generic enough to be used in Koha context?

There is a ElasticSearch implementation of Data::SearchEngine:

https://github.com/gphat/data-searchengine-elasticsearch

In implementation notes, we can read:

   ElasticSearch's query DSL is large and complex. It is not well suited
   to abstraction by a library like this one. As such you will almost
   likely find this abstraction lacking. Expect it to improve as the author
   uses more of ElasticSearch's features in applications.

 > * Fr?d?ric (Demians, from Tamil) wrote a daemon for zebra indexing
 > (see http://git.tamil.fr/?p=Koha-Contrib-Tamil;a=summary), that
 > resulted in bug
 > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7759, that
 > document how to introduce this daemon for indexing. Liz (and maybe
 > others) are using it without any problem.

I don't think there is a lot to do to have an abstraction layer for
indexing with SolR/Zebra/xx.

Koha::Indexer
  |
  +-- Koha::Indexer::SolR
  +-- Koha::Indexer::Zebra

A indexer is then able to index partially (queued) or fully biblio or
authority records. A command line indexing script is nothing more than a
wrapper to this class. It's even possible to run the task from the web
interface. There is a 'watcher' associated with the indexer which could
communicate asynchronously with a WUI via a JavaScript callback function.

As with rebuild_zebra.pl, indexing is a two step process: (1) export
record and (2) index records. Since record format/syntax to be sent to
the search engine may vary: XML, ISO2709, JSON (ElasticSearch), the
exporter must also be a generic class subclassed by a specific class for
each search engine, implementing normalization processing. I'd need to
see how it works now in SolR/Biblibre branch.

For me, the most undecided/mysterious part of the whole is the query
parser. Now, Koha support several syntaxes thanks to ZOOM yaz client: PQF,
CCL and CQL. Queries in those syntaxes are directly given to ZOOM. I
can't figure out how it can be reproduced with other search engine than
Zebra... This isn't a small piece of engineering. See above the citation
about Data::SearcEngine::ElasticSearch. It's one thing to abstract a
search result and its paging, and another thing to abstract a query
language--imagine three languages...

To be continued...
-- 
Fr?d?ric DEMIANS
http://www.tamil.fr/u/fdemians.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120331/aefaf702/attachment.htm>