On Sat, Jun 1, 2013 at 6:37 PM, Paul <pau...@aandc.org> wrote:

> At 07:17 AM 6/1/2013 -0700, BWS Johnson wrote:
>
>> >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/<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.
>>
>
> Mea culpa if I 'pirated' this thread to *stability* rather than *QA*, but
> they are closely intertwined.
>

Heh, you hijacked my Plugins QA policy thread :-D


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

I'm repeating others in previous threads where I said things similar to
yours: as an open source project, it relies on companies and institutions
sponsoring human labour.

UNC made a decision on this: we chose this product, and endorsed it. We
hired some weird guy to make things work for libraries (lucky me :-D ). We
used 3.0.x for almost three years, and been using 3.8.x for a year. We saw
3.12.x as an interesting release (several stuff we wanted to have got
inside of this release, not all of it unfortunately) and accepted the
challenge of maintaining this release. How long? As long as we can.

If a company envisioned supporting an LTS Koha release as a market niche
they could get profit from, I'm pretty sure someone will step in and
propose themself as Release Maintainer for that release. Such is not the
case right now.

But there's no disagreement on the LTS thing, and complaining for not
having that yet won't make it happen. Is a non-technical discussion.

Regards
To+
_______________________________________________
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/

Reply via email to