On Thu, Oct 24, 2013 at 1:41 PM, Owen Leonard <oleonard@myacpl.org> wrote:

I don't want to have to maintain them both any longer than necessary, but I recognize that porting over customizations could be time-consuming.

I think we need some sort of announcement that this is officially going to be deprecated so that we have time to port the customizations from both themes, but I don't think that one release cycle is enough. Nicole

Hi Congrats everybody for the work done during KohaCon and Hackfest! I haven't followed the development of Boostrap opac and Queryparser, but I give you my personal opinion. Maybe I don't understand things well... For the 3 OPAC themes : Some patchs recently made for UNIMARC XSLT were only pushed in prog template, because we did not knew that it needed to be too in CCSR (was it needed?) and in Bootstrap. So, maintaining 3 themes for a long time is obviously impossible, as only a few weeks after the push of Boostrap them, there is already little discrepancies between Boostrap and prog theme :( I would appreciate a clear rule for developpers making changes to OPAC templates, including XSLT (and for QA team) to take into account Bootstrap AND prog (and maybe CCSR?), for the 3.14 version at least. If you want to announce the death of prog and CCSR for 3.16 it is not a problem for me, as we don't really like it, and made huge changes to it with css and jquery hacks. BUT I'm not a big fan for saying that Boostrap theme will be the default theme in 3.14. It is too fresh. The only time I tried to test it, it crashed on my VM ;-) Maybe the rule could be : in 3.15 make your changes for Bootstrap first, and port them to prog and CCSR for maintenance releases including 3.14 ? For the Queryparser : It need to be more documented, so that we know exactly what to do to edit or improve config settings, and what behavior is expected. There is a big RFC page, but now that it is include in Koha's code, we need a different documentation, more directly usable by developers, AND by librarians. For example, I made a patch adding new indexes in Search.pm. From Jared's comments, I guess something is needed in queryparser.yaml, but I don't know exactly what. Idem : what about a rule asking to make changes to QP conf first in 3.15, and in the other parts of Search.pm only for maintenance releases including 3.14 ? For DOM and GRS-1 : Consider that DOM UNIMARC never worked properly, for us DOM is a really fresh thing. Nobody has really tried DOM UNIMARC in a real size Koha, only in VM. I would like to be sure that DOM is not somehow causing some regression. Especially, I wonder if DOM is not going to make the search more "noisy" (we say that in french, not sure in english). If so, some improvements must be made before GRS-1 is deprecated. For example something in the spirit of Bug 8962. Regards, M. Saby ILe 24/10/2013 22:48, Joy Nelson a écrit :

I agree with Nicole. One release cycle is probably not adequate.

-joy

On Thu, Oct 24, 2013 at 3:24 PM, Nicole Engard <nengard@gmail.com <mailto:nengard@gmail.com>> wrote:

On Thu, Oct 24, 2013 at 1:41 PM, Owen Leonard <oleonard@myacpl.org <mailto:oleonard@myacpl.org>> wrote:

I don't want to have to maintain them both any longer than necessary, but I recognize that porting over customizations could be time-consuming.

I think we need some sort of announcement that this is officially going to be deprecated so that we have time to port the customizations from both themes, but I don't think that one release cycle is enough.

Nicole

_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto: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/

-- Joy Nelson Director of Migrations

ByWater Solutions <http://bywatersolutions.com> Support and Consulting for Open Source Software Office: Fort Worth, TX Phone/Fax (888)900-8944 What is Koha? <http://bywatersolutions.com/what-is-koha/>

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

-- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr

The timeframe is all good for deprecation, but what about the immediate issues? For us, it's the first time we hear that this move is coming so we've been developping and contributing on the /prog/ branch solely. What is the plan for the discrepencies already in? What is the plan for the changes in wait of sign-off (or push) ? A short, immediate pain is prefered to a long, drawn, endless itching... :) On 13-10-25 04:23 AM, Martin Renvoize wrote:

I'de agree with Zeno's timeframe.

That give's people time to port their customisation to the new theme without adding too much work for the developers in coding for three theme's simultaneously. We, at PTFS Europe have been enabling CCSR by default for new installs, and often 'upgrading' to CCSR during koha upgrades. Not everyone is going to suddenly be upgraded at the same time, so it shouldn't be too harsh a problem to take OPAC customisations into account during an upgrade.

As for Paul's comments, Robin has pretty much covered it. Bootstrap is a framework of well supported JS and CSS that we could not hope to create and maintain for ourselves, not using one of these frameworks (Bootstrap, Foundation) in the foreseeable future is just plain silly given the work it takes to create fully responsive themes the meet current expectations. Using bootstrap is much more likely to pass tests than us reinventing the wheel.

So.. all in all the bootstrap theme gets my vote!

Martin Renvoize Software Engineer, PTFS Europe Ltd Content Management and Library Solutions Skype: Landline: 0203 286 8685 Mobile: 07725985636

http://www.ptfs-europe.com

On 25 October 2013 08:47, Zeno Tajoli <z.tajoli@cineca.it <mailto:z.tajoli@cineca.it>> wrote:

Hi to all,

Il 24/10/2013 17:04, Galen Charlton ha scritto:

Another point for discussion: I propose that the Bootstrap OPAC theme be made the installation default for 3.14, and that we announce deprecation of the prog and CCSR themes at the same time, with those themes to be removed (or split into separate packages, if somebody really wants to maintain one or both) in 3.16.

my position on the topic is: -- Bootstrap OPAC theme as default in 3.14 -- Themes prog and CCSR deprecated from 3.14 -- Themes prog and CCSR deleted from 3.18 [two release cycle]

So there is more time to port opac costumixations.

Bye Zeno Tajoli

-- Dr. Zeno Tajoli Dipartimento Gestione delle Informazioni e della Conoscenza z.tajoli@cineca.it <mailto:z.tajoli@cineca.it> fax +39 02 2135520 <tel:%2B39%2002%202135520> CINECA - Sede operativa di Segrate

_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto: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/

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

-- Philippe Blouin, Responsable du développement informatique Tél. : (888) 604-2627 philippe.blouin@inLibro.com <mailto:philippe.blouin@inLibro.com> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>

I hope everyone understands that a new default theme would *only* affect new installations, and that the old themes would continue to be maintained and available until the agreed deprecation time.

We have worked with two available themes for a while now. We can work with three for as long as necessary. I just hope it not necessary for long. That's the thing, I got fixes in the pipeline that only modify the /prog/ path. Will I need to redo them all for the other path? How has

Hi, the RM been managing these situations in 3.13->3.14 ? And for the future, if I hear that bootstrap is THE solution, we'll code only for it, and offer only bootstrapt fixes for the master. Mind you, I don't even know how different is bootstrap code from /prog/, but a +20% in dev time + doubling the testing time (very rough estimate) to get two paths out can kill our community budget, so maintaining two versions it probably out of our reach for us. In short, I do not worry about our installations. We'll redo all our libraries css, etc... (ok, yeah, it's a pain :)), but I would like some clarification on the community work and the difference in feature/fix between the three versions in the short future. Best regards, Blou

Hi, On Fri, Oct 25, 2013 at 6:01 AM, Philippe Blouin < philippe.blouin@inlibro.com> wrote:

I hope everyone understands that a new default theme would *only* affect new installations, and that the old themes would continue to be maintained and available until the agreed deprecation time.

We have worked with two available themes for a while now. We can work with three for as long as necessary. I just hope it not necessary for long.

That's the thing, I got fixes in the pipeline that only modify the /prog/ path. Will I need to redo them all for the other path? How has the RM been managing these situations in 3.13->3.14 ?

Thus far I have been writing and pushing follow-ups patches in cases where it was obvious how a patch written for prog should be applied to the Bootstrap theme. If a patch is too complicated to do that, most of the time I will push the prog patch and open a bug for the corresponding change to be made for Bootstrap. However, I anticipate that during the 3.16 cycle there may be cases where a major piece of functionality added to prog may need to be held back until a Bootstrap implementation is available, although I will assist in minimizing the number of times that happens.

And for the future, if I hear that bootstrap is THE solution, we'll code only for it, and offer only bootstrapt fixes for the master. Mind you, I don't even know how different is bootstrap code from /prog/, but a +20% in dev time + doubling the testing time (very rough estimate) to get two paths out can kill our community budget, so maintaining two versions it probably out of our reach for us.

For new work, I recommend coding for Bootstrap first. 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