[Koha-devel] RFC: Plugins QA

Sat Jun 1 23:37:02 CEST 2013

At 07:17 AM 6/1/2013 -0700, BWS Johnson wrote:
>Salvete!
> >Tarballs, packages, gits (including vendors), stables, latest, bugs and
>patches, wikis (various), tools, reports, live-DVDs, mailing lists, chat,
>maybe more, and now plug-ins?  Could we please look at what the
>"open source" world is doing? Apache, SendMail, Perl, PostFix,
>FireFox, Debian, Ubuntu, OpenOffice, LibreOffice ... are fairly stable
>with an established security update capability. Even Java and MySQL are
>simplifying.
> >
>     I'm all for giving our developers the flexibility to deliver their 
> code in whatever form they have time to wrap it in. I might _like_ them 
> to do things my way, but I'm not paying them, and I never have.

Agreed -- 100%. My concern is with the "final product", not the means of 
getting there.

>     What do you consider instable or insecure in particular?

This thread started questioning the need for QA for plugins, *potentially* 
insecure.

The instability issue is part perception/communication, part superb 
enthusiasm on the community/development side. But the fact remains that on 
14 September 2012, we went live with Koha 3.8.4 which was the "cat's 
whiskers" just eight months ago. 3.8 is now "old stable", 3.10 is "stable" 
and 3.12 "development" is advertized (Wiki) equally prominently. And the 
Wiki continues:

"If you're unsure what you want, go for the stable version. If you want to 
be a bit more conservative, go for the most recent old-stables release.
Note that both of these are still very much a work in progress: they won't 
work perfectly just yet."

There is, for a newcomer reading the Wiki, no "working perfectly" LTS (long 
term stable) release. My *opinion* is that we need (cf Ubuntu) a five year 
cycle -- 2 years "stable+security", 2 years continuing support, 1 year 
buffer zone -- this could be seen as maturity in the open-source world.

>     Many of those projects are quite large, so in my light, afford their 
> respective projects the ability to do things that we as a smaller project 
> might not be able to manage.

I truly believe that Koha is no longer a "smaller project", but you make a 
valid point.

>     Many thanks to Robin and anyone else that helped with the packages. I 
> had whinged for ages that I'd love to just have an apt-get command.

Agreed 100% -- although I have never used the packages.

> >I had a "rather important" librarian from Quebec drop in, out
>of the blue, yesterday to talk about Koha. Her group (37 libraries) had
>previously been burned by a trial commercial implementation of Koha (no
>need to quote names), so they're using Opals, but "liked the
>idea" of Koha. First question: "stability?"
>     I am stymied by this. Completely, utterly flabbergasted. First, 
> whatever trash LibLime were selling wasn't Koha.

I was somewhat careful not to quote names ;=} -- you could be right in your 
assumption, but at my age "my memory fails me ..."

>Second, OPALS?  As in
>http://www.mediaflex.net/showcase.jsp?record_id=52

Yup. "OPALS, an open source ILS for school libraries and districts 
developed and supported by Media Flex earned top rankings in Company 
Satisfaction, Product Support, and Company Loyalty." See 
<http://www.librarytechnology.org/perceptions2012.pl>

>     One of the questions I posed to my students was "Is OPALS truly open 
> source if you have to beg for the code and a demo?" In terms of feature 
> comparison and breadth of adoption, it's not even close. It's well known 
> I've a soft spot in the granite thing that's meant to be my heart when it 
> comes to Koha, but I freely admit when I think we get beat. That is most 
> certainly not the case with Koha, and I wish them the best of luck 
> getting a consortium up and running in a multilingual capacity with that heap.

I respect your opinion (but see Marshall Breeding's survey above.) If I 
knew more about Opals, I might well agree.

> >I know that a number of you will ... whatever ... Paul's a pain in the
>neck, doesn't understand, does his own thing, but the bottom line is that
><http://opac.navalmarinearchive.com/>
>is fully functional and is intrinsically Koha. It's (reasonably) secure
>(without https) and meets the needs of our users and librarians. It runs
>itself with minimal ( < 1 hour/week statistically ) intervention by IT
>personnel.
>
>     So what's the problem? I'm truly sorry, but I just don't understand 
> why you're ranting here.

Getting Koha recognized as a major player. I'm convinced. I'm keen on 
persuading other institutions. I'll do my utmost. I just see the lack of a 
solid LTS release as a difficulty. This thread subject concerns "plugins 
QA", and my first para mentions [other open-source as] "fairly stable with 
an established security update capability"; looking at e.g. Firefox 
plugins, Mozilla says (FAQs) "Unless clearly marked otherwise, add-ons 
available from this gallery have been checked and approved by Mozilla's 
team of editors and are safe to install. We recommend that you only install 
approved add-ons."

Mea culpa if I 'pirated' this thread to *stability* rather than *QA*, but 
they are closely intertwined.

> >There are very few institutions that have "happiness" in the
>form of unlimited budgets and unlimited IT departments. I'm personally
>intrigued by the creativity of the Koha community, so try and follow
>what's happening -- which is magnificent -- but doubt that your average
>library has the same passion.
>
>     I think most of the discussions we have are important, and I really 
> love having the longer term steering and strategic types of conversations.

I hope (and genuinely believe) that we're not the only two participants 
here interested in "steering and strategic types of conversations" and also 
hope that my thoughts on stability (QA, maturity, reputation) might strike 
chords with others. It's not criticism, perhaps more my dream of the next 
"small step" for library systems. In my 50+ years of code development, I 
can honestly say that end-user credibility is very closely related to 
stability, and that within "stable" the differentiation between security 
and enhancement must be crystal clear (and separately optional from an 
upgrade pov.) "It works as promised" is a huge compliment. The old saying 
"if it doesn't work, use a bigger hammer; if that fails, rtfm" is dubious 
management.

Thanks for your thoughts and best regards,
Paul

>It's been a long time since I had to interact with proprietary vendors, 
>and I don't relish the thought of ever being charged with that again. I 
>think that a lot of the development done at least gives a nod to small 
>libraries. More often than no, folks bend over backwards for small 
>libraries. I get quite prickly if I sense that things *aren't* moving that 
>way. This is a big tent system, there's plenty of room for everyone's 
>individual take. :)
>
>
>Cheers,
>Brooke
>_______________________________________________
>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/

---
Maritime heritage and history, preservation and conservation,
research and education through the written word and the arts.
<http://NavalMarineArchive.com> and <http://UltraMarine.ca>