| Time |
Nick |
Message |
| 00:19 |
|
ningalls_ joined #evergreen |
| 00:21 |
|
csharp joined #evergreen |
| 00:39 |
|
beanjammin joined #evergreen |
| 01:03 |
|
beanjammin joined #evergreen |
| 01:26 |
|
beanjammin joined #evergreen |
| 01:52 |
|
beanjammin joined #evergreen |
| 02:18 |
|
beanjammin joined #evergreen |
| 02:53 |
|
beanjammin joined #evergreen |
| 03:12 |
|
beanjammin joined #evergreen |
| 03:36 |
|
beanjammin joined #evergreen |
| 04:33 |
|
beanjammin joined #evergreen |
| 05:29 |
|
beanjammin joined #evergreen |
| 05:47 |
|
beanjammin joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:15 |
|
csharp joined #evergreen |
| 07:20 |
|
beanjammin joined #evergreen |
| 07:29 |
|
bdljohn joined #evergreen |
| 07:42 |
JBoyer |
csharp, re: a followup bug to 1481441, I did file it, bug 1576754 but I forgot to ever reference it in that bug. |
| 07:42 |
pinesol |
Launchpad bug 1576754 in Evergreen "Custom Error Messages for Circ/Hold Matrix Matchpoints" [Wishlist,New] https://launchpad.net/bugs/1576754 |
| 07:43 |
JBoyer |
I didn't work up the steam at the time to work on it. |
| 07:46 |
JBoyer |
Also csharp, there are precious few people using FF Hatch since they either have to build the installer themselves or get it from me. :( Progress was made at the hackaway but the branch isn't committed and the updated installer isn't generally available. |
| 07:46 |
JBoyer |
The ball, I have dropped it. |
| 08:23 |
|
tlittle joined #evergreen |
| 08:24 |
|
bos20k joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:43 |
csharp |
JBoyer: s'ok - I just built my own installer and provided it to the library - we'll see how it goes :-) |
| 08:43 |
csharp |
thanks for the bug link |
| 08:48 |
|
Dyrcona joined #evergreen |
| 08:51 |
|
stephengwills joined #evergreen |
| 08:54 |
mmorgan |
@coffee |
| 08:54 |
* pinesol |
brews and pours a cup of Kenya Mamuto Kirinyaga, and sends it sliding down the bar to mmorgan |
| 08:55 |
mmorgan |
@coffee [someone] |
| 08:55 |
* pinesol |
brews and pours a cup of Costa Rica Finca Cerro Palado, and sends it sliding down the bar to dbwells |
| 09:11 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 09:33 |
phasefx |
not really a success, but getting there |
| 09:35 |
mmorgan |
Less of a failure is a success |
| 09:45 |
rhamby |
mmorgan: unless the less of a failure is a failure to correctly diagnose the scale of failure (I'm clearly in an optimistic mood today) |
| 09:47 |
* mmorgan |
should probably have phrased that as: A higher level of failure is a success :) |
| 09:47 |
phasefx |
we're failing upwards |
| 09:48 |
JBoyer |
phasefx++ |
| 09:48 |
mmorgan |
phasefx++ |
| 09:50 |
|
jvwoolf joined #evergreen |
| 09:52 |
rhamby |
phasefx++ |
| 09:56 |
Dyrcona |
Ah ha! |
| 09:57 |
Dyrcona |
So, I get this when trying to process that one PO JEDI event that I mentioned yesterday: Dec 12 09:47:38 util open-ils.trigger: [ERR :18899:EX.pm:66:] Exception: OpenSRF::EX::Jabber 2018-12-12T14:47:38 OpenSRF::Transport::SlimJabber::XMPPReader /usr/local/share/perl/5.22.1/OpenSRF/Transport/SlimJabber/XMPPReader.pm:263 Jabber Exception: Disconnected from Jabber server |
| 09:57 |
Dyrcona |
It appears to happen during the create event output step. |
| 10:01 |
Dyrcona |
Unfortunately, the ejabberd log only shows it closing the connection, not why. |
| 10:02 |
|
yboston joined #evergreen |
| 10:06 |
Dyrcona |
OK. Looks like we need some chunking/bundling work there, possibly. |
| 10:22 |
Dyrcona |
So, I got it to work on a "test" server by setting max_stanza_size to 2,000,000 and firing the event by itself. |
| 10:23 |
Dyrcona |
The server that normally runs the events already has max_stanza_size set to 2,000,000, so it can't be just that. |
| 10:26 |
* Dyrcona |
wishes the perl debugger was actually useful. |
| 10:33 |
Dyrcona |
So, I may just go back to using 1 collector and 1 reactor. It seems we've had the --run-pending a/t runner get hung up about 1/week since changing the configuration. That's far more often than before. |
| 10:33 |
Dyrcona |
csharp: Have you encountered any similar issues? |
| 10:41 |
|
khuckins joined #evergreen |
| 10:41 |
pinesol |
News from qatests: Failed Running OpenSRF build tests <http://testing.evergreen-ils.org/~live> |
| 10:41 |
pinesol |
News from qatests: Failed Running Evergreen build tests <http://testing.evergreen-ils.org/~live> |
| 10:41 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live> |
| 10:41 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live> |
| 10:41 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live> |
| 10:50 |
Dyrcona |
I lowered our collect and react settings to 2, just to see if that helps. |
| 10:50 |
* Dyrcona |
doubts it. |
| 11:10 |
|
terran joined #evergreen |
| 11:11 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live> |
| 11:11 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live> |
| 11:11 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live> |
| 11:12 |
phasefx |
getting there |
| 11:13 |
phasefx |
the pgTAP failure is legit |
| 11:15 |
Dyrcona |
phasefx: I've discussed that failure with someone (gmcharlt?) at the hack-away. I noticed when going to Pg 10. |
| 11:15 |
phasefx |
roger that |
| 11:17 |
Dyrcona |
phasefx: https://bugs.launchpad.net/evergreen/+bug/1730726/comments/3 |
| 11:17 |
pinesol |
Launchpad bug 1730726 in Evergreen "Support for PostgreSQL 10" [Wishlist,Confirmed] |
| 11:17 |
Dyrcona |
I need to finish that branch by adding release notes. |
| 11:17 |
phasefx |
Dyrcona++ |
| 11:18 |
berick |
and phasefx++ |
| 11:18 |
Dyrcona |
phasefx: What version of Pg is installed? |
| 11:18 |
berick |
building test server on ub 18? |
| 11:18 |
phasefx |
Dyrcona: PostgreSQL 9.6.10 on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit |
| 11:19 |
Dyrcona |
OK. I don't recall if I've ever run the tests on Pg 9.6. |
| 11:19 |
phasefx |
berick: debian stretch, but we have or are close to having multi-server support |
| 11:20 |
phasefx |
http://git.evergreen-ils.org/?p=working/random.git;a=blob;f=qa/test_runner.xml;h=6e3952d0b1f47e2a1898d3048ebe6153ce4da547;hb=refs/heads/collab/phasefx/eg_live_tests |
| 11:20 |
berick |
nice! |
| 11:21 |
Dyrcona |
Looks like we'll have to modify the test to accommodate 9.6 also.... |
| 11:31 |
phasefx |
right now testing.evergreen-ils.org is still running test.sh (http://git.evergreen-ils.org/?p=working/random.git;a=blob;f=qa/test.sh;h=11d96d5b42eb05d513e6bea63d75a29983175246;hb=refs/heads/collab/phasefx/eg_live_tests), but we can eventually switch it over to and smoke test test_runner.pl http://git.evergreen-ils.org/?p=working/random.git;a=blob;f=qa/test_runner.pl;h=4fc672529021ec2b74bcf83d69dc22bf74ff3c73;hb=refs/heads/collab/phasefx/eg_live_test |
| 11:32 |
phasefx |
then folks with commit access to the branch can just add their servers (there's an ssh pubkey for testin.evergreen-ils.org in the branch) |
| 11:33 |
Dyrcona |
phasefx: Sound interesting/useful. I'll take a look some day. |
| 11:38 |
jeff |
what keeps us using the random repository for all manner of things? would gitlab and/or something else help us get away from that practice, because it would potentially reduce the burden of creating a repo? |
| 11:38 |
jeff |
(tangent, i know) |
| 11:39 |
* phasefx |
has no strong feeling there; just used random because that's what berick used for the original wheezy installer |
| 11:41 |
pinesol |
[evergreen|Remington Steed] Docs: LP#1731048: Update json_query documentation for new join syntax - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=62fc2ea> |
| 11:41 |
pinesol |
[evergreen|Remington Steed] Docs: Fix screenshot file name - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2dc0b1c> |
| 11:43 |
|
khuckins_ joined #evergreen |
| 11:54 |
|
khuckins__ joined #evergreen |
| 12:02 |
|
beanjammin joined #evergreen |
| 12:12 |
|
jihpringle joined #evergreen |
| 12:25 |
|
bdljohn1 joined #evergreen |
| 12:36 |
|
beanjammin joined #evergreen |
| 12:39 |
Dyrcona |
jeff: Gitlab will let you create your own repositories just by pushing to them be default. It can be done with gitolite using a wildcard repo configuration. |
| 12:42 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live#2018-12-12T12:12:09,428726255-0500 -0> |
| 12:42 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live#2018-12-12T12:12:09,450827934-0500 -2> |
| 12:42 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live#2018-12-12T12:12:09,472980231-0500 -4> |
| 12:47 |
dickreckard |
uhm, is there a way to list the last records added to the catalog in the staff client? |
| 13:01 |
miker |
dickreckard: in the staff client directly? hrm, probably not. but in another tab: http://sandbox-32.evergreencatalog.com/opac/extras/feed/freshmeat/opac/biblio/import/10/ |
| 13:05 |
* jeff |
notes the Apache "Found" 3xx body appended to the end of that document |
| 13:06 |
jeff |
internal redirect being followed, but then still resulting in the body being appended? |
| 13:08 |
miker |
huh. that's cute. |
| 13:09 |
dickreckard |
miker: nice, thanks! haven't seen the search syntax before. is it only here? https://wiki.evergreen-ils.org/doku.php?id=documentation:technical:search_grammar |
| 13:09 |
miker |
other formats available for machine processing; replace 'opac' with, say, atom or rss2 |
| 13:09 |
miker |
dickreckard: that's where i pulled the example from, yep :) |
| 13:09 |
dickreckard |
super useful page :)) |
| 13:10 |
miker |
well, no it's not... https://wiki.evergreen-ils.org/doku.php?id=scratchpad:random_magic_spells |
| 13:10 |
* miker |
disappears into a meeting |
| 13:10 |
jeff |
also, in case it was too subtle above: your results from that feed will be different if you are logged in to the staff client in that browser than if you are not. |
| 13:11 |
jeff |
well, "may" be different or "will likely" be different. |
| 13:11 |
Dyrcona |
YMMV |
| 13:12 |
jeff |
also, if you're not logged in to the staff client in that browser when you fetch that url, if the most recent 10 bibs aren't otherwise visible in searches, you may get zero results, or more likely less than the number requested. |
| 13:14 |
jeff |
but if there are zero results you'll get an error that references record IDs, which you can then individually retrieve. |
| 13:16 |
Dyrcona |
dickreckard: What problem are you trying to solve? Do you want to see X of the most recent records you've added or just the previous one? This sounds like a potentially useful feature request. |
| 13:16 |
dickreckard |
no it's for the staff indeed |
| 13:17 |
dickreckard |
just wanted to check how the staff is doing in the test installation, and export the records that were added |
| 13:17 |
dickreckard |
so maybe make a csv with the IDs and use the batch export |
| 13:18 |
dickreckard |
cos I will need to merge the old database with the recods that were added in the test installation, into a new installation |
| 13:20 |
dickreckard |
I think a record query " * sort(create_date) #descending " solve my needs.. but indeed the last x records instead of just the 'retriev last bib record' button could be nice |
| 13:26 |
dickreckard |
also I finally solved the problem I had with vandelay batch imports.. I found the issue was that systemd creates a private /tmp folder nested inside an apache2 private folder, so it couldn't find the uploaded temporary .mrc file as it was inside the private tmp instead of /tmp. I wanted to somehow add that note somewhere, cos it would be useful to add in the documentation as from debian stretch it's the |
| 13:26 |
dickreckard |
default behavior. |
| 13:27 |
dickreckard |
I looked on launchpad and couldn't find mentions about it. so let me know if I can add notify this somewhere. |
| 13:29 |
jeff |
It might be reasonable to review changing the default value of <importer>/tmp</importer> in openils.xml.example |
| 13:31 |
Dyrcona |
dickreckard: You should be able to get marc records out of the URL that miker shared earlier. |
| 13:31 |
|
sandbergja joined #evergreen |
| 13:32 |
dickreckard |
damn! |
| 13:32 |
dickreckard |
didn't see that jeff . *facepalm* |
| 13:33 |
dickreckard |
i am not sure though if systemd creates everytime a dynamically named tmp folder. |
| 13:33 |
dickreckard |
looks like this : systemd-private-3fe5f7b97530483c883d34f88402e1b1-apache2 websockets.service-KOjl3Y/ |
| 13:34 |
dickreckard |
restarting the service the folder name changes |
| 13:35 |
dickreckard |
so I had to change the settings in systemd, following this : https://www.maxoberberger.net/blog/2017/10/debian-9-private-tmp.html |
| 13:36 |
dickreckard |
running to the supermarket, brb |
| 13:39 |
|
beanjammin joined #evergreen |
| 13:50 |
Dyrcona |
Launchpad timeouts... |
| 13:55 |
jeff |
dickreckard: yes, you can set PrivateTmp=false like you did, or you can change your opensrf.xml config so that marc files are spooled somewhere outside of /tmp |
| 13:59 |
terran |
I'm working on bug 1743783 and I can get the billing location id to display but not the shortname - can someone give me a nudge in the right direction? Code paste at https://pastebin.com/cZMn3832 |
| 13:59 |
pinesol |
Launchpad bug 1743783 in Evergreen "Web Client: Bill Display Issues" [Undecided,Confirmed] https://launchpad.net/bugs/1743783 - Assigned to Terran McCanna (tmccanna) |
| 14:01 |
|
bdljohn joined #evergreen |
| 14:03 |
Dyrcona |
terran: The interface that retrieves the bills probably needs to flesh the circ_lib and billing_location fields. |
| 14:05 |
terran |
Dyrcona - ah, okay |
| 14:10 |
miker |
or you could throw systemd in the ocean, and save us all ;) |
| 14:10 |
miker |
er, that was in ref to dickreckard above |
| 14:12 |
Dyrcona |
:) |
| 14:12 |
* Dyrcona |
eyeballs the Evergreen on FreBSD branch that was abandoned 6 years ago..... |
| 14:13 |
Dyrcona |
If everyone hates systemd, why do we all use it? |
| 14:14 |
bos20k |
Some sort of pact between satan and Pottering would be my guess... |
| 14:15 |
dickreckard |
haha |
| 14:16 |
bos20k |
Poettering that is... Even his name is wrong. |
| 14:17 |
jonadab |
Dyrcona: I'll have you know, I have never installed systemd on any system. |
| 14:18 |
dickreckard |
bos20k: I thought it was in reference to the Italian saying 'the Devil makes pots, and not lids' |
| 14:18 |
jonadab |
Upgraded squeeze->wheezy->Devuan jessie->ascii |
| 14:19 |
bos20k |
dickreckard: lol, no, the guy behind systemd. The guy who won't listen to any outside criticism and thinks systemd is perfect. |
| 14:19 |
dickreckard |
It's funny when I looked him up I saw he's behind pulseaudio and avahi too. Funny always have struggling with centralization issues with those too. |
| 14:19 |
jonadab |
bos20k: He's also the same guy responsible for the pulseaudio fiasco. |
| 14:19 |
dickreckard |
;) |
| 14:20 |
jonadab |
I never had a problem with avahi, because I never had a use case for what it tries to do. So if it doesn't work, I don't care. |
| 14:20 |
bos20k |
jonadab: yup. It is amazing that anyone ever listened to him after that. |
| 14:23 |
dickreckard |
jonadab: me neither, just found out about it as it paralizes the networking, by resisting to systemctl stops and respawning after kills.. |
| 14:31 |
JBoyer |
Having looked at berick's websocketd sample systemd service and having to create an upstart version of the same in the last week, I'm ready to assume Poettering must have compromising information on somebody. SysV rc init, NetBSD init, or maybe even Apple's launchd has to be better than this. :/ |
| 14:32 |
JBoyer |
(the example worked fine, that wasn't the point of the complaint) |
| 14:43 |
gmcharlt |
miker: (and whoever else is interested) bug 1729610 (OpenSRF request backlog queue) now has a complete pullrequest |
| 14:43 |
pinesol |
Launchpad bug 1729610 in OpenSRF "allow requests to be queued if max_children limit is hit" [Wishlist,New] https://launchpad.net/bugs/1729610 |
| 14:44 |
miker |
gmcharlt++ |
| 14:51 |
|
tlittle joined #evergreen |
| 14:56 |
Dyrcona |
We have a dev meeting in about 4 minutes. |
| 15:00 |
Dyrcona |
gmcharlt: Do you want to run it? I know you have the agenda locked. |
| 15:00 |
gmcharlt |
sure |
| 15:00 |
gmcharlt |
gimme two minutes |
| 15:00 |
Dyrcona |
OK |
| 15:01 |
berick |
thanks gmcharlt |
| 15:01 |
gmcharlt |
#startmeeting Evergreen Development Meeting, 2018-12-12 |
| 15:01 |
pinesol |
Meeting started Wed Dec 12 15:01:58 2018 US/Eastern. The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:01 |
pinesol |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 15:01 |
|
Topic for #evergreen is now (Meeting topic: Evergreen Development Meeting, 2018-12-12) |
| 15:01 |
pinesol |
The meeting name has been set to 'evergreen_development_meeting__2018_12_12' |
| 15:02 |
gmcharlt |
#info Agenda is https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2018-12-12 |
| 15:02 |
gmcharlt |
#topic Introductions |
| 15:02 |
|
Topic for #evergreen is now Introductions (Meeting topic: Evergreen Development Meeting, 2018-12-12) |
| 15:02 |
|
beanjammin joined #evergreen |
| 15:02 |
gmcharlt |
#info gmcharlt = Galen Charlton, EOLI |
| 15:02 |
jeff |
#info jeff = Jeff Godin, Traverse Area District Library (TADL) |
| 15:02 |
JBoyer |
#info JBoyer = Jason Boyer, ISL |
| 15:02 |
berick |
#info berick Bill Erickson, KCLS |
| 15:02 |
agoben |
#info agoben = Anna Goben, Evergreen Indiana |
| 15:02 |
remingtron |
#info remingtron is Remington Steed, Hekman Library (Calvin College) |
| 15:02 |
Dyrcona |
#info Dyrcona = Jason Stephenson, CW MARS |
| 15:02 |
dbwells |
#info dbwells = Dan Wells, Hekman Library (Calvin College) |
| 15:02 |
stephengwills |
#info stephengwills at Maine Balsam Libraries |
| 15:03 |
Bmagic |
#info Bmagic = Blake GH, MOBIUS |
| 15:04 |
gmcharlt |
#topic Action items from last meeting |
| 15:04 |
|
Topic for #evergreen is now Action items from last meeting (Meeting topic: Evergreen Development Meeting, 2018-12-12) |
| 15:04 |
gmcharlt |
#info JBoyer and csharp will work on a new Hatch release during the hack-a-way |
| 15:04 |
gmcharlt |
JBoyer: how did that go? |
| 15:05 |
JBoyer |
I believe it's ready to go, but it hasn't yet been committed. |
| 15:05 |
gmcharlt |
OK |
| 15:05 |
berick |
JBoyer: got the bug # handy? |
| 15:06 |
JBoyer |
Once that's done and a new version number selected (berick and I talked about 0.2.0) the final installer can be built and put on the site, and the extensions updated in their respective browsers. |
| 15:06 |
JBoyer |
will soon |
| 15:06 |
JBoyer |
bug 1731922 |
| 15:06 |
pinesol |
Launchpad bug 1731922 in Evergreen "Firefox add-on for Hatch" [Wishlist,Confirmed] https://launchpad.net/bugs/1731922 |
| 15:06 |
Bmagic |
I have some more Hatch code related to the Dymo Printer, wonder if they can be combined for the release versioning number? |
| 15:07 |
berick |
JBoyer: i can make sure nothing broke for chrome, but would prefer if someone else could sign off on the windows+firefox bits |
| 15:07 |
JBoyer |
++ |
| 15:08 |
* berick |
wonders if csharp is in the house |
| 15:08 |
berick |
in any event, I'll note that in the LP |
| 15:08 |
* Dyrcona |
was thinking we could assign testing with Firefox to csharp. :) |
| 15:08 |
JBoyer |
The thing that's primarily being tested is the Windows installer. The extension can function without changes so long as the windows bits are updated. |
| 15:08 |
gmcharlt |
ok |
| 15:08 |
gmcharlt |
so I'll take this as |
| 15:09 |
gmcharlt |
#info Next Hatch release is close |
| 15:09 |
JBoyer |
+1 |
| 15:09 |
gmcharlt |
#action berick, JBoyer, csharp, et. al. will collaborate on final testing |
| 15:09 |
gmcharlt |
Bmagic: we can discuss the Dymo stuff later in the agenda |
| 15:09 |
Bmagic |
sure |
| 15:10 |
gmcharlt |
but I note that since there's a direct Evergreen dependency with the "compatiblity mode", we may not want to couple that issue with the other stuff that's being worked on for the Hatch release |
| 15:10 |
|
khuckins__ joined #evergreen |
| 15:11 |
gmcharlt |
so, moving on |
| 15:11 |
gmcharlt |
#topic OpenSRF release |
| 15:11 |
|
Topic for #evergreen is now OpenSRF release (Meeting topic: Evergreen Development Meeting, 2018-12-12) |
| 15:11 |
gmcharlt |
#info OpenSRF 3.0.2 released during the hack-a-way |
| 15:11 |
gmcharlt |
#info OpenSRF 3.1-beta now down to two bugs |
| 15:11 |
gmcharlt |
bug 1803182 |
| 15:11 |
pinesol |
Launchpad bug 1803182 in OpenSRF "Websocketd graceful shutdown support" [Undecided,New] https://launchpad.net/bugs/1803182 |
| 15:11 |
gmcharlt |
^ that one looks straightforward; I'll run it through its paces and will merge today |
| 15:12 |
gmcharlt |
the other is bug 1729610 |
| 15:12 |
pinesol |
Launchpad bug 1729610 in OpenSRF "allow requests to be queued if max_children limit is hit" [Wishlist,New] https://launchpad.net/bugs/1729610 |
| 15:12 |
gmcharlt |
which I know miker will test, but it would be nice to have additional eyes on it |
| 15:12 |
gmcharlt |
I'll write up draft release notes as well |
| 15:12 |
gmcharlt |
request chunking will /not/ make it into 3.1-beta for lack of code |
| 15:12 |
gmcharlt |
any questions? |
| 15:12 |
* miker |
hangs head in shame |
| 15:13 |
JBoyer |
Looks good, since I'm hoping to use websocketd in production soon I'll try to test those two branches too. |
| 15:14 |
|
bdljohn1 joined #evergreen |
| 15:14 |
* Dyrcona |
is using websocketd in production and it is very reliable. |
| 15:14 |
berick |
just noticed I need a better commit message on the websocketd patch... |
| 15:14 |
berick |
will do that today |
| 15:15 |
gmcharlt |
berick++ |
| 15:15 |
jeff |
berick++ |
| 15:15 |
jeff |
also using websocketd in production here. no complaints yet. |
| 15:16 |
gmcharlt |
great |
| 15:16 |
gmcharlt |
so moving on |
| 15:16 |
gmcharlt |
#topic Evergreen release |
| 15:16 |
|
Topic for #evergreen is now Evergreen release (Meeting topic: Evergreen Development Meeting, 2018-12-12) |
| 15:16 |
gmcharlt |
dbwells |
| 15:16 |
gmcharlt |
? |
| 15:17 |
dbwells |
A few small updates... |
| 15:17 |
dbwells |
First, there is now a roadmap page available here: https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:3.3 So far it just has berick's Angular staff catalog bug, so feel free to fill it in/out some more. |
| 15:18 |
dbwells |
I did not carry over anything from 3.2 (which was actually mostly accomplished; good job all!) |
| 15:19 |
Dyrcona |
We should probably info the roadmap. |
| 15:19 |
dbwells |
Also, concerning monthly releases, I am suggesting that we do not do a December release. I don't think activity warrants it, and I will be doing our 3.2 upgrade during the release window, so may not be able to swing it. Here are the unreleased changes: https://launchpad.net/evergreen/+milestone/3.2.3 |
| 15:19 |
dbwells |
#info https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:3.3 |
| 15:20 |
berick |
+1 to skipping Dec. release |
| 15:21 |
dbwells |
To be clear, just the (4) "Fix Committed" would get in, not that giant list :) |
| 15:21 |
Dyrcona |
I'm OK with skipping the December release, too. |
| 15:21 |
gmcharlt |
... action: dbwells will close 40 bugs in the next 7 days... ;) |
| 15:21 |
Dyrcona |
:) |
| 15:21 |
gmcharlt |
seriously, I'm also OK with punting the next maintenance releases to January |
| 15:22 |
dbwells |
Okay, that is all from me. Any questions pertaining to 3.3? |
| 15:23 |
gmcharlt |
none frmo me |
| 15:23 |
JBoyer |
none here |
| 15:23 |
gmcharlt |
#agreed no Evergreen maintenance releases will be made in December; they will be deferred to January |
| 15:24 |
Dyrcona |
Looks good so far. I'll see if any of my recent bugs warrant being added to the road map. |
| 15:25 |
gmcharlt |
ok, moving on |
| 15:25 |
gmcharlt |
#topic Hatch |
| 15:25 |
|
Topic for #evergreen is now Hatch (Meeting topic: Evergreen Development Meeting, 2018-12-12) |
| 15:26 |
berick |
I am planning to help w/ the Dymo LP, at minimum code reivew and non-Dymo testing. |
| 15:26 |
gmcharlt |
berick++ |
| 15:26 |
berick |
I don't have a Dymoe printer, alas |
| 15:27 |
berick |
so kind of like the other Hatch issue, more help testing would be appreciated |
| 15:27 |
gmcharlt |
I have one comment so far ... I dislike calling it "compatibility mode" as a printing setting |
| 15:27 |
dbwells |
We've got a million Dymos and can help with testing. |
| 15:27 |
Bmagic |
I solicited my libraries and was able to borrow one more long term. |
| 15:28 |
gmcharlt |
as ultimately that's meaningless to the user |
| 15:28 |
Bmagic |
I'm not married to the term either. |
| 15:28 |
berick |
thanks dbwells |
| 15:28 |
Dyrcona |
"broken mode?" :) |
| 15:29 |
gmcharlt |
maybe instead (on the Evergreen side) have the interface present a list of potential "special" printer models |
| 15:29 |
berick |
you can never go wrong with "Turbo" |
| 15:29 |
gmcharlt |
along the lines of "[] Dymo [] Everything else" (or something along those lines) |
| 15:29 |
berick |
gmcharlt: makes sense... other printers may need other tweaks |
| 15:29 |
Dyrcona |
I think the release note could use a little more detail. I didn't have any idea what I changes would be required until I saw the example. |
| 15:29 |
JBoyer |
We do kind of have a precedent in the way we do EDI worksrounds. |
| 15:30 |
gmcharlt |
JBoyer: hopefully it won't need to get that involved |
| 15:30 |
JBoyer |
This would just be the Dymo workaround. |
| 15:30 |
gmcharlt |
wait |
| 15:30 |
gmcharlt |
we're talking about printing |
| 15:30 |
berick |
heh |
| 15:30 |
gmcharlt |
Narrator: it will get that involved, and more |
| 15:30 |
JBoyer |
gmcharlt++ |
| 15:31 |
Bmagic |
In the Hatch code, it's a fork based upon a boolean as to which way to render the HTML. It's first incarnation was a string match against the word "Dymo" but now is in the hands of the staff via the Evergreen setting |
| 15:31 |
gmcharlt |
yeah, I can understand not wanting to do string matching there |
| 15:32 |
dbwells |
berick: Looking at my "Dymo Labelwriter 400 Turbo" right now, it's not a bad name for the option ;) |
| 15:32 |
Dyrcona |
I'm not too fussed about what it is called as long as the documentation is clear about what it does and what other changes it will require. |
| 15:32 |
Bmagic |
In the end, it's true/false which fits nicely with the checkbox UI |
| 15:32 |
gmcharlt |
but having the Evergreen end keep track of a set of special printer (dis)capabilities and send appropriate flags to Hatch could work |
| 15:32 |
berick |
dbwells: oh yeah, I forgot they were called that... |
| 15:33 |
gmcharlt |
anything else to say about Hatch? |
| 15:33 |
gmcharlt |
#action Bmagic, berick, et al will poke more on the Dymo branch per feedback at this meeting |
| 15:34 |
gmcharlt |
moving on |
| 15:34 |
gmcharlt |
#topic Date of next meeting |
| 15:34 |
|
Topic for #evergreen is now Date of next meeting (Meeting topic: Evergreen Development Meeting, 2018-12-12) |
| 15:34 |
gmcharlt |
so... shall we try 1/9? |
| 15:34 |
JBoyer |
that |
| 15:34 |
Dyrcona |
+1 # I've already got 2 other meetings on 1/2, now. |
| 15:34 |
JBoyer |
s good for me. |
| 15:34 |
Bmagic |
works for me |
| 15:35 |
berick |
+1 |
| 15:35 |
dbwells |
+1 |
| 15:35 |
gmcharlt |
#agreed Next development meeting will be held on 2019-01-09 |
| 15:35 |
gmcharlt |
#topic Evergreen 2019 Hack-A-Way |
| 15:35 |
|
Topic for #evergreen is now Evergreen 2019 Hack-A-Way (Meeting topic: Evergreen Development Meeting, 2018-12-12) |
| 15:35 |
agoben |
In the survey I sent out, Nov 4-6 took the most top votes. Oct 21-23 took second place. Halloween week got a lot of meh. |
| 15:35 |
agoben |
Are you ok with election week again after all? |
| 15:36 |
Dyrcona |
The dates were all the same to me at this point, tbh. |
| 15:37 |
JBoyer |
What was the spread between 1st and 2nd ? |
| 15:37 |
rhamby |
I'd rather not do election week personally. We had some complaints at the hack-a-way this year for that reason. |
| 15:37 |
agoben |
8 ppl responded. 5 chose election week as their number 1 choice |
| 15:37 |
rhamby |
(complaints might be too strong a word ....) |
| 15:38 |
JBoyer |
Oh. |
| 15:38 |
agoben |
No one went for halloween week as a first choice and 3 picked the week before that |
| 15:38 |
gmcharlt |
we are all clearly committed to feeding trick-or-treaters... |
| 15:39 |
agoben |
Be a shame to miss out on the candy and costumes, indeed. |
| 15:39 |
* Dyrcona |
changes his vote to make it a tie. :) |
| 15:39 |
JBoyer |
Or being trick-or-treaters, no judging here. ;) |
| 15:39 |
agoben |
But Halloween week was the winner of the #2 choice (again 5 participants) |
| 15:39 |
gmcharlt |
agoben: how long do you want to keep the survey open? |
| 15:39 |
berick |
Hackfest Spooktacular! |
| 15:40 |
agoben |
I would like to lock in the contracts next week so we're not holding 3 weeks hostage. |
| 15:40 |
* JBoyer |
puts flashlight under chin, "This behavior only happens when debug logging is turned off!" |
| 15:41 |
dbwells |
JBoyer: I got chills |
| 15:41 |
berick |
we just work on EDI all week |
| 15:41 |
remingtron |
JBoyer++ |
| 15:41 |
JBoyer |
berick wins, I'm not going |
| 15:41 |
gmcharlt |
I have a mild preferance against not doing it during election week, but only mild |
| 15:41 |
gmcharlt |
(it would be /much/ stronger if we were talking about 2020) |
| 15:42 |
agoben |
I can leave it open until Monday if you want to just leave it in the hands of the stats at that point? |
| 15:42 |
gmcharlt |
that makes sense to me |
| 15:42 |
agoben |
Since fewer than half of the expected participants responded, it might be best to get a reminder out to vote now ;) |
| 15:43 |
berick |
agoben: maybe send a reminder to the lists, including a note about election day |
| 15:43 |
berick |
:) |
| 15:43 |
Dyrcona |
I was going to suggest Friday evening with an email sent explicitly with the topic of vote now or don't complain. |
| 15:43 |
agoben |
I'm out on Friday, but I can send out a reminder tomorrow to that effect. |
| 15:43 |
agoben |
Thanks for the input; the decision will be posted next week! |
| 15:43 |
berick |
agoben++ |
| 15:44 |
gmcharlt |
agoben++ |
| 15:44 |
Dyrcona |
I meant send a reminder now, and close the poll on Friday evening. Sorry that I wasn't clear. |
| 15:44 |
remingtron |
agoben++ |
| 15:44 |
Dyrcona |
agoben++ |
| 15:44 |
agoben |
I'll send it out first thing tomorrow. Have to buzz now. Thanks everyone! |
| 15:45 |
gmcharlt |
#topic Angular Staff Catalog |
| 15:45 |
|
Topic for #evergreen is now Angular Staff Catalog (Meeting topic: Evergreen Development Meeting, 2018-12-12) |
| 15:45 |
berick |
ok, questions about that... |
| 15:45 |
berick |
i am continuing work on it as noted in the LP. |
| 15:45 |
berick |
and i've done a bit more since my last update |
| 15:46 |
berick |
I strongly suspect it will not be in a state to replace the existing catalog by 3.3 |
| 15:46 |
gmcharlt |
I'm generally in favor of making it available in 3.3 on a beta basis (and making it easy to switch via a workstation pref?) |
| 15:46 |
berick |
gmcharlt: that's exactly my question |
| 15:46 |
berick |
and what I was imagining -- workstation pref |
| 15:47 |
berick |
and when it's enabled it will be clearly /other/ |
| 15:47 |
berick |
and not a replacement |
| 15:47 |
gmcharlt |
but I'm wondering if we can go so far as to also deprecate the old embedded OPAC at the same time, with a stated goal of removing it in 3.4 |
| 15:47 |
JBoyer |
+1 to having the code in core, possibly just have 2 entries in the cat menu "Search Catalog" and "Testing Catalog" or similar. |
| 15:47 |
Dyrcona |
I'd be inclined to leave it out. |
| 15:47 |
berick |
Dyrcona: well, it's already in there |
| 15:47 |
berick |
or do you mean the menu entry? |
| 15:47 |
JBoyer |
Oops, I forgot that was the case |
| 15:47 |
miker |
gmcharlt: I don't know that I'd be comfortable with that |
| 15:48 |
* Dyrcona |
rephrases: I'd be inclined to not expose it easily. |
| 15:48 |
berick |
Dyrcona: gotcha |
| 15:48 |
miker |
is it Decided(tm) that the embedded catalog must die? (sorry if that's been made clear or is obvious) |
| 15:48 |
JBoyer |
Does seem a little early to deprecate embedded tpac in 3.3, though |
| 15:48 |
berick |
it could still be easily tested even if it weren't listed in the menu, of course |
| 15:49 |
berick |
miker: that is certainly my hope, but no decisions on that have really been made. also why I wanted to raise the topic |
| 15:49 |
JBoyer |
miker, if it went up to a vote among circ staff they wouldn't think twice, as the iframe eats the shortcut keys. |
| 15:49 |
gmcharlt |
miker: in the long run, I don't think it does us much good to support two different staff OPACs (although obviously there will need to be a way to quickly open a bib in the OPAC) |
| 15:49 |
berick |
make sure I'm tilting at the correctly shaped windmills |
| 15:50 |
dbwells |
Perhaps we could state a goal of having the new catalog be the default in 3.4 rather than deprecate the TT2 right away, then see how that unfolds. |
| 15:51 |
berick |
to give some idea of scope, removing tpac means implementing a /lot/ of Angular code |
| 15:51 |
Dyrcona |
This new catalog is only for the web staff client, correct? TPAC is still there for patrons. |
| 15:51 |
miker |
well, the tenticals that are reaching into the OPAC from ng today are really pretty well constrained ... so a goal of just not breaking it seems doable. and, what dbwells said. let's just see |
| 15:51 |
berick |
Dyrcona: correct, just staff |
| 15:51 |
Dyrcona |
Thanks, just making sure I was on the same page. |
| 15:52 |
miker |
tpac is only going to get more features, too, so is parity in the staff pac something we should (can?) commit to? |
| 15:53 |
berick |
miker: i don't think parity should necessarily be a goal. to me, they are 2 different things entirely |
| 15:54 |
Dyrcona |
what berick said with the addition that I can imagine there being features useful for patrons and not staff and vice versa. |
| 15:54 |
jeffdavis |
there is an awful lot of functional overlap though |
| 15:54 |
miker |
berick: thanks. that's something we may have to sell, since that's a touted benefit, but we shall see. maybe opinions have evolved :) |
| 15:54 |
berick |
jeffdavis: agreed, and if we move to an Ang public catlog, much code will be shared |
| 15:55 |
jeffdavis |
Is that the community's overall goal? (not against it fwiw) |
| 15:55 |
berick |
miker: agreed, I don't mean to take it for granted. I strongly suspect the benefits will far outweigh any lost functionality, though. |
| 15:56 |
miker |
jeffdavis: I mean ... I'm for a web app, but then, I was for it the first time, too ;) |
| 15:58 |
jeffdavis |
I've been worried about having to support separate parallel public and staff OPACs. If we do plan to make the angular staff OPAC the basis for a new public OPAC in future, that eases some concern there (although it raises other concerns re existing customizations etc for the current TPAC). |
| 15:59 |
miker |
jeffdavis: yeah, that has to be solved for sure. one shouldn't need a compiler to change some css ;) |
| 16:00 |
* gmcharlt |
leans more towards (a) staff catalog as an entity that can be optimized for staff workflows and (b) avoids the jankiness and speed issues of the embedded TPAC |
| 16:00 |
berick |
i guess, stepping back, is my assumption that we want to chip away at the iframes and generally move toward Angular for the staff UI not fully agreed upon? |
| 16:00 |
JBoyer |
Can everyone get behind "keep working on it aiming for 3.4, don't deprecate the embed in 3.3, and expose it locally if you like by editing navbar.tt2?" |
| 16:01 |
miker |
anyway, I've pulled us off into the weeds enough. to the original point, I'm not for calling the embedded tpac deprecated and set for removal as 3.4 |
| 16:01 |
gmcharlt |
I realize that deprecating it in 3.3 is aggresive, and arguably too agressive |
| 16:01 |
gmcharlt |
but I am very concerned in the long run about this turning into "catalog" and "alt. catalog" a la the XUL serials interfaces |
| 16:02 |
berick |
i'm fine seeing how it goes. i suspect we'll get more direction from users after more public discussion as well. |
| 16:02 |
gmcharlt |
so I think berick's latest question is kinda an existential one |
| 16:02 |
miker |
berick: that's agreed upon generally, yes. it can continue to work in Ang, right? it's just shoving data and functions into the iframe's window, which I assume Ang can do as well as AngJS? |
| 16:03 |
berick |
miker: well, you skipped the part of my question about chipping away at the iframes |
| 16:03 |
miker |
berick: heh, well, there are lots of them |
| 16:04 |
miker |
I mean, obv removing the dojo iframes is a goal and underway |
| 16:04 |
gmcharlt |
and IMO the TPAC iframes really should go as well. the current embedded TPAC is slow |
| 16:05 |
berick |
that's my take as well. |
| 16:05 |
miker |
gmcharlt: that's totally fair |
| 16:05 |
jeffdavis |
I think deprecating in 3.3 is too aggressive, but a soft goal of defaulting to angular OPAC in 3.4 (+ deprecating TPAC in client) is ok with me. |
| 16:06 |
gmcharlt |
I also think that it should be a bit easier than editing navbar.tt2 (or the equivalent) to make it avaialble in 3.3 for testing purposes |
| 16:06 |
gmcharlt |
YAOUS, perhaps? |
| 16:07 |
JBoyer |
A reasonable compromise; that way Library A can get their staff started early even if Library B isn't sure how this whole "online" thing is going to shake out. |
| 16:07 |
miker |
I'm mainly curious as to whether we can, or should, write an Ang egFrame component so we can make use of what's there, or will the whole catalog in the client continue to be AngJS until we switch? |
| 16:08 |
berick |
miker: as it stands, I'm making the Ang catalog jump to AngJS for anything it's not prepared to deal with |
| 16:08 |
berick |
to ease integration / testing |
| 16:09 |
berick |
e.g. it jumps to AngJS for holdings maintenance, holds lists, and a few others |
| 16:09 |
berick |
but AngJS stays within its own sphere for now |
| 16:09 |
berick |
it never jumps back to Ang (unless you use the back button) |
| 16:10 |
berick |
which as it stands would be confusing for most staff, but certainly usable / testable |
| 16:10 |
miker |
sure, that makes sense |
| 16:11 |
berick |
but to answer your questoin, I think yes, there has to be a single catalog that's the main one |
| 16:11 |
berick |
which will be angjs until it's not |
| 16:11 |
miker |
ok, thanks |
| 16:12 |
miker |
berick: one last thing on Ang catalog... |
| 16:13 |
miker |
do you think there will need to be some new services (or at least API calls) to do some of what the mod_perl code does now, like interfacing with memcache for various things (recent staff searches, etc) |
| 16:13 |
miker |
or, I guess /a/ new services to contain some APIs |
| 16:14 |
miker |
(asking because that might be our chance to move some of the private-service code out of tpac, improving that along the way) |
| 16:14 |
berick |
miker: yes, definitely. i've already created some and copied-ish some TPAC code into public APIs for my working branch |
| 16:14 |
* miker |
should really just look a the code |
| 16:14 |
miker |
thanks for bearing with me |
| 16:14 |
* miker |
places the mic gently on the edge of the stage and steps back |
| 16:15 |
berick |
i've added a bit to return some tidy holds info (so that UI doens't have to repeat all of that) and copied the browse bits |
| 16:15 |
* JBoyer |
can't wait for the hip-hop remix of the discussion. |
| 16:15 |
berick |
i think that's it so far |
| 16:15 |
berick |
miker: :) |
| 16:16 |
gmcharlt |
ok, so I think to sum up, it sounds like we have |
| 16:16 |
gmcharlt |
(a) general willingness that the Ang staff OPAC be made available in 3.3 in some fashion for testing |
| 16:17 |
gmcharlt |
(b) a new shared sense of what the issues will be around when (or if) to make a full transiition to it at some point |
| 16:17 |
gmcharlt |
accurate? |
| 16:17 |
miker |
+1 |
| 16:17 |
JBoyer |
+1 |
| 16:17 |
berick |
+1 |
| 16:17 |
jeff |
+1 |
| 16:18 |
jeffdavis |
+1 |
| 16:18 |
gmcharlt |
ok, we're 18 minutes over, so I'm going to call this meeting done and dusted |
| 16:18 |
gmcharlt |
#endmeeting |
| 16:18 |
|
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:18 |
pinesol |
Meeting ended Wed Dec 12 16:18:53 2018 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 16:18 |
pinesol |
Minutes: http://evergreen-ils.org/meetings/evergreen/2018/evergreen.2018-12-12-15.01.html |
| 16:18 |
pinesol |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2018/evergreen.2018-12-12-15.01.txt |
| 16:18 |
pinesol |
Log: http://evergreen-ils.org/meetings/evergreen/2018/evergreen.2018-12-12-15.01.log.html |
| 16:19 |
stephengwills |
:/ wow so (so fun to watch you guys work) |
| 16:19 |
JBoyer |
gmcharlt++ |
| 16:19 |
berick |
gmcharlt++ |
| 16:19 |
miker |
(to be clear, I think it's "when", I just wonder about the open questions of maintenance, the form of the public catalog, etc) |
| 16:19 |
miker |
gmcharlt++ |
| 16:19 |
remingtron |
gmcharlt++ |
| 16:19 |
dbwells |
gmcharlt++ |
| 16:19 |
* rhamby |
alas poor meeting I knew him well Horatio |
| 16:19 |
jeff |
gmcharlt++ |
| 16:19 |
rhamby |
gmcharlt++ |
| 16:22 |
Dyrcona |
gmcharlt++ |
| 16:25 |
berick |
VM done building.. Ang catalog is here: https://35.231.77.33/eg2/en-US/staff/catalog (admin / demo123) |
| 16:26 |
berick |
i'll move it to a different host w/ a proper SSL cert in Jan. |
| 16:27 |
jeff |
berick: is that running the branch from bug 1806087? |
| 16:27 |
pinesol |
Launchpad bug 1806087 in Evergreen "Angular staff catalog continued (cira 3.2)" [Wishlist,New] https://launchpad.net/bugs/1806087 - Assigned to Bill Erickson (berick) |
| 16:27 |
berick |
jeff: yes |
| 16:27 |
jeff |
thanks! berick++ |
| 16:29 |
|
bdljohn joined #evergreen |
| 16:31 |
|
beanjammin joined #evergreen |
| 16:47 |
|
bdljohn1 joined #evergreen |
| 17:00 |
|
khuckins joined #evergreen |
| 17:03 |
|
jvwoolf left #evergreen |
| 17:06 |
|
bdljohn joined #evergreen |
| 17:07 |
|
mmorgan left #evergreen |
| 17:23 |
|
Glen__ joined #evergreen |
| 18:28 |
|
beanjammin joined #evergreen |
| 18:48 |
|
stephengwills joined #evergreen |
| 19:33 |
|
beanjammin joined #evergreen |
