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@lists.koha-community.org [koha-devel-bounces@lists.koha-community.org] på vegne av Paul A [paul.a@navalmarinearchive.com] Sendt: 22. august 2014 02:32 Til: koha-devel@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@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/