| Time |
Nick |
Message |
| 03:02 |
|
devted joined #evergreen |
| 03:15 |
|
yar joined #evergreen |
| 03:15 |
|
abowling joined #evergreen |
| 03:15 |
|
eady joined #evergreen |
| 03:15 |
|
pastebot joined #evergreen |
| 03:15 |
|
jeff joined #evergreen |
| 03:29 |
|
mrisher joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
rfrasur joined #evergreen |
| 07:19 |
|
rjackson_isl_hom joined #evergreen |
| 08:15 |
|
Dyrcona joined #evergreen |
| 08:30 |
Dyrcona |
Gotta love queries that use action.all_circulation: -> Seq Scan on aged_circulation ... -> Seq Scan on circulation circ. |
| 08:35 |
|
mantis1 joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:48 |
|
dbwells_ joined #evergreen |
| 08:54 |
|
dbwells joined #evergreen |
| 08:56 |
|
rfrasur joined #evergreen |
| 09:21 |
|
rjackson_isl_hom joined #evergreen |
| 09:25 |
|
collum joined #evergreen |
| 09:57 |
|
jvwoolf joined #evergreen |
| 10:12 |
Dyrcona |
I don't know what the problem is, but I often have to do a reingest on a database after restoring it from a dump. I assume that some process was updating a search-related table while the dump was being made, leaving things in an inconsistent state. |
| 10:13 |
Dyrcona |
When MVLC was on Horizon, we used to rebuild the OPAC search indexes on a weekly basis, and sometimes they'd still blow up and have to rebuilt in between times. I mention that because the search result pages look pretty much the same as in Evergreen when a reingest is called for. |
| 10:17 |
Dyrcona |
These blank results certainly make testing for a potential upgrade more difficult. Everyone suspects it is something in the upgraded code until the ingest finishes. Oh well, guess we're not upgrading next week. |
| 10:20 |
rfrasur |
-- |
| 10:20 |
* rfrasur |
has no answers. |
| 10:21 |
* Dyrcona |
doesn't expect any answers. |
| 10:21 |
Dyrcona |
rfrasur++ |
| 10:22 |
* Dyrcona |
rocks out to Led Zeppelin. |
| 10:22 |
rfrasur |
Dyrcona++ |
| 10:22 |
* rfrasur |
sits in relative silence and thinks about socks. |
| 10:22 |
* berick |
spits out coffee |
| 10:22 |
* Dyrcona |
isn't wearing any socks at the moment. |
| 10:24 |
Dyrcona |
git++ For making it easy to manage custom branches and bug fix backports. |
| 10:24 |
Dyrcona |
I've got a branch based on 3.2.10 that has a number of things from 3.3 and 3.4 backported to it. |
| 10:25 |
Dyrcona |
We figure that's a nice stop gap until we upgrade to 3.5 or whatever in the fall. |
| 10:25 |
rfrasur |
berick - bad coffee? |
| 10:25 |
Dyrcona |
smelly feet? :) |
| 10:25 |
* rfrasur |
isn't wearing socks either - and it's chilly. |
| 10:26 |
berick |
rfrasur: spit-take at your socks comment |
| 10:27 |
rfrasur |
Oh...hmm. |
| 10:27 |
rfrasur |
Fair. |
| 10:28 |
mmorgan |
socks++ |
| 10:28 |
* rfrasur |
drinks her coffee. |
| 10:28 |
* Dyrcona |
is out of iced tea. |
| 10:28 |
rfrasur |
mmorgan++ |
| 10:29 |
rfrasur |
@coffee |
| 10:29 |
* pinesol |
brews and pours a cup of Colombia Hato Viejo Cup of Excellence, and sends it sliding down the bar to rfrasur |
| 10:29 |
rfrasur |
@coffee berick |
| 10:29 |
* pinesol |
brews and pours a cup of India AA Elkhill Estate, and sends it sliding down the bar to berick |
| 10:30 |
berick |
thanks |
| 10:30 |
rfrasur |
I'm great at sharing the representation of the concept of a thing. So, no prob ;) |
| 10:31 |
Dyrcona |
:) |
| 10:31 |
rfrasur |
(with the help of automated processes) |
| 10:32 |
mmorgan |
rfrasur++ |
| 10:32 |
berick |
heh |
| 10:35 |
rfrasur |
On the plus side, I fostered the development of a microscopic society on my countertop. (the sourdough starter hasn't died yet) |
| 10:36 |
Dyrcona |
Are we planning on having the developers' meeting this afternoon? I created an agenda: https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-05 |
| 10:41 |
berick |
Dyrcona++ |
| 10:43 |
berick |
i'll send a reminder email |
| 10:49 |
csharp |
berick++ Dyrcona++ |
| 10:53 |
Dyrcona |
berick++ |
| 11:46 |
|
sandbergja joined #evergreen |
| 11:47 |
|
jihpringle joined #evergreen |
| 12:10 |
|
mrisher joined #evergreen |
| 12:12 |
|
Innarri joined #evergreen |
| 12:16 |
|
Innarri joined #evergreen |
| 12:16 |
|
mikerisher joined #evergreen |
| 12:21 |
|
khuckins joined #evergreen |
| 12:35 |
|
Innarri joined #evergreen |
| 12:38 |
|
Innarri_ joined #evergreen |
| 12:58 |
|
sandbergja joined #evergreen |
| 13:00 |
|
mrisher joined #evergreen |
| 13:42 |
Dyrcona |
Too many pull list and hold target functions.... |
| 13:45 |
mmorgan |
Dyrcona: More than there should be? Are there redundant ones? |
| 13:47 |
Dyrcona |
I think so, yes. |
| 13:49 |
Dyrcona |
One thing that bugs me about how the web staff client has been developed is that existing back end functions have, in many cases, been abandoned for new ones or replaced in the web client code with pcrud calls. |
| 13:50 |
Dyrcona |
Just trying to figure out how pull lists work, now, is a bit of a chore, particularly when a number of member libraries are still using XUL and some libraries are using both XUL and the web staff client. |
| 13:51 |
mmorgan |
:-( |
| 13:52 |
Dyrcona |
Pretty much everything ends up going through open-ils.storage.direct.action.hold_request.pull_list |
| 13:52 |
Dyrcona |
eventually. |
| 13:53 |
|
Innarri joined #evergreen |
| 13:53 |
mmorgan |
Is ahopl in the fm_IDL still getting used? |
| 13:55 |
Dyrcona |
Not in the web staff client as far as I can tell. |
| 13:56 |
Dyrcona |
Hmm. Maybe it is. Maybe my rgrep wasn't thorough enough? |
| 13:57 |
Dyrcona |
Turns out I'm looking at the implementation of print_full_list that calls open-ils.circ.hold_pull_list.fleshed.stream |
| 13:58 |
* mmorgan |
still doesn't quite understand how all the pieces fit together, but wondered why queries like ahopl were in the fm_IDL rather than in the db. |
| 14:00 |
Dyrcona |
mmorgan: Because it's a mess to be honest. |
| 14:01 |
mmorgan |
Ah, ok :) |
| 14:05 |
mmorgan |
So kind of like a jigsaw puzzle with some pieces missing and some extra pieces that don't go in at all? ;-) |
| 14:06 |
Dyrcona |
Pretty much. Though, I like to describe as lasagna, made with spaghetti noodles. :P |
| 14:07 |
mmorgan |
Heh. |
| 14:07 |
csharp |
and made with noodles from last night's lasagna? |
| 14:08 |
Dyrcona |
So, the only reference to pull lists that I can find in the web staff client code at the moment is a call to open-ils.circ.hold_pull_list.fleshed.stream, so I'll assume for lack of better evidence that is how the hold pull list gets populated. |
| 14:09 |
Dyrcona |
rgrep doesn't turn ahopl in the web staff client code. |
| 14:09 |
Dyrcona |
word can comprehension. :) |
| 14:09 |
Dyrcona |
Oh, nice VPN disconnected me..... |
| 14:11 |
Dyrcona |
I suppose that I should clarify that I'm looking at the code for 3.2.10. |
| 14:11 |
Dyrcona |
Things have changed since then. |
| 14:14 |
Dyrcona |
Anyway, I've determined that we need a new status to keep quarantined items off of library pull lists. |
| 14:17 |
mmorgan |
How would items get into that status? |
| 14:17 |
Dyrcona |
Manually, I assume. |
| 14:18 |
mmorgan |
Could you make the Reshelving status not holdable, and extend the reshelving status interval? |
| 14:19 |
Dyrcona |
The pull list looks specifically for status (0,7) Available and Reshelving/Recently Returned. |
| 14:20 |
Dyrcona |
I could hack it to exclude status 7, but that's less than ideal because I'd have to undo it later. |
| 14:20 |
mmorgan |
So it doesn't care about the holdability of status 7 :-( |
| 14:21 |
Dyrcona |
Nope. Not in 3.2.10, anyway. |
| 14:25 |
Dyrcona |
You can also get a pull list that doesn't care about the status, but you'd have to make the back end call yourself. |
| 14:31 |
|
remingtron joined #evergreen |
| 14:31 |
Dyrcona |
Actually, this search came of out of a question about extending the reshelving interval to keep things off of the pull list. |
| 14:32 |
Dyrcona |
It would be an easy hack to remove status 7 from the filter. |
| 14:33 |
* mmorgan |
would think it would be less easy for library staff to get all the quarantined items into a custom status. |
| 14:34 |
mmorgan |
How long will items be quarantined, or is that TBD? |
| 14:34 |
Dyrcona |
TBD, but also not my call. The thing about the reshelving is that there's an OU setting, so if that worked, it could vary by library and the "system" would take care of it. |
| 14:35 |
mmorgan |
That would be ideal. |
| 14:35 |
Dyrcona |
With a custom status, libraries would still determine their own quarantine periods, but they'd have to track it themselves. |
| 14:40 |
Dyrcona |
I guess staff would have to use noop checkins for quarantined items, too. |
| 14:40 |
Dyrcona |
Otherwise, they'll target holds right away. |
| 14:41 |
mmorgan |
How would staff do a noop checkin? |
| 14:43 |
* Dyrcona |
shrugs. I don't use the client, so I don't know. |
| 14:43 |
Dyrcona |
We've had discussions of using the capture holds as transits option. |
| 14:43 |
jeff |
"ignore holds and transits" checkin modifier is a likely option, but i don't know without looking that it actually uses the noop argument. |
| 14:43 |
Dyrcona |
It probably does. |
| 14:44 |
|
sandbergja joined #evergreen |
| 14:44 |
jeff |
another option is capture local holds as transits, which does mean that some holds will have items "tied up" in quarantine that could have been filled with items on the shelf, but I think we're not going to worry about that. |
| 14:44 |
jeff |
our returns via sorter do that already. |
| 14:44 |
Dyrcona |
rgrep says, "Yes." |
| 14:44 |
mmorgan |
jeff: But would suppress holds and transits put all items into reshelving status? |
| 14:45 |
jeff |
those items will go in a distinct bin and will be handled differently post-quarantine. |
| 14:45 |
* Dyrcona |
has 151 locations who all want to do different things. |
| 14:45 |
jeff |
mmorgan: i believe so. the catch with that is that if you have items that should transit you're likely to miss them. |
| 14:46 |
Dyrcona |
Yeahp. There's no ideal solution. |
| 14:47 |
mmorgan |
Right, and the item looks like it's at home. Maybe that checkin modifier should be named "suppress holds and teleport" |
| 14:47 |
jeff |
capture local holds as transits is likely to work for us, with the one con I mentioned above. |
| 14:47 |
jeff |
But maybe you're discussing a different problem than I thought. :-) |
| 14:47 |
jeff |
mmorgan: suppress holds and lose items |
| 14:48 |
* mmorgan |
nods :) |
| 14:48 |
jeff |
I believe it's equivalent to right clicking an item and checking it in. |
| 14:49 |
rfrasur |
you'd probably want to suppress holds and transits first..let them sit for quarantine - maybe throw them into a bucket and change their status to temp unavailable rather than reshelving. |
| 14:49 |
jeff |
(note to self: see how that bug turned out with the id vs barcode change in web:xul) |
| 14:49 |
rfrasur |
(all of which is a PitA) |
| 14:50 |
jeff |
we're planning to extend reshelving interval to roughly quarantine interval, check in all items with "capture local holds as transits", and exclude Reshelving status from hold pull lists. |
| 14:50 |
jeff |
most items will check in via sorter. |
| 14:50 |
jeff |
items not needed for holds/transits may or may not be quarantined together, but will exit quarantine differently. |
| 14:51 |
jeff |
we will not pull items from quarantine to fill holds until after quarantine has expired (based on "quarantine until DATE" paper note on tables/carts/whatever). |
| 14:51 |
|
sandbergja joined #evergreen |
| 14:52 |
* miker |
considered a (new) copy alert that forced a new status at all checkins, and a new 'quarantine' status (no holds, not opac visible), then you throw everything on a "may 5th" cart that you check in today, and reprocess them on friday for a 3-day quarantine |
| 14:53 |
jeff |
we'd like to avoid re-processing, though we had considered something like that (though i had initially thought we might use a copy status, a new-style copy alert might be better) |
| 14:54 |
jeff |
we might change config or code to cause reshelving status to not be something that's targeted and thus doesn't show on the hold pull list, but we might also exclude items in reshelving status on the report we use for holds pull lists. |
| 14:56 |
jeff |
that second option has side effects, i think: one hold might need to wait a little longer even though it should be "first" because it was "on the holds pull list" fr the reshelving copy but we were ignoring it. |
| 14:56 |
mmorgan |
miker: Interesting - so you would apply that copy alert with a database query to all checked out items, or something like that? |
| 14:56 |
jeff |
changing the targeting (and not just omitting those copies from the report) would avoid that, just a matter of how much effort we decide to put into the approach. |
| 14:57 |
jeff |
applying sticky statuses at checkin is something we had also started to look at with complex kits requiring inspection, but... those won't be going out for a while now. |
| 15:01 |
Dyrcona |
So, meeting? |
| 15:01 |
Bmagic |
shoot |
| 15:01 |
* Dyrcona |
needs to find the cheat sheet if I'm going to run it. |
| 15:01 |
Bmagic |
I knew you cheated! You are the spy |
| 15:02 |
Dyrcona |
#startmeeting 2020-05-05 - Developer Meeting |
| 15:02 |
pinesol |
Meeting started Tue May 5 15:02:54 2020 US/Eastern. The chair is Dyrcona. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:02 |
pinesol |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 15:02 |
|
Topic for #evergreen is now (Meeting topic: 2020-05-05 - Developer Meeting) |
| 15:02 |
pinesol |
The meeting name has been set to '2020_05_05___developer_meeting' |
| 15:03 |
Dyrcona |
#topic Introductions |
| 15:03 |
|
Topic for #evergreen is now Introductions (Meeting topic: 2020-05-05 - Developer Meeting) |
| 15:03 |
Bmagic |
#info Bmagic, Blake GH MOBIUS |
| 15:03 |
csharp |
#info csharp = Chris Sharp, GPLS |
| 15:03 |
Dyrcona |
#info Dyrcona = Jason Stephenson, CWMARS |
| 15:03 |
miker |
mmorgan: yes, exactly. just create an alert for each location (or group) and assign to all copies |
| 15:04 |
miker |
they peel it off as folks open back up |
| 15:04 |
alynn26 |
#info alynn26 is Lynn Floyd Evergreen Indiana |
| 15:04 |
miker |
s/they/then |
| 15:04 |
JBoyer |
#info JBoyer = Jason Boyer, EOLI |
| 15:04 |
miker |
#info miker = Mike Rylander, EOLI |
| 15:04 |
abneiman |
#info abneiman = Andrea Buntz Neiman, EOLI |
| 15:04 |
Dyrcona |
#info Agenda is https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-05 |
| 15:05 |
JBoyer |
Ooh, that new business item has been on my mind before. |
| 15:06 |
sandbergja |
#info sandbergja = Jane Sandberg, Linn-Benton Community College |
| 15:06 |
devted |
#info devted, Ted Peterson, MOBIUS |
| 15:06 |
jeff |
#info jeff = Jeff Godin, Traverse Area District Library (TADL) |
| 15:06 |
Dyrcona |
#topic Action Items from Last Meeting |
| 15:06 |
|
Topic for #evergreen is now Action Items from Last Meeting (Meeting topic: 2020-05-05 - Developer Meeting) |
| 15:07 |
Dyrcona |
#info csharp will arrange testing for sandbergja's fix to https://launchpad.net/bugs/1821094 on a realistic test server |
| 15:07 |
pinesol |
Launchpad bug 1821094 in Evergreen 3.3 "Item status refresh after editing can get confusingly slow" [Medium,Confirmed] |
| 15:07 |
csharp |
we installed the fix for bug 1821094 on a test server and one of our testers provided a comment on the bug |
| 15:08 |
csharp |
that's kind of where we left it as far as I'm aware |
| 15:08 |
sandbergja |
csharp++ |
| 15:08 |
Dyrcona |
So the action item is done. Is any more work required that merits a new action item? |
| 15:09 |
csharp |
I'll check on our end to see if they think the feature is ready |
| 15:09 |
berick |
#info berick Bill Erickson, KCLS |
| 15:10 |
Dyrcona |
#info action item done. |
| 15:10 |
Dyrcona |
#action csharp will check if PINES staff think https://launchpad.net/bugs/1821094 is ready |
| 15:10 |
pinesol |
Launchpad bug 1821094 in Evergreen 3.3 "Item status refresh after editing can get confusingly slow" [Medium,Confirmed] |
| 15:11 |
Dyrcona |
Next item |
| 15:11 |
Dyrcona |
#info berick will consider approaches to https://launchpad.net/bugs/1627373 |
| 15:11 |
pinesol |
Launchpad bug 1627373 in Evergreen "Acq: We need to fully implement EDI availability codes" [Wishlist,New] |
| 15:11 |
berick |
i need to carry that one over for next time |
| 15:12 |
Dyrcona |
#info action item tabled until next meeting |
| 15:12 |
Dyrcona |
#info csharp will organize a spreadsheet of needsdiscussion bugs to be walked through during bugsquash week |
| 15:13 |
csharp |
since bugsquash week was overtaken by covid-19 closures, etc., that didn't happen :-/ |
| 15:13 |
csharp |
I can do it before the next one |
| 15:13 |
Dyrcona |
#info action tabled because of pandemic |
| 15:14 |
Dyrcona |
#action csharp will organize a spreadsheet of needsdiscussion bugs to be walked through during next bugsquash week |
| 15:14 |
Dyrcona |
Hmm, guess I should add berick's as another action... |
| 15:14 |
Dyrcona |
#action berick will consider approaches to https://launchpad.net/bugs/1627373 |
| 15:14 |
pinesol |
Launchpad bug 1627373 in Evergreen "Acq: We need to fully implement EDI availability codes" [Wishlist,New] |
| 15:15 |
Dyrcona |
Any other discussion about the above items? |
| 15:16 |
Dyrcona |
If not, moving on.... |
| 15:17 |
Dyrcona |
#topic OpenSRF Release Info |
| 15:17 |
|
Topic for #evergreen is now OpenSRF Release Info (Meeting topic: 2020-05-05 - Developer Meeting) |
| 15:17 |
Dyrcona |
I'm not sure that we have any releases planned, but there is 1 bug that I want to mention in relation to a potential future release: https://bugs.launchpad.net/opensrf/+bug/1874510 |
| 15:17 |
pinesol |
Launchpad bug 1874510 in OpenSRF 3.1 "Chunked message reassembly leads to premature request timeout" [Medium,Confirmed] |
| 15:18 |
berick |
i'll merge that one shortly unless someone beats me to it |
| 15:18 |
Dyrcona |
I signed off on the path, but thought someone else should have a look. If that goes in, I think it is worthy of a bug release. |
| 15:19 |
Dyrcona |
Who normally does the OpenSRF releases, gmcharlt? |
| 15:19 |
gmcharlt |
Dyrcona: aye |
| 15:20 |
gmcharlt |
I'm in another meeting, but at risk of really opening myself up, am wiling to take action items |
| 15:20 |
berick |
heh |
| 15:20 |
Dyrcona |
Are there any special steps required? |
| 15:20 |
gmcharlt |
Dyrcona: not particularly |
| 15:20 |
Dyrcona |
Well, if it's not any hard than doing an Evergreen release and the steps are documented somewhere or as easy as "make release" then I'd be happy to help out. |
| 15:22 |
gmcharlt |
there are steps on the wik page |
| 15:23 |
Dyrcona |
OK. I'll have a look after the meeting. Not sure this is action-worthy. |
| 15:23 |
Dyrcona |
#info tentative OpenSRF releases to coincide with Evergreen 3.5.0 or RC |
| 15:23 |
Dyrcona |
And that would bring us to..... |
| 15:23 |
Dyrcona |
#topic Evergreen Release Info |
| 15:23 |
|
Topic for #evergreen is now Evergreen Release Info (Meeting topic: 2020-05-05 - Developer Meeting) |
| 15:24 |
berick |
i can summarize some stuff.. |
| 15:25 |
berick |
3.5rc was delayed, of course. it has not been forgotten! we're just wrapping up a few issues |
| 15:25 |
berick |
hoping to merge bug 1847800 very soon |
| 15:25 |
pinesol |
Launchpad bug 1847800 in Evergreen "Missing links to secondary admin pages" [High,Confirmed] https://launchpad.net/bugs/1847800 |
| 15:25 |
berick |
which was identified by several people as critical |
| 15:26 |
berick |
once that's merged, the plan is to do a 3.4 release first, followed directly by 3.5 rc1 |
| 15:26 |
Dyrcona |
berick++ |
| 15:26 |
berick |
that way 3.5 can use the latest 3.4 sql as its basis |
| 15:26 |
berick |
specifically to address the complexity introduced by the money aging bug |
| 15:26 |
csharp |
stat: we've committed fixes for 24 of the 32 bugs targeted to 3.5.0 |
| 15:27 |
Dyrcona |
us++ |
| 15:27 |
Dyrcona |
csharp++ |
| 15:27 |
sandbergja |
berick++ |
| 15:27 |
berick |
csharp++ |
| 15:27 |
sandbergja |
csharp++ |
| 15:27 |
berick |
yes, the delay has allowed us to get quite a few more bug merged. thanks for the parallel attention |
| 15:28 |
Dyrcona |
#info Evergreen 3.5.0RC1 planned after https://launchpad.net/bugs/1847800 fix is committed |
| 15:28 |
pinesol |
Launchpad bug 1847800 in Evergreen "Missing links to secondary admin pages" [High,Confirmed] |
| 15:28 |
berick |
nothing else from me unless there are questions re: 3.5 |
| 15:28 |
Bmagic |
I'd like to discuss the docs stuff |
| 15:28 |
Dyrcona |
OK, Bmagic. Go ahead. |
| 15:29 |
Bmagic |
not sure if it needs to run parrallel to an EG release, but the Antora stuff is looking pretty good: eg-docs.georgialibraries.org/prod/ |
| 15:30 |
Bmagic |
It's not clear what is required for it to merge - for example: the server-side code that makes the pages that might be server specific should be in the EG repo? |
| 15:30 |
|
Innarri joined #evergreen |
| 15:31 |
Dyrcona |
What benefit do we get from having the server-side code in Eg proper versus separate? |
| 15:32 |
Bmagic |
The old docs need preserved somehow as well. It was mentioned that they could be "slurped" and linked. Not sure if there should be code for that either? |
| 15:32 |
|
Innarri joined #evergreen |
| 15:33 |
Bmagic |
Dyrcona: One benefit is, we won't lose it. The code that runs our current docs is sometimes gone or inaccesible... |
| 15:33 |
Dyrcona |
I'm personally a bit unclear on the relationship of antora documentation and the current documentation, etc. |
| 15:34 |
Dyrcona |
So, is antora meant to replace the current docs server? But, right now, it can't? |
| 15:34 |
Bmagic |
the current docs have been modified slightly to be Antora-friendly |
| 15:34 |
Bmagic |
replace - yes |
| 15:35 |
Bmagic |
At the same time - we've a new docs server. It seems to me that the Antora branch could easily be merged with no affect on anything else? |
| 15:36 |
berick |
Bmagic: that would be collab/blake/LP1848524_antora_ize_docs ? |
| 15:37 |
Bmagic |
yes |
| 15:38 |
* Dyrcona |
senses an action item item coming up.... |
| 15:38 |
berick |
ok so it all sits in docs-antora and some changes to docs |
| 15:38 |
Bmagic |
it would need a quick change to make it ready. Change the config to point to "master" - and then for the 3.5 branch, the config changed to "tags/rel_3_5" |
| 15:38 |
Bmagic |
the final nail will be to blow away docs/* and rename docs-antora -> docs |
| 15:39 |
Dyrcona |
Bmagic: Do you think it is ready for the final nail, or would more work be required? |
| 15:40 |
Bmagic |
I think it's ready - with the exception of telling everyone who might have outstanding docs/* changes in working branches - to merge or forever hold your peace |
| 15:40 |
berick |
Bmagic: this would be a master-only commit? |
| 15:41 |
berick |
or do you expect to merge to 3.5 as well? |
| 15:41 |
Bmagic |
Antora is setup internally to deal with git branches for doc versioning - therefore, it can have a master "version" and a 3_5 "version" each with a small change in antora.yml |
| 15:42 |
Dyrcona |
So, if I understand correctly, you're asking to have this in for 3.5, right? |
| 15:42 |
berick |
well for 3.5 i'm a little concerned at such a big doc change at this point might be too disruptive |
| 15:43 |
Bmagic |
I think it would need to hit master before the cut, and it would branch with 3_5 - I'm happy with the group thoughts on the matter. Perhaps it can merge to master between releases.. |
| 15:43 |
miker |
yeah, I think this big of a change should be at the beginning of the dev cycle rather than the end |
| 15:43 |
csharp |
I would be more comfortable with a target of 3.6 - yeah - what others are saying :-) |
| 15:43 |
|
mantis1 left #evergreen |
| 15:43 |
Bmagic |
sounds good |
| 15:44 |
Dyrcona |
#info antora docs branch revisited after 3.5 release for 3.6 |
| 15:44 |
Bmagic |
changes to docs/* needs to be "backported" to collab/blake/LP1848524_antora_ize_docs in the meantime |
| 15:44 |
Dyrcona |
Bmagic: you should be able to rebase on master, no? |
| 15:45 |
Bmagic |
I don't think the files are hooked up 1:1 |
| 15:46 |
dbwells |
#info dbwells = Dan Wells, Hekman Library, Calvin University (and late) |
| 15:46 |
Dyrcona |
Bmagic: If you want help with that, I'm sure we'll be able to make it happen. |
| 15:47 |
Bmagic |
cool, thanks for taking the time today to talk about that |
| 15:47 |
Dyrcona |
So, anything else for Evergreen releases? |
| 15:48 |
csharp |
Bmagic: looking forward to testing it out |
| 15:48 |
Bmagic |
csharp: feel free to click through what's there http://eg-docs.georgialibraries.org/prod/ |
| 15:49 |
csharp |
oh cool |
| 15:50 |
Dyrcona |
#topic New Business |
| 15:50 |
|
Topic for #evergreen is now New Business (Meeting topic: 2020-05-05 - Developer Meeting) |
| 15:51 |
Dyrcona |
I added the one agenda item under new business partly because of bug 1873286. |
| 15:51 |
pinesol |
Launchpad bug 1873286 in Evergreen 3.4 "jQuery 3.5.0 breaks at least AngularJS interfaces" [Critical,Fix committed] https://launchpad.net/bugs/1873286 |
| 15:53 |
Dyrcona |
I think jQuery and jQueryUI could also be used to resolve some date-related bugs in the OPAC such as: bug 1723651 and bug 1814150. |
| 15:53 |
pinesol |
Launchpad bug 1723651 in Evergreen "Use HTML5 Date Element in the OPAC" [Wishlist,New] https://launchpad.net/bugs/1723651 |
| 15:53 |
pinesol |
Launchpad bug 1814150 in Evergreen "Self-registration: system accepts wrong DOB format" [Medium,Confirmed] https://launchpad.net/bugs/1814150 |
| 15:54 |
Dyrcona |
I also think it could be used to replace the Dojo that is occasionally used int he OPAC, such as for the Overdrive integration. |
| 15:55 |
JBoyer |
Outright requiring it would also make it easier to stamp out those odd situations where JS fails if it's included, like bug 1739666 |
| 15:55 |
pinesol |
Launchpad bug 1739666 in Evergreen "Publication Date "Between" option doesn't work if jQuery is enabled in the OAPC." [Medium,Confirmed] https://launchpad.net/bugs/1739666 |
| 15:55 |
Dyrcona |
JBoyer, yes, I was about to mention the presence of those bugs. |
| 15:56 |
csharp |
sounds like a solid case for it (not knowing what's involved, really) |
| 15:56 |
jeffdavis |
I've added the "jquery" tag to the 3 bugs I know of where enabling jQuery breaks something in the OPAC |
| 15:56 |
Dyrcona |
So, I guess what I'm really asking is what everyone thinks about going with jQuery in the OPAC, and possibly requiring it? |
| 15:56 |
csharp |
you had me at "replace the Dojo" :-) |
| 15:56 |
Bmagic |
lol |
| 15:56 |
Dyrcona |
jeffdavis++ Yes, that jogged my memory on them. |
| 15:56 |
Dyrcona |
:) |
| 15:57 |
Dyrcona |
Not hearing any outright opposition, I suppose the next step would be to make a Lp bug and start a branch. |
| 15:57 |
csharp |
+1 |
| 15:58 |
jeffdavis |
I'm less familiar with jQueryUI |
| 15:58 |
csharp |
https://www.youtube.com/watch?v=PVhTDNlbsSc |
| 15:58 |
Dyrcona |
#action Dyrcona will open a Lp bug about adding jQuery and jQueryUI to the OPAC |
| 15:58 |
jeffdavis |
I wonder if it is less supported/more likely to become unsupported |
| 15:58 |
jeffdavis |
...than jQuery proper |
| 15:58 |
Dyrcona |
I've not read anything about jQueryUI deprecation. |
| 15:59 |
jeffdavis |
looks like the last stable release was 4 years ago |
| 15:59 |
Dyrcona |
I've experimented with some of the widgets, and the datepicker would be particularly useful since we can't rely on HTML5 because of Safari on Mac OS X. |
| 16:00 |
jeffdavis |
And the last commit was in Dec. But we can discuss that via LP, not important for today's meeting. |
| 16:00 |
csharp |
seems to be actively developed: https://github.com/jquery/jquery-ui |
| 16:00 |
csharp |
yeah |
| 16:01 |
Dyrcona |
Ok, anyone have anything else for new business? |
| 16:02 |
Dyrcona |
Does anyone have anything to bring up about needsdiscussion or qaproject bugs? |
| 16:06 |
Dyrcona |
Not hearing anything, I declare the meeting adjourned! |
| 16:06 |
Dyrcona |
#endmeeting |
| 16:06 |
|
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:06 |
pinesol |
Meeting ended Tue May 5 16:06:08 2020 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 16:06 |
pinesol |
Minutes: http://evergreen-ils.org/meetings/evergreen/2020/evergreen.2020-05-05-15.02.html |
| 16:06 |
pinesol |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2020/evergreen.2020-05-05-15.02.txt |
| 16:06 |
pinesol |
Log: http://evergreen-ils.org/meetings/evergreen/2020/evergreen.2020-05-05-15.02.log.html |
| 16:06 |
Bmagic |
Dyrcona++ |
| 16:06 |
csharp |
Dyrcona++ |
| 16:06 |
dbwells |
I do feel like jQueryUI is generally falling out of favor. The big-name, basically monolithic JS front-ends have really squeezed it out from one side, and general browser/widget improvements have squeezed from the other side. |
| 16:06 |
dbwells |
Dyrcona++ |
| 16:06 |
JBoyer |
Dyrcona++ |
| 16:07 |
Dyrcona |
dbwells: Yes, that does seem to be happening, but as long as Safari lags the other browsers, particularly with respect to date inputs, I think jQueryUI, at least 1 component of it would be useful. |
| 16:08 |
Dyrcona |
And, we can build a custom jQueryUI distro that only includes what we need. |
| 16:08 |
dbwells |
The same might really be said for jQuery as a whole, though to a lesser degree so far. I am fine with using older projects that are still quite stable. I remember 2016 pretty well, it wasn't so bad :) |
| 16:09 |
Dyrcona |
:) |
| 16:09 |
Dyrcona |
Well, there is the option of reimplementing the OPAC with Angular. |
| 16:10 |
dbwells |
No, no, let's do AngularJS first. We only know one way! |
| 16:12 |
* dbwells |
slinks back into the shadows |
| 16:18 |
Dyrcona |
:) |
| 17:06 |
|
mmorgan left #evergreen |
| 17:11 |
gmcharlt |
Dyrcona++ |
| 17:33 |
Bmagic |
Dyrcona: the comment about rebasing master - this collab branch rebases master with no conflicts. I've compared current master docs/* against the docs/* in the collab branch - found some differences - so now the task is to integrate those differences into docs-antora - you have ideas on using git to do that for us? |
| 17:37 |
berick |
Bmagic: if the file names are the same (for the modified files) within the docs and docs-antora directories, you could create a patch of the changes to docs and apply it to docs-antora |
| 17:37 |
Bmagic |
I think in most cases the filenames are the same - though folder paths are different - I'll look into the syntax for making a patch for a single file |
| 17:38 |
berick |
git diff --patch / git am (w/ various flags) |
| 17:41 |
Bmagic |
git diff would need to generate output first - therefore, I'd need to be in a state where my desired diffs existed on the old docs/x/y/z file |
| 17:41 |
Bmagic |
yeah? |
| 17:42 |
berick |
or specify a range of commit hashes |
| 17:43 |
berick |
e.g. git diff 2b259e3ef6~1..f643bea30c |
| 17:43 |
pinesol |
berick: [evergreen|Bill Erickson] LP1850955 Angular build targets modernized - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2b259e3> |
| 17:43 |
pinesol |
berick: [evergreen|Jason Boyer] LP1850955: Include changes to package-lock.json - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f643bea> |
| 17:43 |
berick |
with ~1 being the parent commit (which is often useful since first commit is not inclusive) |
| 17:43 |
berick |
heh |
| 17:43 |
Bmagic |
unwinding that - I'd need to narrow those to commits for docs files |
| 17:44 |
berick |
or use --relative |
| 17:44 |
berick |
and specify the path |
| 17:44 |
Bmagic |
starting to see it in my head |
| 17:45 |
Bmagic |
trying some things.. |
| 17:49 |
Bmagic |
git diff 3b067004fc95c8b92b757a8...d338486c851339b --relative docs/ seems to hit it |
| 17:49 |
pinesol |
Bmagic: [evergreen|Bill Erickson] LP1824391 Hatch File Writer release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3b06700> |
| 17:49 |
pinesol |
Bmagic: [evergreen|Chris Sharp] LP#1873048 - Stamp upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d338486> |
| 17:49 |
Bmagic |
phew - glad pinesol didn't post ALL of the patches in that chain |
| 17:50 |
|
sandbergja joined #evergreen |
| 17:54 |
Bmagic |
I have a patch file for the target differing files - https://git-scm.com/docs/git-am doesn't seem to inform me how to make it patch *different* files |
| 17:55 |
Bmagic |
oh well - something for tomorrow - have a good evening Evergreen! |
| 18:00 |
berick |
Bmagic: oops, I mean 'git apply'. if the only difference is the path to the file, see the -p flag |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:05 |
|
sandbergja joined #evergreen |
| 18:37 |
|
sandbergja_ joined #evergreen |
| 20:14 |
|
sandbergja joined #evergreen |
| 22:04 |
|
sandbergja joined #evergreen |
| 23:20 |
|
eady joined #evergreen |
| 23:40 |
|
sandbergja joined #evergreen |
