On Tue, Dec 10, 2013 at 3:59 PM, Liz Rea <liz@catalyst.net.nz> wrote:

IE 7 is only available in Windows XP, which is due to be end of life in April 2014.

Something I think also gets lost in the discussion: Just because someone is still running Windows XP doesn't mean they're using IE 7. The latest versions of Firefox and Chrome work fine on WinXP. Dropping support for IE 7 means only dropping support for that small subset of WinXP users who are still running IE 7. Let's let the real statistics tell the story. As far as my library goes, IE 7 traffic over the last year was .7% of all visits. FF 3.x traffic during the same period was .8%. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

Greetings,

If it means broken functionality, that is a problem for us. If it means graceful degradation, that's more acceptable.

Yes and yes.

I'll be doing some investigation, but I think we need some opinions from others about what level of support we need to offer for IE7 and FF 3.6.

IE7 ran in Windows as early as Windows 98. This means it is quite old. Windows 98 is no longer supported. The OS that people are most concerned with people still having is XP, which was IE7 by default, though, if I recall correctly, later versions did run in it. http://windows.microsoft.com/en-CA/windows/end-support-help April 2014 is just before the release of 3.16 in May 2014. http://cdn2.tnwcdn.com/wp-content/blogs.dir/1/files/2013/08/ie_july_2013.png http://cdn0.tnwcdn.com/wp-content/blogs.dir/1/files/2013/08/firefox_july_201... I feel like I'm basically agreeing with Liz. If *MICROSOFT* is dumping IE7 and they wrote it, then perhaps we should not worry about lost support for it in bootstrap 3. As for FireFox, my wife is attending college here, and their tech support only supports FireFox 4.0 (which seems silly, but I ended up locking my wife's browser to not upgrade). So, I figure losing 3.6 support is probably okay too. GPML, Mark Tompsett

Some plans that ByWater (Kyle, Jesse, etc.) has for 3.16 (or at least make sure our patches are out there). Elastic Search - which Chris talked about. New catalogers interface - which Jesse Weaver has been working on and we're getting closer and closer to having that ready to submit. (Jesse did a quick demo at KohaCon in Reno). I bug pianohacker daily on when that's going to be submitted :) Finishing the Plackifying of the staff-side so that it could be stably used. I would also like to see a big push of using DBIx::Class and I love the comments from Galen about using Koha on PG (++). We are more than willing to help in that project Galen - please take advantage of us and let us know what you'd need help on. We will contribute in any way that we can. Just some thoughts - and I'm sure we'll add to that in the coming months. On Tue, Dec 10, 2013 at 1:11 PM, Chris Cormack <chris@bigballofwax.co.nz>wrote:

Hi All

In addition to the goals Galen has mentioned.

Catalyst and Bywater are working on adding ElasticSearch as an option for searching in Koha. It will of course not remove Zebra, but will provide the option of using it as a search tool instead.

The brief plan is

Write code, so that if ElasticSearch is selected, when a Biblio is modified the index is updated. This will not preclude the zebra code from running, so the zebra indices are still updated too. (This is mostly working now)

Next, allow the Public Interface (OPAC in the old talk) to use ElasticSearch to do it's searches (sorta working)

Then, implement a browse feature (in planning)

Then, allow the staff catalogue to use ElasticSearch (not even started).

(Probably only get this far for 3.16)

Then move on to the authorities ..

Then allow for fully ajax option for searching ...

The plan is incremental increases, not breaking existing search, in fact not touching the zebra code at all, so that any time you could switch back and you would still have working searches.

Maybe eventually it will be feature complete, including a z3950 and sru/sw server and we can make switching it on mean switching zebra off. But definitely not for 3.16.

You can follow along at

http://git.catalyst.net.nz/gw?p=koha.git;a=shortlog;h=refs/heads/elastic_sea...

I push everything as I go, (I will tidy it up into neater patches before submitting of course)

Also, big huge thanks to the Catmandu developers http://librecat.org/index.html whose library I am making extensive use of http://search.cpan.org/~nics/Catmandu-0.8001/

I even got a patch in https://github.com/LibreCat/Catmandu-MARC/commits/master And its in the latest version on CPAN already.

I am sure we will make much more use of their code, for creating RDF etc also

Ok, tangent finished :)

Chris _______________________________________________ Koha-devel mailing list Koha-devel@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/

-- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Santa Barbara, CA - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info@bywatersolutions.com

Hi, On Wed, Dec 18, 2013 at 8:28 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:

Le 10/12/2013 23:50, Brendan Gallagher a écrit :

...

Finishing the Plackifying of the staff-side so that it could be stably used. The SAN-OP is running Plack on staff since 3.10, it runs fine, except for C4/BackgroundJobs, and we could not understand where the problem comes from, because we can't reproduce it outside from SAN-OP server (which is expected to be a Wheezy-with-nothing-exotic)

I think there may be a bit more to it considering the existence of things like bug 9224 and the lack of a consensus Plack configuration in the source tree. That said, I would agree that Plack-compatibility for the staff interface is both achievable and not far off for 3.16. [1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9224 Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@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

Le 18/12/2013 23:36, Galen Charlton a écrit :
> Hi,
> 
> On Wed, Dec 18, 2013 at 8:28 AM, Paul Poulain
> <paul.poulain@biblibre.com> wrote:
>> Le 10/12/2013 23:50, Brendan Gallagher a écrit :
>>> Finishing the Plackifying of the staff-side so that it could be
>>> stably used.
>> The SAN-OP is running Plack on staff since 3.10, it runs fine,
>> except for C4/BackgroundJobs, and we could not understand where the
>> problem comes from, because we can't reproduce it outside from
>> SAN-OP server (which is expected to be a
>> Wheezy-with-nothing-exotic)
> 
> I think there may be a bit more to it considering the existence of 
> things like bug 9224 and the lack of a consensus Plack configuration 
> in the source tree.
That's what I should have pointed: there's some/quite a lot of work to
do to setup Plack during install if we want.
Next question then: what do we want :
 * the installer let the user choose Plack - CGI mode ? (ie: trading
memory for performance)
 * the install is made in CGI mode and we provide tools to setup Plack
for those who want it (manually editing configurations)
 * the install is made in CGI mode and we document how to setup Plack
 * other idea ?

> That said, I would agree that Plack-compatibility for the staff
> interface is both achievable and not far off for 3.16.
and give a good benefit. Added to caching & DBIx::Classing (with cache
too), the performance gain will be large (on the long term)

-- 
Paul POULAIN - Associé-gérant
Tel : (33) 4 91 81 35 08
http://www.biblibre.com
Logiciels Libres pour les bibliothèques et les centres de documentation

Hi, On Wed, Dec 18, 2013 at 8:38 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:

Le 10/12/2013 01:59, Galen Charlton a écrit : I'd like to see as many of the 70 improvements or new features already submitted by BibLibre (plus more coming) being signed-off, QAed and pushed (Sorry if I appear a little bit rude)

Same thing for the 120 improvements or new features not submitted by BibLibre and that are in the same status.

I'll be direct: it is not enough to submit a patch, then expect it to be reviewed quickly. Eventually most things will get looked at by other developers in the community. "Eventually" is a rather imprecise time period, of course, and I appreciate how awkward it is. For good or ill, to my knowledge there's nobody who is time is being sponsored specifically to do patch review. We are quite fortunate that there are folks who are doing it anyway. I would like to publicly call out and thank the folks who have done 50 or more initial patch signoffs according to Bugzilla this year: Kyle M Hall- 262 Bernardo Gonzalez Kriegel- 192 Chris Cormack- 182 Owen Leonard- 177 Jonathan Druart- 112 M. de Rooy- 112 Srdjan Jankovic- 87 Katrin Fischer- 68 Paul Poulain- 63 Liz Rea- 50 I would also like to thank the folks who have reviewed any patches at all, too -- for the complete list so far, scroll to the bottom of the page at http://dashboard.koha-community.org/. Nonetheless, there needs to be more people signing off on things, period. However, I submit the following thesis: organizations -- and I use the word "organization" intentionally -- who author a lot of patches should also be doing a lot of patch review. More to the point, that patch review should be distributed, not just depend on the efforts of a subset of the developer employees.. That last sentence is yes, directed at BibLibre, but not just at BibLibre. There are several organizations active in Koha development who have more than one person authoring patches on a regular basis. Not all of them are reviewing patches at a proportional rate. Thus, my challenge to everybody, but in particular to multi-developer organizations: consider implementing a practice of *at least* one for one. In other words, for each patch you submit, review another developer's patch. Review doesn't mean automatic signoff -- it's valid feedback to mark a patch as failed QA so long as you explain why. If an organization has got an employee who is active on the QA team, their QA work counts too, of course -- but that shouldn't put the other developers of that organization off the hook for doing their share of patch review. One for one is a minimum, I feel -- there are several organizations that average two or more patches reviewed for each one they author. [2] One thing I will add -- if one looks at the commits pushed to the master branch, starting with the beginning of the 3.2 development cycle through the release of 3.14.0, the release manager who has pushed the most patches authored by BibLibre is... me. This isn't actually a terribly interesting fact, as a lot of factors contribute to the ebb and flow of which patches get pushed when, but I hope you will take this as indication that I highly value the work that BibLibre has done and continues to do.

...

[1] Deprecation of the GRS-1 mode for Zebra. +1

...

Obstacles: the default UNIMARC indexing rules for the DOM filter need more testing. There is also an ongoing discussion about the desired semantics for the Any index, which at present behaves differently with the current DOM indexing rules as compared with GRS-1. And BibLibre should be a leader here, I apologize because we aren't

Great -- I look forward to BibLibre taking a more active role on this front.

...

Upgrade considerations: in order to truly deprecate the GRS-1 filter, at some point there will have to be a forced reindexing upon upgrade. Note that when upgrading from 3.6 to 3.8 (iirc), one also had to run a separate script to remove items from marcxml, so having a "complex" upgrade is "uncommon" but not "never happened"

I agree -- a forced reindexing is by no means the end of the world in the simplest case: it just adds time to the upgrade process, but that can be planned for. Users who have customized their Zebra index definitions will have more work to do during an upgrade, however.

...

[2] Use DBIx::Class to deploy the database schema for new installations. No opinion, because I'm not sure I see all the consequences.

Using DBIx::Class to deploy the schema would facilitate PostgreSQL support. Of more immediate interest, however, use of DBIx::Class::Schema::Versioned or the like to manage database updates would provide an alternative that doesn't rely on bespoke code. The primary obstacle to use of DBIC for deploying the schema is that DBIC doesn't inherently know anything about how to create indexes or which indexes to create. It also doesn't know anything about which MySQL storage engine to use. Fortunately, DBIC does provide a mechanism [1] for specifying the creation of indexes and setting per-table options, so the obstacle should be transient.

...

[3] Relaunch PostgreSQL support As a long term goal, I'm fine with that, but I don't think I'll invest any time for now. Better adding DBIx::Class support imho.

That's fine. [1] https://metacpan.org/pod/DBIx::Class::Schema#sqlt_deploy_hook [2] http://paste.koha-community.org/27 -- the report for 3.14.0 is courtesy of Chris Cormack. For each organization, the first line is the number of patches authored, while the second line is the number of patches containing a signoff from that organization. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@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

Hi, On Thu, Dec 19, 2013 at 8:17 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:

Le 18/12/2013 23:31, Galen Charlton a écrit :

...

Paul Poulain- 63 I don't endorse those 63: most of them (if not all) were in fact sandboxes signoff, because I use my account to send signoff from the sandboxes. Maybe we should/could create a generic "sandbox signoff" account ?

I think that's a good idea. Another idea (if it doesn't do it already) would be to have the sandbox ask the user to supply their name and email address so that they can be individually credited with the signoff if they want.

...

One for one is a minimum, I feel -- there are several organizations that average two or more patches reviewed for each one they author. [2] I'm a little bit uncomfortable with those numbers because they can't show the time we dedicate to rebasing patches. When you submit an enhancement that is not pushed quickly, rebasing 4 or 5 times is common. And that's a part of the quality process. And we try to have a very good reactivity on this matter. But those number can also convince me to ask someone from my staff to get involved (on a regular basis).

Great! I hope they do so.

And if I were playful[*], I would bounce[*] on the fact that you highly value the work we're doing: thank you for that. I'm sure then, as you value it so high, that you'll try to find a way to conserve (or even improve) our enthusiasm, right ? ;-)

[*] strictly no negative meaning here, I hope google translate didn't lied to me with these words...

Google Translate didn't lie to you. And thank you.

...

Users who have customized their Zebra index definitions will have more work to do during an upgrade, however. OTOH, those who are able to customize their zebra index definitions also have the skills to double check their upgrade ;-)

One can only hope. :) Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@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

Hi On Fri, Dec 20, 2013 at 1:21 AM, Jonathan Druart <jonathan.druart@biblibre.com> wrote:

2013/12/19 Galen Charlton <gmc@esilibrary.com>: I have already created an account for sandboxes' SO : sandboxes@biblibre.com. By signing off, the form asks for a name and an email address. These 2 information are used to fill the Signed-off-by line in the commit message. It is not possible to switch the bz status to signed off by using the sandbox interface: the script has to log in bugzilla for that and I don't want to ask for a password in the sandbox interface.

Quite right -- it had slipped my mind momentarily that the dashboard's count of signoffs goes by Bugzilla status changes, not the line in the commit message. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@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

At 05:17 PM 12/19/2013 +0100, Paul Poulain wrote: [snip]

...

And if I were playful[*], I would bounce[*] on the fact that you highly value the work we're doing: [snip]

[*] strictly no negative meaning here, I hope google translate didn't lied to me with these words...

Ça aide d'être multilingue -- more probably "jump" rather than bounce (je sauterais de joie sur le fait que...?) Reverse engineering 'playful' is more problematic: "badiner?" Non, "taquin" => playful ( "taquin" is a mix of kidding, laughing, and

Le 19/12/2013 18:22, Paul A a écrit : pointing some inconsistency/a limit/a mistake ). For example, my wife is always saying I should not wear green clothes. And today, she wear green clothes. I'll "taquiner" her about that : "darling, don't you say you don't like green clothes ?" et "rebondir" pour "bounce" ("take up the ball") -- Paul POULAIN - Associé-gérant Tel : (33) 4 91 81 35 08 http://www.biblibre.com Logiciels Libres pour les bibliothèques et les centres de documentation