I'm +0.5 to removal. Thanks, all. -- Mike Rylander | Executive Director | Equinox Open Library Initiative | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@equinoxinitiative.org | web: http://equinoxinitiative.org
On Wed, Aug 29, 2018 at 1:09 PM Bill Erickson <beric...@gmail.com> wrote: > > For the reasons mentioned by Ben and Galen, I am also +1 for removal. > > I also prefer we remove before bug squashing week so we can get it out of the > way, with option to revert later if some new serious problem surfaces. > > And just to have some skin in the game, between Kyle and I, we will resolve > LP#1511742. > > -b > > On Wed, Aug 29, 2018 at 12:50 PM Ben Shum <b...@evergreener.net> wrote: >> >> One other idea that just popped into my head that we might want to >> discuss is potentially keeping XUL in Evergreen, but deciding to end >> all the i18n processes related to it. By now, strings should be >> relatively static, so template changes should no longer be occurring >> (though sometimes I've been surprised or bug fixes change something). >> >> This separates my i18n concerns from the primary XUL retention question. >> >> I still vote "yes" though. >> >> -- Ben >> On Wed, Aug 29, 2018 at 12:21 PM Ben Shum <b...@evergreener.net> wrote: >> > >> > I vote "yes" to getting rid of XUL now. >> > >> > From i18n side of things, we've been working around the problems with >> > running the translation process with our old XUL code by using the >> > older template toolkit set from Ubuntu 14.04. That Ubuntu version is >> > EOL next year April 2019, and I'd rather not have the community >> > dealing with translation support for the old XUL code (which is >> > already unsupported by modern template toolkit) past that point. If >> > we retain XUL in 3.2 and keep supporting it through late 2019 (as we >> > usually do the 15 months of support), then we'll have to build in >> > additional carryover processes for the release builders and >> > maintainers to deal with. >> > >> > Things are already going to be complicated enough moving forward with >> > i18n translation support in the new ang6, I'd prefer to keep us >> > looking ahead rather than continuing to half-support broken legacy >> > processes. >> > >> > -- Ben >> > On Wed, Aug 29, 2018 at 12:08 PM Kathy Lussier <kluss...@masslnc.org> >> > wrote: >> > > >> > > Based on what I know today, I reluctantly vote against removal. There >> > > are some bugs in that list with no other current workaround except to >> > > use the xul client to perform an action. I would happily change my vote >> > > in a couple of weeks if more progress were made on some of the >> > > webstaffblockers. >> > > >> > > Kathy >> > > >> > > -- >> > > Kathy Lussier >> > > Project Coordinator >> > > Massachusetts Library Network Cooperative >> > > (508) 343-0128 >> > > kluss...@masslnc.org >> > > >> > > >> > > >> > > On Wed, Aug 29, 2018 at 11:57 AM Bill Erickson <beric...@gmail.com> >> > > wrote: >> > >> >> > >> Devs, >> > >> >> > >> I'd like to have an informal vote on whether we should remove (well, >> > >> disable) the XUL client in 3.2. Delaying the decision is complicating >> > >> the release process. If it's clear which way the wind is blowing, we >> > >> can set a date for the final vote and patching. >> > >> >> > >> Knowing what you know today about outstanding webstaff blockers (a few >> > >> were just added), would you vote to proceed with XUL removal? Can I >> > >> get a show of hands, yea or nay? >> > >> >> > >> Thanks, >> > >> >> > >> -b >> > >> >> > >> > >> > -- >> > Benjamin Shum >> > Evergreener >> >> >> >> -- >> Benjamin Shum >> Evergreener
