| Time |
Nick |
Message |
| 07:05 |
|
agoben joined #evergreen |
| 07:05 |
|
bos20k joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:44 |
|
sandbergja joined #evergreen |
| 09:14 |
|
bdljohn left #evergreen |
| 09:14 |
|
jamesrf joined #evergreen |
| 09:37 |
|
terran joined #evergreen |
| 09:50 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-02-06T09:48:51,496761679-0500 -0> |
| 09:52 |
|
yboston joined #evergreen |
| 09:58 |
|
jvwoolf joined #evergreen |
| 10:13 |
|
Stompro joined #evergreen |
| 10:41 |
|
jwoodard joined #evergreen |
| 10:42 |
|
khuckins joined #evergreen |
| 11:09 |
|
dpearl joined #evergreen |
| 11:40 |
bshum |
csharp: I was just reading bug 1812733 and it references a new feature bug 1714070 which is only targeted towards 3.3-beta1 currently |
| 11:40 |
pinesol |
Launchpad bug 1812733 in Evergreen "Error in upgrade script for Parent/Guardian feature" [High,New] https://launchpad.net/bugs/1812733 |
| 11:40 |
pinesol |
Launchpad bug 1714070 in Evergreen "Web Client: Parent/Guardian Field vs Secondary Identification" [Wishlist,Fix committed] https://launchpad.net/bugs/1714070 |
| 11:40 |
bshum |
But the upgrade script bug is targeted at 3.2.4 |
| 11:41 |
bshum |
I'm thinking it's a bad target and we can roll it in as a change to the original upgrade script from 1714070 to fix things up? |
| 11:41 |
bshum |
Since 3.3 is not released |
| 11:41 |
csharp |
bshum: yeah - feel free to change the target |
| 11:45 |
|
Christineb joined #evergreen |
| 11:59 |
Bmagic |
Anyone here already dealt with an Acq issue when loading MARC and creating a PO where an error occurrs "ITEM_BARCODE_EXISTS" - the system is setup to autogenerate the barcodes |
| 12:01 |
|
jihpringle joined #evergreen |
| 12:06 |
|
mcgriff joined #evergreen |
| 12:18 |
|
sandbergja joined #evergreen |
| 12:19 |
Bmagic |
It's probably the lack of library settings for the barcode generation |
| 12:49 |
csharp |
@band add The Barcode Generation |
| 12:49 |
pinesol |
csharp: Band 'The Barcode Generation' added to list |
| 12:50 |
Bmagic |
lol |
| 12:54 |
csharp |
Bmagic: relevant? https://bugs.launchpad.net/evergreen/+bug/708416 |
| 12:54 |
pinesol |
Launchpad bug 708416 in Evergreen "potential for bad interaction between cataloging and acquisitions auto-barcode generators" [Low,Incomplete] |
| 12:55 |
Bmagic |
csharp++ |
| 12:55 |
Bmagic |
yeah, that gives me some ideas |
| 12:55 |
csharp |
awesome |
| 12:57 |
Bmagic |
wow that is old |
| 12:57 |
Bmagic |
milestone 2.0.1 lol |
| 12:59 |
Bmagic |
dbwells++ # 3.3 |
| 13:02 |
jeffdavis |
I wonder if anyone would be willing to look at bug 1715767 sometime soon - it's been sitting there for awhile and I'd love to get it in 3.3 if possible |
| 13:02 |
pinesol |
Launchpad bug 1715767 in Evergreen "Allow others to use my account (privacy waiver)" [Wishlist,New] https://launchpad.net/bugs/1715767 |
| 13:08 |
jeffdavis |
dbwells: I think bug 1801191 is a bug affecting existing releases, not a feature request |
| 13:08 |
pinesol |
Launchpad bug 1801191 in Evergreen "Recalls can extend loan period" [Wishlist,New] https://launchpad.net/bugs/1801191 |
| 13:10 |
|
jvwoolf joined #evergreen |
| 13:32 |
|
derekz joined #evergreen |
| 13:46 |
berick |
dbwells++ |
| 13:46 |
|
yboston joined #evergreen |
| 13:58 |
dbwells |
jeffdavis: I think you are right, and I can see it either way. It just felt a little more on the side of "let's make this better" rather than "let's fix what's broken", especially given that the current behavior has existed for quite a while. |
| 14:05 |
jeffdavis |
I was assuming that the current behavior is unintended and it just hadn't been noticed. |
| 14:06 |
csharp |
jeffdavis: I'm interested in testing patron privacy waivers, but I'm seeing several file conflicts with master. I'm fixing them locally, but you might want to rebase with master. |
| 14:07 |
jeffdavis |
csharp: ah, branch drift. Will do, thanks. :) |
| 14:08 |
csharp |
:-) |
| 14:13 |
* csharp |
is going to have to miss the dev meeting - 3:00 is always kid-pickup hour :-/ |
| 14:14 |
JBoyer |
the time is probably negotiable, is there a suggestion that could be brought up? |
| 14:15 |
JBoyer |
(didn't they used to be at 1 or 2 Eastern?) |
| 14:18 |
dbwells |
We have at times in the past done polls to pick the time, but I think they all started turning out the same, so we stopped. Time to do at least one again, it appears. |
| 14:23 |
csharp |
1 or 2 EST would be better for me in general, but if I'm the only one this affects, probably not worth it |
| 14:37 |
|
Dyrcona joined #evergreen |
| 14:39 |
|
mdriscoll joined #evergreen |
| 14:41 |
|
tlittle joined #evergreen |
| 14:44 |
JBoyer |
Well, my schedule generally sees me leaving at 3:30 so I wouldn't argue about pushing it back towards 1-2 |
| 14:51 |
berick |
+1 to new poll. 1-2-ish is good for me too |
| 14:52 |
|
stephengwills joined #evergreen |
| 14:55 |
* berick |
adds note to agenda |
| 14:59 |
|
abowling joined #evergreen |
| 14:59 |
gmcharlt |
yeah, enough time has passed since the standing time was set |
| 14:59 |
gmcharlt |
so it may well not just be you, csharp |
| 15:01 |
abneiman |
Not opposed to moving times, but I am noting that the Outreach Committee meeting is currently 1st Wednesdays at 2pm |
| 15:02 |
rhamby |
I'm biased as I'd like the two to not overlap since I generally at least pay attention to the dev meetings and abneiman probably even more so. |
| 15:03 |
gmcharlt |
is somebody raring to run the meeting? I'm willing to |
| 15:03 |
|
yboston joined #evergreen |
| 15:04 |
* Dyrcona |
is coming down with something and may fade out, so if someone else would run it.... |
| 15:04 |
gmcharlt |
ok |
| 15:04 |
gmcharlt |
#startmeeting Evergreen Development Meeting, 6 February 2019 |
| 15:04 |
pinesol |
Meeting started Wed Feb 6 15:04:43 2019 US/Eastern. The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:04 |
pinesol |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 15:04 |
|
Topic for #evergreen is now (Meeting topic: Evergreen Development Meeting, 6 February 2019) |
| 15:04 |
pinesol |
The meeting name has been set to 'evergreen_development_meeting__6_february_2019' |
| 15:04 |
gmcharlt |
#info Agenda is https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2019-02-06 |
| 15:05 |
gmcharlt |
#topic Introductions |
| 15:05 |
|
Topic for #evergreen is now Introductions (Meeting topic: Evergreen Development Meeting, 6 February 2019) |
| 15:05 |
Dyrcona |
#info Dyrcona is Jason Stephenson, CW MARS |
| 15:05 |
gmcharlt |
#info gmcharlt = Galen Charlton, EOLI |
| 15:05 |
dpearl |
#info dpearl is Dan Pearl, CWMARS Inc. |
| 15:05 |
abowling |
#info abowling is Adam Bowling, Emerald Data Networks |
| 15:05 |
remingtron |
#info remingtron is Remington Steed, Hekman Library (Calvin College) |
| 15:05 |
JBoyer |
#info JBoyer = Jason Boyer, Evergreen Indina, ISL |
| 15:05 |
miker |
#info miker = Mike Rylander, EOLI |
| 15:05 |
dbwells |
#info dbwells is Dan Wells, Hekman Library (Calvin College) |
| 15:05 |
abneiman |
#info abneiman is Andrea Buntz Neiman, EOLI |
| 15:05 |
berick |
#info berick Bill Erickson, KCLS |
| 15:06 |
stephengwills |
#info Stephengwill working with Maine Balsam Library Consortium |
| 15:06 |
rhamby |
#info rhamby is Rogan Hamby, EOLI |
| 15:06 |
jeff |
#info jeff = Jeff Godin, Traverse Area District Library (TADL) |
| 15:07 |
Bmagic |
#info Bmagic = Blake GH, MOBIUS |
| 15:07 |
gmcharlt |
#topic Action items from previous meeting |
| 15:07 |
|
Topic for #evergreen is now Action items from previous meeting (Meeting topic: Evergreen Development Meeting, 6 February 2019) |
| 15:08 |
gmcharlt |
berick, JBoyer, csharp: where do we stand with a Hatch release? |
| 15:08 |
JBoyer |
It lives. |
| 15:08 |
berick |
indeed |
| 15:08 |
JBoyer |
Thanks to gsams testing |
| 15:08 |
JBoyer |
gsams++ |
| 15:08 |
gmcharlt |
gsams++ |
| 15:09 |
gmcharlt |
#info New Hatch release has been made |
| 15:09 |
abowling |
berick++ |
| 15:09 |
abowling |
jboyer++ |
| 15:09 |
abowling |
gsams++ |
| 15:09 |
gmcharlt |
berick, Bmagic: where stands the Dymo branch? |
| 15:09 |
berick |
I hope to spend some time on that this and next week, in fact |
| 15:10 |
gmcharlt |
great |
| 15:10 |
gsams |
I've been testing that as well this week |
| 15:10 |
gmcharlt |
I'll just carry the action item forward then |
| 15:10 |
gmcharlt |
#action Bmagic, berick, gsams et al will poke more on the Dymo branch |
| 15:10 |
berick |
gsams++ great |
| 15:10 |
gmcharlt |
#topic OpenSRF release |
| 15:10 |
|
Topic for #evergreen is now OpenSRF release (Meeting topic: Evergreen Development Meeting, 6 February 2019) |
| 15:11 |
gmcharlt |
#info OpenSRF 3.1.0 was released on 2019-01-17 |
| 15:11 |
gmcharlt |
anybody seeing issues running it (and not just the websocketd stuff) in production? |
| 15:11 |
miker |
no me! :) |
| 15:12 |
csharp |
we're running it in a test environment that's pretty well-used - no complaints yet |
| 15:12 |
Dyrcona |
I haven't used it in production, but it seems to work fine on my VMs, even with Evergreen 3.0. |
| 15:12 |
csharp |
(OpenSRF 3.1.0 + websocketd) |
| 15:12 |
gmcharlt |
ok |
| 15:12 |
JBoyer |
We actually have master running in production here and haven't noticed any issues |
| 15:12 |
Dyrcona |
I have backported the websocketd stuff to OpenSRF 3.0 and that works fine in production. |
| 15:13 |
* JBoyer |
was impatient for websocketd |
| 15:13 |
* csharp |
is impatient for it now |
| 15:13 |
gmcharlt |
I've got some questions about future directions (in addition to the topics Dyrcon's raised for later) |
| 15:13 |
gmcharlt |
first - are folks OK with the removal of Tahr being targeted for 3.1.1 (as opposed to a 3.2.0)? |
| 15:14 |
Dyrcona |
I'm fine with that. I had hoped it would be gone by 3.1.0, myself. |
| 15:14 |
gmcharlt |
related - any reasons pro or con for making 3.1.0 be the minimum version for Evergreen 3.3? |
| 15:14 |
dbwells |
We are running a December master of OpenSRF in production, so not exactly 3.1.0, but pretty close. No complaints! |
| 15:14 |
berick |
no objection to Tahr support removal |
| 15:14 |
csharp |
took me a second to realize that "Tahr" is referring to Ubuntu' 14.04 |
| 15:14 |
gmcharlt |
and another q: any reason not to remove the apache2-websocket stuff from the core installation instructions for 3.1.1? |
| 15:15 |
berick |
csharp: me too :) |
| 15:15 |
csharp |
I think it has to be done - it's EOL as of April |
| 15:15 |
abowling |
it's not so trusty anymore ;) |
| 15:15 |
berick |
zing |
| 15:15 |
csharp |
abowling++ |
| 15:15 |
Dyrcona |
heh. |
| 15:15 |
JBoyer |
abowling++ |
| 15:15 |
gmcharlt |
just a pile o'bones... |
| 15:15 |
Dyrcona |
abowling++ |
| 15:15 |
miker |
gmcharlt: should we consider pinning a websocketd version for each opensrf release going forward? |
| 15:15 |
berick |
gmcharlt: +1 to removing apache2-websocket from docs. it's complicating the setup. |
| 15:15 |
csharp |
gmcharlt: +1 for websocketd-only |
| 15:16 |
miker |
I mean, it's a low risk, but options changing under us... |
| 15:16 |
JBoyer |
+1 to removing 14.04 support, |
| 15:16 |
csharp |
it's so frickin' simple, my mom could do it! |
| 15:16 |
gmcharlt |
and my final small question for now: any reason why starting up websocketd could be done as a new osrf_control command? |
| 15:16 |
Dyrcona |
+1 for dropping apache2-websocket |
| 15:16 |
JBoyer |
and +1 to dumping apache-websockets |
| 15:16 |
dbwells |
+1 to removing the apache2-websockets instructions. I am enjoying not killing random stuck Apache processes every few days. |
| 15:16 |
miker |
and +1 to both removing 14.04 and apache-websockets |
| 15:16 |
gmcharlt |
obviously that would bake in running it as the opensrf user, but that doesn't seem like a big deal |
| 15:16 |
* csharp |
imagines his mom actually trying to install websocketd on a Linux server |
| 15:16 |
abowling |
+1 removing apache2-websocket and tahr |
| 15:17 |
stephengwills |
balsam runs 3.1.8 w/ apache-websockets. will need help on ow to convert to new method. is Balsam alone in this? |
| 15:17 |
abowling |
csharp++ |
| 15:17 |
csharp |
stephengwills: nearly everyone is still running it - not alone by far |
| 15:17 |
Dyrcona |
gmcharlt: Do you envision starting websocketd as part of --start-all or would it be an entirely separate command? |
| 15:17 |
berick |
gmcharlt: i had considered adding it as an osrf_control command, so no objections there. I also run it as user 'opensrf' in the systemd setup, fwiw. |
| 15:17 |
JBoyer |
I'm fairly happy with it being a separate systemd service. |
| 15:18 |
csharp |
I think it should be separate |
| 15:18 |
Dyrcona |
conversion to websocketd is rather straight forward. |
| 15:18 |
gmcharlt |
Dyrcona: I think either a separate command or maybe adding a flag to opensrf{_core?}.xml indicating that it shoudl be started via a --startl-all |
| 15:18 |
miker |
Dyrcona: IMO, since it opens a new listening port, rather than actively connecting to /something else/ (xmpp server), I'd be in favor of a separate command |
| 15:18 |
csharp |
--start-lol |
| 15:18 |
Dyrcona |
gmcharlt: OK. I ask because I start websocketd via sudo to read our SSL certs. |
| 15:18 |
miker |
csharp: the irony is that you just decremented a great joke ;) |
| 15:19 |
csharp |
heh |
| 15:19 |
Dyrcona |
I'm for keeping it separate, personally. |
| 15:19 |
gmcharlt |
miker: re websocketd versions, strikes me as the sort of thing to note compatibility when doing new releases of OpenSRF |
| 15:19 |
gmcharlt |
though hopefully short of a full pin |
| 15:20 |
miker |
Dyrcona: are you using haproxy? (nginx localhost might free you from that) |
| 15:20 |
JBoyer |
It also hinges on another version actually being released... :/ |
| 15:20 |
miker |
gmcharlt: sure, I'm more raising the question than advocateing |
| 15:20 |
gmcharlt |
JBoyer: happy news on that front - I see that commits are showing up in websocketd's github repo again |
| 15:20 |
miker |
JBoyer: point |
| 15:20 |
JBoyer |
Ah, very nice. |
| 15:20 |
miker |
oh, good! |
| 15:20 |
Dyrcona |
miker: No. We have ldirectord and no proxy for the SSL. Our web staff clients connect to the high-numbered port directly. |
| 15:21 |
* JBoyer |
wasn't looking forward to learning Go. ;) |
| 15:21 |
Dyrcona |
We're a bit odd in that respect. |
| 15:21 |
miker |
what's one more language? |
| 15:21 |
gmcharlt |
ah, and in particular 0.3.1 was released 9 days ago |
| 15:22 |
gmcharlt |
or prereleased, anyway |
| 15:22 |
berick |
JBoyer: hopefully we never have to |
| 15:22 |
gmcharlt |
oh, with .debs available |
| 15:22 |
gmcharlt |
ok, so summarizing the discussion |
| 15:22 |
gmcharlt |
#agreed patch for removing Trusty Tahr support will be applied for a 3.1.1 release |
| 15:23 |
gmcharlt |
#agreed apache2-websockets instructions will be removed or seriously deemphasized for a 3.1.1 release |
| 15:23 |
gmcharlt |
#action gmcharlt will open a bug to continue discussions about osrf_control or other means of websocketd startup management |
| 15:24 |
gmcharlt |
so I think that leaves the question of thoughts on having 3.1.x be the minimum required version for Evergreen 3.3 |
| 15:25 |
JBoyer |
If there's anything about 3.3 that would be made simpler by also dropping 14.04 that would be a good time to sync them up. |
| 15:25 |
gmcharlt |
on the one hand, there's no actual technical requirement yet, although I _might_ write a patch to take advantage of the new 503 status to make the OPAC display a sensible message if open-ils.search or open-ils.storage gets overcapacity |
| 15:25 |
Dyrcona |
I don't have a problem with that, but I think it does actually work with 3.0, doesn't it? |
| 15:25 |
gmcharlt |
on the other hand - requiring it woudl be a way of encouraging folks to switch to websocketd |
| 15:26 |
Dyrcona |
JBoyer: We do not want to ship 3.3 with support for Trusty Tahr, since 14.04 is EOL in April. |
| 15:26 |
gmcharlt |
(and I'm content to open a bug and punt the discussion over there) |
| 15:27 |
gmcharlt |
which I'll do |
| 15:27 |
miker |
gmcharlt: one question |
| 15:27 |
gmcharlt |
miker: yeah? |
| 15:27 |
miker |
actually, nevermind |
| 15:27 |
* gmcharlt |
exhales |
| 15:27 |
miker |
heh |
| 15:27 |
Dyrcona |
:) |
| 15:27 |
gmcharlt |
#action gmcharlt will open bug about whether to require OpenSRF 3.1.x for Evergreen 3.3 |
| 15:27 |
JBoyer |
Dyrcona, I see, makes sense with their release cadences that it's only really a Q for OSRF. |
| 15:28 |
miker |
once we start builing binaries (ha!) I'll ask :) |
| 15:28 |
gmcharlt |
so that brings us to |
| 15:28 |
miker |
building, even |
| 15:28 |
gmcharlt |
#topic Evergreen release |
| 15:28 |
|
Topic for #evergreen is now Evergreen release (Meeting topic: Evergreen Development Meeting, 6 February 2019) |
| 15:28 |
gmcharlt |
dbwells? |
| 15:29 |
dbwells |
An update was sent to the general list this morning, so nothing to add beyond that. |
| 15:29 |
dbwells |
Any questions? |
| 15:30 |
dbwells |
Then my plan to reduce my role in this meeting worked brilliantly. |
| 15:30 |
Dyrcona |
:) |
| 15:30 |
gmcharlt |
#info Evergreen 3.3 release update from dbwells: http://libmail.georgialibraries.org/pipermail/open-ils-general/2019-February/015605.html |
| 15:30 |
JBoyer |
dbwells++ |
| 15:30 |
dbwells |
gmcharlt++ # thanks |
| 15:30 |
stephengwills |
lol dbwells++ |
| 15:30 |
abowling |
dbwells++ |
| 15:30 |
Dyrcona |
dbwells++ |
| 15:30 |
gmcharlt |
quick, somebody come up with a question that will take dbwells 15 minutes to answer! |
| 15:30 |
jeff |
dbwells++ |
| 15:31 |
gmcharlt |
(seriously, any questions for him before we move on?) |
| 15:31 |
berick |
i have a question.. |
| 15:31 |
berick |
(just in time) |
| 15:31 |
berick |
generally for 3.3, any plans to furhter excise XUL bits? |
| 15:31 |
berick |
or do we retain status quo for a bit |
| 15:32 |
gmcharlt |
I for one don't have time to do anything comprehensive dissection |
| 15:33 |
dbwells |
If folks are generally amenable to more removal, I can throw some tuits that way. |
| 15:33 |
gmcharlt |
I'm in support of that |
| 15:34 |
csharp |
+1 to de-XUL-ification |
| 15:34 |
berick |
no strong preference, but will be good to reach some consensus there, since XUL is technically usable in 3.2. Is 3.3 where it fully stops working, i guess is the question. |
| 15:34 |
JBoyer |
+1 |
| 15:34 |
* csharp |
is happy to help (at least with testing) |
| 15:34 |
Dyrcona |
Did we ever set a release for removal of XUL? |
| 15:34 |
csharp |
PINES is running 3.2 without XUL (so far) - I think that's a good indicator that we can leave it behind |
| 15:34 |
* Dyrcona |
doesn't remember. |
| 15:35 |
berick |
Dyrcona: iirc, 3.2 was the last xul milestone discussed |
| 15:36 |
dbwells |
I believe the push was to defeat all webstaffblocker bugs before conceding to removal. There are just three such bugs at the moment, so that seems doable. |
| 15:36 |
gmcharlt |
yeah, that matches my memory |
| 15:37 |
sandbergja |
I have another 3.3 question: according to this, all new UIs should be in Angular as of 3.3: https://wiki.evergreen-ils.org/doku.php?id=dev:browser_staff:angjs_to_ang_migration#migration_timeline_proposal |
| 15:38 |
sandbergja |
Is that still the case? |
| 15:38 |
sandbergja |
And more specifically, should I rewrite this in Angular: https://bugs.launchpad.net/evergreen/+bug/1790727 |
| 15:38 |
pinesol |
Launchpad bug 1790727 in Evergreen "New feature: add a daily schedule view of existing bookings" [Wishlist,New] |
| 15:38 |
berick |
sandbergja: that's not the case |
| 15:38 |
berick |
well, wait |
| 15:38 |
* berick |
re-reads |
| 15:39 |
berick |
sandbergja: sorry, i read that as /all/ UI's... |
| 15:39 |
berick |
i do think new UI's should be implemented in Angular if it's reasonable to do so. |
| 15:39 |
miker |
(re Angular, berick, I plan to have your Server Admin page in place RSN, so that I can stay true to "new UIs in Angular7") |
| 15:40 |
jeffdavis |
sandbergja: how big of a burden would it be for you to reimplement? |
| 15:40 |
miker |
s/page/branch |
| 15:40 |
berick |
miker++ |
| 15:40 |
sandbergja |
jeffdavis: not sure yet; I'll do some exploration this afternoon |
| 15:41 |
jeffdavis |
Sitka was hoping to test the bookings daily schedule this week and looking forward to having it in 3.3 |
| 15:41 |
berick |
i'd say at this stage there's some flexibility |
| 15:41 |
berick |
i mean if the code is already written... |
| 15:41 |
sandbergja |
yeah, I just barely missed 3.2 :-( |
| 15:41 |
gmcharlt |
agreeded - especially since it's a relatively small (codewise) addition to an existing AngularJS app |
| 15:42 |
sandbergja |
Okay, I'll plan to keep that targeted for 3.3 then, but still do some exploration about re-implementing in Angular, since it will have to happen eventually anyway |
| 15:42 |
gmcharlt |
sandbergja++ |
| 15:42 |
sandbergja |
If that works for y'all |
| 15:43 |
dbwells |
sandbergja: You have two weeks, I don't see the problem ;) No, I agree that this seems fine :) |
| 15:43 |
JBoyer |
sandbergja++ |
| 15:43 |
berick |
+1 |
| 15:43 |
berick |
heh |
| 15:43 |
gmcharlt |
looing at the webstaffblocker bugs, they have active branches, so I think it would be reasonable to paln that all three will be fixed by the release of 3.3.0 |
| 15:43 |
gmcharlt |
so back to the original question... I think we can be free to taken up dbwells' offer of tuits to disable more of XUL |
| 15:44 |
gmcharlt |
*to take up |
| 15:44 |
gmcharlt |
any objections? |
| 15:44 |
dbwells |
gmcharlt: sounds good! |
| 15:45 |
Dyrcona |
No objection from me. |
| 15:45 |
gmcharlt |
so |
| 15:45 |
gmcharlt |
#agreed we're amenable to XUL removal continuing in for 3.3 to a degree that it may no longer be an option for use |
| 15:45 |
gmcharlt |
#action dbwells will contribute time to XUL removal prior to release |
| 15:46 |
* berick |
pours some Scotch on the ground |
| 15:46 |
gmcharlt |
so moving on |
| 15:46 |
gmcharlt |
#topioc Hatch |
| 15:46 |
gmcharlt |
#info Hatch version 0.2.0 released including Firefox support released. |
| 15:46 |
gmcharlt |
anything else to say about Hatch that wasn't already? |
| 15:46 |
berick |
nothing from me |
| 15:46 |
JBoyer |
Nothing from me. |
| 15:47 |
gmcharlt |
ok |
| 15:47 |
gmcharlt |
on to new business |
| 15:47 |
gmcharlt |
#topic Should we remove Java libs from OpenSRF and Evergreen? |
| 15:47 |
|
Topic for #evergreen is now Should we remove Java libs from OpenSRF and Evergreen? (Meeting topic: Evergreen Development Meeting, 6 February 2019) |
| 15:48 |
Dyrcona |
Seeing as Java no longer builds, I say yes. |
| 15:48 |
berick |
both are way behind w/ recent osrf changes |
| 15:48 |
gmcharlt |
are there any known uses of that code? |
| 15:48 |
jeffdavis |
Is it worth polling the broader EG community (via the mailing lists I guess) to see if anyone is still using them somehow? |
| 15:48 |
berick |
jeffdavis: i'd say yet |
| 15:48 |
berick |
er, yes |
| 15:49 |
|
tlittle joined #evergreen |
| 15:49 |
gmcharlt |
yeah, it is at least a good courtesy |
| 15:49 |
gmcharlt |
(and there's always the chance, however unlikely, that somebody has been maintaining a Java binding quietly who might speak up) |
| 15:49 |
JBoyer |
It would be good to emphasize that they're going away unless someone wants to take a more active role in their maintenance. |
| 15:50 |
* Dyrcona |
agrees with JBoyer. |
| 15:50 |
* gmcharlt |
has no objection to framing it that way |
| 15:50 |
gmcharlt |
(it would be a 3.2.x thing, though) |
| 15:51 |
* abowling |
is thinking of the judge in My Cousin Vinny to anyone who wants to keep it: That is a lucid, intelligent, well-thought out objection...Thank you, your honor...Overruled |
| 15:51 |
gmcharlt |
Dyrcona: shall you send out such a notification/query? |
| 15:51 |
Dyrcona |
Sure! |
| 15:51 |
Dyrcona |
Maybe not today, but by Friday at the latest. |
| 15:52 |
gmcharlt |
#action Dyrcona will query the dev community to see if any users of OpenSRF's Java bindings are still out there? |
| 15:52 |
gmcharlt |
moving on |
| 15:52 |
gmcharlt |
#topic Should we update or remove Python libs from OpenSRF and Evergreen? |
| 15:52 |
|
Topic for #evergreen is now Should we update or remove Python libs from OpenSRF and Evergreen? (Meeting topic: Evergreen Development Meeting, 6 February 2019) |
| 15:53 |
Dyrcona |
It's a different situation from Java, in that it builds and srfsh.py works on Ubuntu 18.04, but not Ubuntu 16.04, and IIRC, Syrup uses it, but Syrup is abandonware. |
| 15:53 |
Dyrcona |
I haven't tested it on Debian since Debian 7, so I don't know if Python works on Stretch or Jessie. |
| 15:53 |
stephengwills |
I just used marc_convert.py for an on-boarding last week. Does that require any Osrf or Eg libs? or is it stand alone? |
| 15:54 |
Dyrcona |
And, then, there's another wrinkle. Our Python libs are version 2.7 compatible, and Python 2.7 is EOL on Jan 1, 2020. |
| 15:54 |
berick |
i'm pretty sure it's not 100% with perl/c osrf, but I also have not looked at it in a long time |
| 15:55 |
berick |
100% compatible, i mean |
| 15:55 |
Dyrcona |
stephengwills: Did you configure OpenSRF and Evergreen with --enable-python? |
| 15:55 |
gmcharlt |
my inclination there would be to also do a community query, but maybe frame this one as being (initially) a call for a Python maintainer |
| 15:56 |
JBoyer |
I'm +1 to that. "Happens to work in certain versions of certain OSes" is a pretty rough claim to support. |
| 15:57 |
gmcharlt |
if folks are amenable, I can save Dyrcona some effort and make that query |
| 15:57 |
miker |
berick: I'm nearly 100% sure it's not, currently, for some message types. fwiw |
| 15:57 |
berick |
miker: yeah... |
| 15:57 |
gmcharlt |
(and perhaps help Dyrcona avoid coming off as the sole chopper-of-bindings ;) ) |
| 15:57 |
Dyrcona |
:) |
| 15:57 |
miker |
chunking, bundling, and now 503 |
| 15:57 |
gmcharlt |
yeah |
| 15:58 |
gmcharlt |
I'll run with that |
| 15:58 |
Dyrcona |
Well, if we keep Python, I'd suggest we update the code to be Python 3.x (which is much easier than it sounds) and keep it up to date with latest changes. |
| 15:58 |
gmcharlt |
#action gmcharlt will send query about (a) whether there are any active users of Evergreen's Python bindings and (b) volunteers to help maintain it and ideally upgrade to 3.x |
| 15:58 |
gmcharlt |
so moving on |
| 15:59 |
gmcharlt |
#topic Miscellenaous |
| 15:59 |
|
Topic for #evergreen is now Miscellenaous (Meeting topic: Evergreen Development Meeting, 6 February 2019) |
| 15:59 |
gmcharlt |
#info Beware update to Angular 7 requires npm update (or rm -rf node_modules; npm install) in Open-ILS/src/eg2 |
| 15:59 |
gmcharlt |
berick: anything more to say about that? |
| 16:00 |
berick |
just wanted to give a heads up |
| 16:00 |
gmcharlt |
berick++ |
| 16:00 |
Dyrcona |
berick++ |
| 16:00 |
gmcharlt |
next up - doing a poll to see if a new standing time for the dev meeting would work better for folks |
| 16:00 |
* Dyrcona |
wants to look at more of the Angular bugs. |
| 16:01 |
gmcharlt |
it's been a while since the question was asked... so who wants to run the poll? |
| 16:01 |
remingtron |
I'll do it! |
| 16:01 |
gmcharlt |
remingtron++ |
| 16:02 |
gmcharlt |
#action remingtron will run poll to see if a new standing day/time for the dev meeting would be better |
| 16:02 |
gmcharlt |
#info Hope to get some movement on bug 1811288 since it will impact most of the active Angular dev branches. |
| 16:02 |
pinesol |
Launchpad bug 1811288 in Evergreen "Angular Fieldmapper Editor should use combobox for linked fields" [Medium,New] https://launchpad.net/bugs/1811288 |
| 16:02 |
gmcharlt |
berick: regarding that, both phasefx_ and I have need to poke at the new combobox anyway, so we can offer tuits |
| 16:03 |
berick |
gmcharlt++ |
| 16:03 |
berick |
great, holler if I can help |
| 16:03 |
JBoyer |
That branch just puts it in the sandbox initially, yes? |
| 16:03 |
berick |
it goes into the fm-editor which is used in lots of places |
| 16:03 |
miker |
also for berick, but for later (just planting the seed), I'd like to talk about being able to pass initial filters to admin (local and server) pages, for linked dependent config (if that makes sense) |
| 16:04 |
berick |
+ a sandbox example of a certain type of use |
| 16:04 |
gmcharlt |
so... we have 7.5 more seconds |
| 16:04 |
JBoyer |
Ah, good. |
| 16:04 |
gmcharlt |
any last-second topics? |
| 16:04 |
berick |
miker: sounds good |
| 16:04 |
gmcharlt |
ok, thanks folks! |
| 16:04 |
gmcharlt |
#endmeeting |
| 16:04 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org | Can't speak? Make sure your nickname is registered and that you are identified to freenode services: https://freenode.net/kb/answer/registration |
| 16:04 |
pinesol |
Meeting ended Wed Feb 6 16:04:53 2019 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 16:04 |
pinesol |
Minutes: http://evergreen-ils.org/meetings/evergreen/2019/evergreen.2019-02-06-15.04.html |
| 16:04 |
pinesol |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2019/evergreen.2019-02-06-15.04.txt |
| 16:04 |
pinesol |
Log: http://evergreen-ils.org/meetings/evergreen/2019/evergreen.2019-02-06-15.04.log.html |
| 16:04 |
miker |
gmcharlt++ |
| 16:05 |
berick |
gmcharlt++ |
| 16:05 |
dbwells |
gmcharlt++ |
| 16:05 |
remingtron |
gmcharlt++ |
| 16:05 |
abowling |
gmcharlt++ |
| 16:05 |
JBoyer |
gmcharlt++ |
| 16:05 |
Dyrcona |
gmcharlt++ |
| 16:05 |
rhamby |
gmcharlt++ |
| 16:06 |
gsams |
berick: On testing the DYMO hatch fix, the prints are diverting to an alternate printer other than the target. This is on Windows 10, I haven't tried elsewhere. |
| 16:07 |
berick |
gsams: *nod* |
| 16:07 |
gsams |
I had a small back and forth with Bmagic about it, and he got similar results. |
| 16:11 |
|
stephengwills left #evergreen |
| 16:11 |
|
jamesrf joined #evergreen |
| 16:59 |
|
mdriscoll left #evergreen |
| 17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:06 |
|
jvwoolf left #evergreen |
| 17:12 |
|
mmorgan left #evergreen |
| 17:20 |
|
beanjammin joined #evergreen |
| 18:07 |
|
beanjammin joined #evergreen |
| 19:04 |
|
csharp joined #evergreen |
| 19:46 |
|
stephengwills joined #evergreen |
| 19:53 |
gsams |
Possibly found a bug, thought I'd run it by the channel. Regarding auto renewal, should the database entry circulation.auto_renewal also follow the same conventions as desk/phone/opac_renewal and have NOT NULL DEFAULT false? Because it doesn't. |
