[Koha-devel] RFC: proposing change to Koha's plugins system

[Petter Goksøyr Åsen]

> Please don't misunderstand me.  I'm all in favour of "improvments", but
I'm trying to understand you. You come across as somewhat saracstic, but I hope I'm wrong.

The chrome audit analysis you cite is not that bad. If you run it even on 
google search page you will also find ~1000 unused css rules.
Im not saying these kind of micro-optiizations not are worthwhile, but it's likely
to have a very minor impact on Koha's performance as a whole. Some nanoseconds maybe.

As for long vs short release cycles - I prefer frequent releases.

Keep up the good work, everyone:)

Best regards
Petter Goksøyr Åsen
Deichmanske bibliotek / Oslo Public Library
________________________________________
Fra: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] på vegne av Paul A [paul.a at navalmarinearchive.com]
Sendt: 22. august 2014 02:32
Til: koha-devel at lists.koha-community.org
Emne: Re: [Koha-devel] RFC: proposing change to Koha's plugins system

At 10:16 PM 8/21/2014 +0000, Indranil Das Gupta wrote:
>Hi all,
>
>I've been trying to use the KPZ structure in some of my projects. In
>general, I've found it rather useful, with a few modifications.
>
>I would like to propose the following changes as
>http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12805
>
>lets have your feedback on this.

With a view of maintaining core stability for Koha, all 'enhancements'
(e.g. plug-ins) should be optional and not affect speed, size and cpu
cycles of basic functionality.  I think that this is what you are
proposing... if I'm mistaken, please advise.

I've been relatively quiet for some time about my intrinsic belief that a
two year cycle of updating Koha (along the same 2-year lines of most OS's)
should be the norm. "If it ain't broke, don't fix it."  Enhancements (not
security updates) should be for the end-user to decide upon, and most
libraries do not have the personnel | time | budget to get involved every
couple of months.

I recognize that the paid consultants may have an interest -- and I have
absolutely nothing against that; without them a huge amount of "Koha devel"
would not take place.  However, we are getting ready to upgrade our servers
from 2012 to 2014 standards, and I've been looking at Koha 3.14 and
3.16.  We are *not* a lending library -- just a big research centre -- and
quite frankly I can find no totally compelling reason to upgrade from 3.8
(handheld browsers might be the exception.)  Again, if I'm mistaken, please
advise.

Please don't misunderstand me.  I'm all in favour of "improvments", but
when a quick analysis of one of my OPAC pages come up with:

Combine external CSS (6)
Combine external JavaScript (11)
Leverage browser caching (23)
Leverage proxy caching (5)
Minimize cookie size
Serve static content from a cookieless domain (11)
Specify image dimensions (1)
Optimize the order of styles and scripts (2)
Remove unused CSS rules (1335)
Use normal CSS property names instead of vendor-prefixed ones (3)

it's probably better to look at the 1,335 "unused CSS rules"... (bootstrap?
doesn't do away with yahoo? does zebra depend on yahoo?)

End rant. I promote Koha wherever I can, but in my job I've got to stay
practical. Over the last four years we've put in place a marvelous OPAC
meeting our users requirements.  Please keep up the good work, but please
also maintain core stability.  Compare with Debian (lenny, squeeze, wheezy,
2 year cycle); Ubuntu (lynx, pangolin, tahr, 2 year cycle); Apache (2.2 ==>
2.4, eight/ten? year cycle); MySQL (fairly minor in the 5. series, no
urgency); Perl (ditto); etc...

Best -- Paul


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