| Time |
Nick |
Message |
| 00:19 |
|
abowling joined #evergreen |
| 01:29 |
|
abowling1 joined #evergreen |
| 01:30 |
|
abowling1 left #evergreen |
| 01:31 |
|
abowling1 joined #evergreen |
| 01:32 |
|
abowling1 left #evergreen |
| 03:01 |
|
mrisher_ joined #evergreen |
| 04:49 |
|
mrisher joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:00 |
|
agoben joined #evergreen |
| 07:13 |
|
rjackson_isl_hom joined #evergreen |
| 07:40 |
|
angelo joined #evergreen |
| 07:48 |
angelo |
does anyone have experience migrating data from one evergreen server to another? i have a new install of an evergreen server that i need to import data into in the form of TSV files |
| 07:48 |
angelo |
but when i try to import them i get a bunch of DB constraint violation errors |
| 08:02 |
|
Dyrcona joined #evergreen |
| 08:08 |
|
mantis1 joined #evergreen |
| 08:15 |
|
angelo left #evergreen |
| 08:15 |
|
angelo joined #evergreen |
| 08:16 |
|
angelo left #evergreen |
| 08:16 |
|
angelo joined #evergreen |
| 08:17 |
|
angelo left #evergreen |
| 08:17 |
|
rfrasur joined #evergreen |
| 08:18 |
|
angelo joined #evergreen |
| 08:19 |
angelo |
can anyone see this? |
| 08:22 |
agoben |
Yes, but I can't offer you any answers on your earlier questions. |
| 08:22 |
angelo |
oh perfect, i wasnt sure if i was registered or not |
| 08:23 |
agoben |
You might try posting again in an hour or so. More support staff will be watching the chat by then. Good luck with your migration! |
| 08:23 |
angelo |
thanks, will do |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:45 |
Dyrcona |
angelo: Are you trying to move everything from one Evergreen instance to another, or is it just selected data from the source database? |
| 08:50 |
|
tlittle joined #evergreen |
| 08:57 |
|
angelo joined #evergreen |
| 08:57 |
angelo |
Dyrcona its an export of certain data |
| 08:58 |
angelo |
the old host is not giving us any assitance because we are moving away from them so they just dumped the tables |
| 08:58 |
Dyrcona |
angelo: You'll have to disable the constraints in the target database and re-enable them after the load is finished, and hope you didn't miss any crucial data. |
| 08:59 |
angelo |
ok, ill give that a try |
| 08:59 |
angelo |
thanks |
| 09:00 |
Dyrcona |
Also, pay attention to the constraint messages because loading the data in a certain order may help. |
| 09:01 |
Dyrcona |
For instace, the actor.org_unit table should be the very first data loaded. Without those entries, nothing else works. |
| 09:05 |
|
collum joined #evergreen |
| 09:18 |
|
Stompro joined #evergreen |
| 09:32 |
rhamby |
so you have a bunch of delimited files but not a dump, I take it this is a subset of the data and that's why you don't have an actual postgres dump file? |
| 09:37 |
Dyrcona |
rhamby: That's what it sounds like, and I wonder how complete the data really is. |
| 09:37 |
rhamby |
Dyrcona: yeah, depends and what from, for example if they're from the migration-tools export script it's fairly complete data wise but not really meant to rebuild an evergreen instance from |
| 09:38 |
rhamby |
I would assume dragons would live in those waters actually. |
| 09:38 |
Dyrcona |
Yeah. If it's done by hand, then who knows what they've got. |
| 09:39 |
rhamby |
yeppers |
| 09:39 |
Dyrcona |
I was also just about to suggest that angelo have a look at the migration tools: https://github.com/EquinoxOpenLibraryInitiative/migration-tools |
| 09:41 |
rhamby |
and that reminds me I need to put on my todo when when I have time (hah) to audit the actor schema for tables that should be added to the export script |
| 09:42 |
angelo |
thanks @dy |
| 09:42 |
angelo |
@dy |
| 09:42 |
pinesol |
angelo: http://cat.evergreen-ils.org.meowbify.com/ |
| 09:42 |
angelo |
Dyrcona omg, clicking too soon, thank you |
| 09:43 |
angelo |
pinesol that link goes nowhere |
| 09:43 |
pinesol |
angelo: It reads like a Nigerian 419 scam, but I think it is a sincere question sent to the wrong list. |
| 09:45 |
Dyrcona |
Looks like meobify.com doesn't work any more. |
| 09:45 |
* Dyrcona |
had trouble typing the URL to visit the home page, too. |
| 09:47 |
Dyrcona |
pineol: Be nice. |
| 09:47 |
Dyrcona |
pinesol, even.... :) |
| 09:47 |
pinesol |
Dyrcona: We're going to need a bigger boat. |
| 09:47 |
Dyrcona |
My fingers don't seem to want to cooperate this morning. |
| 09:48 |
csharp |
angelo: pinesol is our channel bot and @ is the prefix for bot commands - when addressing someone individually, just use their nick with no @ |
| 09:48 |
csharp |
@blame pinesol |
| 09:48 |
pinesol |
csharp: itself is probably integrated with systemd |
| 09:49 |
angelo |
csharp thanks |
| 09:51 |
csharp |
+ |
| 09:51 |
gmcharlt |
yikes, the bot is feeling stroppy today! |
| 09:52 |
csharp |
@insult pinesbot |
| 09:52 |
pinesol |
pinesbot: You are nothing but a weasel-smelling pile of off-color snake. |
| 09:52 |
csharp |
heh - "pinesbot" is the name of our XMPP channel bot on another platform so muscle memory did that |
| 09:52 |
angelo |
**skynet activated** |
| 09:53 |
csharp |
angelo++ |
| 09:53 |
Dyrcona |
angelo++ and welcome to the club! |
| 09:53 |
angelo |
thanks! |
| 09:54 |
csharp |
angelo: if you can pastebin the format of your data files somewhere (pastebin.com, paste.evergreen-ils.org, etc.) people might be able to advise more helpfully |
| 09:54 |
angelo |
i inherited this evergreen project, im just a lowly developer but now a library system admin! |
| 09:54 |
angelo |
csharp i was just looking how to paste in a screen shot of the files to see if anyone recognized the format |
| 09:54 |
csharp |
(cleansed of any sensitive data, of course, just the column structure) |
| 09:55 |
|
stompro_ joined #evergreen |
| 09:55 |
Dyrcona |
Yeah, the header lines should be enough. |
| 09:55 |
angelo |
https://pasteboard.co/JkOvo5j.png |
| 09:55 |
angelo |
thats what was in the zip |
| 09:58 |
rhamby |
angelo: that is a dead ringer for the export script output from migration-tools |
| 09:59 |
rhamby |
those files have complete data but the export wasn't designed to be a quick rebuild for an evergreen instance |
| 09:59 |
csharp |
angelo: and most people here inherited their sys admin roles, so you're in good company :-) |
| 10:00 |
angelo |
csharp i need a new rack for all my hats |
| 10:09 |
rhamby |
angelo: I don't know if this is enough detail to be helpful but the way I'd aprpoach that kind of migration/data loading is to create a bunch of child tables with the old IDs as legacy values and use those to map to new fresh IDs on a fresh Evergreen install |
| 10:09 |
rhamby |
angelo : it's time consuming but could be largely scripted for an easy repeatable process |
| 10:12 |
csharp |
create a table that matches the columns/data types, then "copy <table name> from '<file>' csv header;" would at least get it into postgres where you can work with it more easily |
| 10:13 |
csharp |
wouldn |
| 10:13 |
csharp |
't need to do that with the MARC files though - they could be imported directly |
| 10:14 |
csharp |
I'm not a migration expert at all, though - our instance has been super static for years |
| 10:14 |
* csharp |
would defer to rhamby and people like Bmagic |
| 10:14 |
* Bmagic |
scrolls up |
| 10:15 |
gmcharlt |
e.g., create table actor.org_unit_stage (like actor.org_unit); |
| 10:15 |
|
stompro__ joined #evergreen |
| 10:16 |
Dyrcona |
I'd recommend creating the tables in a staging schema, like the migration tools do in the other import scripts. |
| 10:16 |
rhamby |
a quick not about using psql \copy with tsv files if you use \coopy with tabs you'll need to use the \E flag when you define the '\t' delimiter |
| 10:17 |
rhamby |
i.e. ELIMITER E'\t' |
| 10:17 |
rhamby |
erg, DELIMITER E'\t' |
| 10:17 |
rhamby |
which just says the delimiter is extended and not single character |
| 10:18 |
rhamby |
and my fingers need a lot more caffeine /sigh |
| 10:18 |
Dyrcona |
@coffee rhamby |
| 10:18 |
* pinesol |
brews and pours a cup of Sumatra Lake Tawar, and sends it sliding down the bar to rhamby |
| 10:18 |
rhamby |
mmmmm |
| 10:18 |
Bmagic |
I wrote a script to migrate Evergreen -> Evergreen... linking it here if it might be helpful |
| 10:19 |
Bmagic |
it does exactly that: makes a schema, and tons of inherited tables... automates all of those columns and maps old ID -> new ID |
| 10:20 |
Bmagic |
https://github.com/mcoia/mobius_evergreen/blob/master/Random/migrate_evergreen.pl |
| 10:20 |
Bmagic |
angelo: It won't work for you "out of the box" - but maybe* you could use some of the ideas. It shows some of the things that rhamby and gmcharlt have mentioned about staging tables |
| 10:21 |
rhamby |
yeah, if you're comfortable with postgres it's not hard but there will be an evergreen data learning curve |
| 10:21 |
Bmagic |
that script will at least give you a full list of important tables. Something to start with hopefully |
| 10:28 |
angelo |
i dont suppose there is an import script as part of migration tools lol |
| 10:28 |
Bmagic |
looking deeper - that script is just one part of the equation. You will also need this one: https://github.com/mcoia/mobius_evergreen/blob/master/Random/migrate_evergreen.sql |
| 10:29 |
Bmagic |
It's not strictly a sql file - it's more of a crib sheet :) |
| 10:30 |
rhamby |
angelo : it wouldn't be impossible to write such as script but there isn't at this point, if you write one feel to do a push request though :) |
| 10:55 |
|
dbwells joined #evergreen |
| 10:58 |
angelo |
would this accomplsh the import? |
| 10:58 |
angelo |
http://docs.evergreen-ils.org/2.1/html/migrating_records_using_migration_tools.html |
| 10:59 |
|
dbwells_ joined #evergreen |
| 11:00 |
Bmagic |
angelo: you have several challenges. Those import instructions will get you close to importing the marc. You need to get all the rest of those files into the database. Into a staging table, where you can operate on the data and get them into their final destination production tables |
| 11:02 |
rhamby |
angelo : it's going to be a substantial project |
| 11:03 |
Bmagic |
angelo: what rhamby said. Sorry :) - I wish there was a script to do this for you but there isn't (right now) |
| 11:04 |
rhamby |
I can pretty easily see how to write a script to fire and forget how to do it with the output from migration-tools but it would be enough work that I wouldn't just hack it together on the side |
| 11:06 |
angelo |
yeah im just not familiar enough with the data structure to write anything |
| 11:08 |
Bmagic |
Too bad you don't have the original database or at least access to it. Those scripts I linked above would have worked pretty much out of the box. With a little shim though, they could still work. Just need to import the data from files instead of from a database |
| 11:18 |
csharp |
angelo: how are your postgresql skills? |
| 11:19 |
angelo |
never used it until now, but im familiar with MSSQL and MySQL if that matteres |
| 11:19 |
csharp |
it does matter - just some differences in dialect |
| 11:20 |
csharp |
angelo: is the Evergreen database up and running yet? |
| 11:20 |
angelo |
yeah |
| 11:21 |
csharp |
ok, then I would just focus on getting each file imported into staging tables, then you can get more familiar with Evergreen's data structures so you can map everything |
| 11:21 |
Bmagic |
the way I see it: 1. Setup empty PG DB. 2. Create default EG schema from repo. 3. Shim migrate_evergreen.pl to read in files, including mrc (hopefully 901c is there). 4. Follow the steps in migrate_evergreen.sql. 5. Success! |
| 11:21 |
csharp |
everyone who's speaking up about this is very familiar with the DB structure and can help you |
| 11:22 |
Bmagic |
angelo: yep! We got you! |
| 11:22 |
angelo |
thanks guys |
| 11:22 |
angelo |
i got an empty staging table setup in postgre |
| 11:22 |
angelo |
i copied the existing EGDB |
| 11:23 |
Bmagic |
wha??! You have the DB? |
| 11:23 |
angelo |
i was going to copy the tsv files into the staging db |
| 11:23 |
angelo |
the one that came with the default install |
| 11:24 |
Bmagic |
oh ok - the default EG db can be re-created at will from the EG repo |
| 11:25 |
angelo |
ok |
| 11:25 |
angelo |
can i copy the schema without the data into the staging table? |
| 11:25 |
Bmagic |
not sure I am following - which schema? |
| 11:26 |
angelo |
i suppose all of them, so i can import the data into a staging table to work with it and get it into prod |
| 11:26 |
Bmagic |
This section of the Evergreen install instructions will create the EG database (and schemas and functions, etc) |
| 11:26 |
Bmagic |
https://evergreen-ils.org/documentation/install/README_3_3.html#_creating_the_evergreen_database |
| 11:27 |
Bmagic |
that perl script up there will create a staging schema for you - and populate it with the data (from another EG DB, but we want to change that to "from files") |
| 11:30 |
Bmagic |
Once you get those files (that you showed in your screen shot) - into the staging schema tables - you are half way there! |
| 11:31 |
Bmagic |
FYI - Unlike MYSQL - Postgres has another path layer: schema. In PG there is a "database", and below that are "schemas" and then finally "tables" - MYSQL is: Database -> tables. So keep that in mind. There will always be a schema designation for your queries |
| 11:32 |
angelo |
yeah i got that, where are you seeing the "from files" optioon? |
| 11:32 |
angelo |
i dont see that in the help for eg_db_config |
| 11:32 |
Bmagic |
The "from files" option is not coded :) |
| 11:33 |
Bmagic |
that is the piece that you are missing |
| 11:34 |
Bmagic |
I was thinking that the work I did with the migrate_evergreen.pl perl script could save you some time, and just edit that script to read your files instead of another database. It's not "simple" but with an hour or two I bet a perl programmer could get it functioning |
| 11:35 |
angelo |
ok so i dumped the schemas into an empty db for staging, would the next step be to import the TSV data into that DB? |
| 11:36 |
Bmagic |
alternatively, you could manually create the schema, and file by file, import them into pre-created staging tables, column by column |
| 11:38 |
Bmagic |
angelo: yes, that's the next step - either make them by hand or make that script do it for you. How many files are we talking about? |
| 11:38 |
|
nfBurton joined #evergreen |
| 11:38 |
angelo |
looks like under 100 |
| 11:40 |
Bmagic |
I wouldn't want to make 100 tables by hand but more power to you! Does each TSV file contain a header row? With column names? |
| 11:40 |
angelo |
i got the tables created already |
| 11:40 |
angelo |
by using the dump |
| 11:41 |
Bmagic |
tables that will accept each of these ~100 files? |
| 11:41 |
|
sandbergja joined #evergreen |
| 11:43 |
angelo |
yeah, its the same schema and tables as the default EG db |
| 11:43 |
Bmagic |
the issue is: you don't want to import these files directly into the EG database production tables |
| 11:43 |
angelo |
yeah im using a staging DB |
| 11:43 |
Bmagic |
CREATE SCHEMA m_staging |
| 11:44 |
Bmagic |
CREATE TABLE m_staging.file_name (l_col1 TEXT, l_col2 TEXT, l_col3 TEXT, l_col4 TEXT, ......); |
| 11:45 |
Bmagic |
\copy m_staging.file_name (l_col1 TEXT, l_col2 TEXT, l_col3 TEXT, l_col4 TEXT, ......) from /filename |
| 11:47 |
Bmagic |
back on that CREATE TABLE statement, I would make it "inherit" from the related production table so that you get all the related production columns in your child table - and then you get a nice ID->ID map created for you |
| 11:47 |
|
sandbergja joined #evergreen |
| 11:57 |
|
alynn26 joined #evergreen |
| 12:00 |
angelo |
is there a way to disable constrains without removing them completely? |
| 12:00 |
|
jihpringle joined #evergreen |
| 12:00 |
Bmagic |
it sounds like you are wanting to import these files directly into the production tables? If you use the staging schema, you won't have that problem. One of the main reasons we import files like this into staging schemas |
| 12:01 |
angelo |
i created a dump from the prod db to import the schemas without data into a staging db |
| 12:01 |
angelo |
im trying to import the files into that staging db |
| 12:01 |
Bmagic |
but yes - you can disable constraints without removing them. It will be table specific and IMO much more work than you need to do |
| 12:01 |
angelo |
but it brought the contraints over with the dump |
| 12:02 |
Bmagic |
I am confused - you have a pg_dump file that contains the default EG database? No data? |
| 12:02 |
angelo |
yes |
| 12:02 |
angelo |
just schemas and tables |
| 12:03 |
Bmagic |
You don't need that. Let the Evergreen repository make the database for you |
| 12:03 |
angelo |
wouldnt that still put the constraints in place? |
| 12:04 |
Bmagic |
yes, and that's OK |
| 12:04 |
angelo |
but when i try and import the TSV i get the constraint error |
| 12:05 |
Bmagic |
sure, because you are importing the data directly into the production table right? |
| 12:05 |
angelo |
no, into the table in the staging db i created |
| 12:05 |
Bmagic |
please share your command that produces the error |
| 12:06 |
|
dbwells joined #evergreen |
| 12:06 |
angelo |
staging=# COPY actor.org_unit FROM '/home/evergreen/client/client/items/actor.org_unit.tsv'; |
| 12:06 |
Bmagic |
actor.org_unit <-- production table |
| 12:06 |
angelo |
ERROR: insert or update on table "org_unit" violates foreign key constraint "actor_org_unit_billing_address_fkey" |
| 12:07 |
Bmagic |
you want m_staging.actor_org_unit |
| 12:07 |
angelo |
ok when you said production i thought you meant the actual eg db |
| 12:07 |
Bmagic |
sorry, that's what I mean by production table. Any table that is "For Evergreen production functionality" |
| 12:08 |
angelo |
where did you get m_staging.actor_ord_unit |
| 12:08 |
Bmagic |
you have to create it |
| 12:08 |
angelo |
with the columns and everything |
| 12:08 |
Bmagic |
I wrote the an example command for you above |
| 12:08 |
Bmagic |
yep! |
| 12:08 |
Bmagic |
a real pain |
| 12:08 |
angelo |
ahh |
| 12:08 |
Bmagic |
that's why I was recommending that script |
| 12:08 |
angelo |
could i just remove the constraints in my staging DB? |
| 12:09 |
Bmagic |
you could but if you knew the amount of constraints/triggers/business logic that you would be dealing with, you would choose to do what I am suggesting instead :) |
| 12:11 |
Bmagic |
Admittedly it's lots of work either way. But the staging schema -> into production tables is the "Safer" and "sure" way to ensure data integrity while at the same time letting the Evergreen DB do what it's deisgned to do when things are INSERTED and UPDATED |
| 12:13 |
angelo |
ok thanks bmagic, i need to sign off for a little, ill see what i come up with and report back |
| 12:13 |
angelo |
thanks for everyone's help |
| 12:13 |
Bmagic |
no problem! Good luck. We are usually here during business hours |
| 12:13 |
angelo |
sounds good, im sure ill be back |
| 12:14 |
Bmagic |
:) |
| 12:14 |
angelo |
idk where you guys are located, but i need to go prep for the hurricane coming up the east coast of the US |
| 12:14 |
Bmagic |
Oh man! That is arguably more important than Evergreen migration |
| 12:15 |
angelo |
if only upper management thought so |
| 12:15 |
angelo |
lol |
| 12:15 |
angelo |
ttyl |
| 12:24 |
|
mrisher joined #evergreen |
| 12:25 |
|
mrisher joined #evergreen |
| 12:27 |
|
rjackson_isl_hom joined #evergreen |
| 12:31 |
Bmagic |
I have a question of my own. I just noticed that I have 973 entries in acq.edi_message for the exact same file with the exact same edi message |
| 12:32 |
Bmagic |
should edi_import ignore already-processed files from the ftp server? |
| 12:32 |
Bmagic |
edi_fetcher.pl rather |
| 12:37 |
|
jvwoolf joined #evergreen |
| 12:41 |
Bmagic |
it seems (from looking at Application::Acq::EDI::retrieve_core it does "dedupe" |
| 12:49 |
Bmagic |
I found in my logs where it open-ils.cstore.direct.acq.edi_message.id_list.atomic looks up a matching row in the database, and the return is "1 result(s)" |
| 12:52 |
Bmagic |
therefore, I would expect to see another log message for "already retrieved" but I don't. Instead I see " 1 of 187 targets: ftp://server/filename" |
| 12:55 |
Bmagic |
well, if I am reading these logs correctly (debug is not turne don) - I don't see the message "already retrieved. Skipping" but that's because debug is not on |
| 12:56 |
Bmagic |
so the question is: Will the edi_fetcher software create a new row in acq.edi_message for files that it doesn't process? Trying to find an explaination why I have 973 rows for the same file with the exact same edi message. Each with "processed" status |
| 13:21 |
|
mantis1 joined #evergreen |
| 13:22 |
csharp |
Bmagic: we had that happen early on - I can't remember offhand why though :-/ |
| 13:22 |
Bmagic |
hmmmm, still analyzing the logs |
| 13:22 |
Bmagic |
it runs every half hour and every hour, it looks to see if the file exists. Finds that it DOESN'T and processes it again.... |
| 13:26 |
csharp |
is there an error listed for each edi_message? |
| 13:26 |
|
stompro__ joined #evergreen |
| 13:26 |
Bmagic |
no error |
| 13:26 |
Bmagic |
all of them process just fine |
| 13:29 |
csharp |
what's in the status column for those? |
| 13:29 |
Bmagic |
processed |
| 13:34 |
csharp |
https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Acq/EDI.pm;h=49feb960986c8ad870684cc1bd16c2dd6b6d46d7;hb=refs/heads/master#l122 - that's the (master) query that finds already-processed/errored-out files |
| 13:42 |
Bmagic |
yep! |
| 13:42 |
Bmagic |
was just looking at that bit |
| 13:42 |
Bmagic |
I see the related log messages for the atomic lookup |
| 13:43 |
Bmagic |
and it responds with "0 results" |
| 13:43 |
Bmagic |
open-ils.cstore open-ils.cstore.direct.acq.edi_message.id_list.atomic {"+acqedi":{"host":"ftp://ftp.ingramcontent.com","in_dir":"outgoing","username":"XXXXXX","password":"XXXXXX"},"remote_file":{"=":{"value":["evergreen.lowercase","outgoing/XXXXXXXXXXXXXX.EPR"],"transform":"evergreen.lowercase"}},"status":{"in":["processed","proc_error","trans_error"]}},{"join":{"acqedi":{}},"limit":1} |
| 13:44 |
Bmagic |
sanitized log entry there |
| 13:44 |
Bmagic |
funny thing is that sometimes it responds with "1 result(s)" |
| 13:44 |
Bmagic |
and then, of course, it doesn't process the file |
| 13:45 |
Bmagic |
I wonder if the edi_fetcher.pl script is overlapping runtimes |
| 13:45 |
Bmagic |
the CRONSCRIPT lockfile should keep that at bay though |
| 13:50 |
Dyrcona |
We've had the fetcher and puller overlap and some vendors will not let one log in while the other is connected. Also, it does some stupid stuff when you have multiple accounts for the same vendor. It logs in once for each account even though the credentials and directory are the same. |
| 13:51 |
Dyrcona |
We've also had 1 vendor out right block us for a few hours because that looks like an attack. |
| 13:53 |
Bmagic |
yeah those sound sticky but the fetcher is running and logging into the FTP server and getting directory listings without issue in this case |
| 13:54 |
Bmagic |
the fetcher is running right now... I don't see a LOCK file in /tmp - should it be there? |
| 13:56 |
Bmagic |
the cron passes these switches: ./edi_fetcher.pl -v -d |
| 13:56 |
Bmagic |
I couldn't find those switches in the code.... |
| 14:02 |
Dyrcona |
Bmagic: Are you talking about the fetcher or the pusher, and if the pusher, which one? |
| 14:04 |
Dyrcona |
The fetcher and the old pusher use Cronscript.pm, so they'll recognize -v as "verbose" and -d as "debug." Doesn't mean that they do anything with those options, though. |
| 14:14 |
Bmagic |
fetcher |
| 14:33 |
* JBoyer |
announces a Developer Meeting beginning in approximately 30 minutes |
| 14:35 |
jeffdavis |
JBoyer++ |
| 14:56 |
|
nfBurton joined #evergreen |
| 14:57 |
|
terran joined #evergreen |
| 14:59 |
|
JBoyer left #evergreen |
| 15:00 |
|
JBoyer joined #evergreen |
| 15:00 |
JBoyer |
Ah, love the keyboard shortcut that auto-closes the channel... |
| 15:00 |
JBoyer |
Anyway. |
| 15:01 |
* JBoyer |
bangs drum, shouts DEV MEETING |
| 15:01 |
JBoyer |
#startmeeting 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-08-04 |
| 15:01 |
pinesol |
Meeting started Tue Aug 4 15:01:10 2020 US/Eastern. The chair is JBoyer. 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: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-08-04) |
| 15:01 |
pinesol |
The meeting name has been set to '2020_08_04___developer_meeting__agenda_available_at_https___wiki_evergreen_ils_org_doku_php_id_dev_meetings_2020_08_04' |
| 15:01 |
JBoyer |
#topic Introductions |
| 15:01 |
|
Topic for #evergreen is now Introductions (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-08-04) |
| 15:01 |
berick |
drums, drums in the deep |
| 15:01 |
berick |
#info berick Bill Erickson, KCLS |
| 15:01 |
JBoyer |
#info JBoyer = Jason Boyer, EOLI |
| 15:01 |
Dyrcona |
#info Dyrcona = Jason Stephenson, CWMARS |
| 15:01 |
gmcharlt |
#info gmcharlt = Galen Charlton, EOLI, part of the 3.6 release team |
| 15:01 |
Bmagic |
#info Bmagic = Blake GH, MOBIUS |
| 15:02 |
jeffdavis |
#info jeffdavis = Jeff Davis, BC Libraries Cooperative (Sitka) |
| 15:02 |
mmorgan |
#info mmorgan = Michele Morgan, NOBLE |
| 15:02 |
nfBurton |
#info cburton = Chris Burton, Niagara Falls Public Library |
| 15:02 |
terran |
#info terran = Terran McCanna, PINES |
| 15:03 |
JBoyer |
Folks can feel free to introduce themselves as they continue to come in |
| 15:03 |
JBoyer |
#topic Action Items from Last Meeting |
| 15:03 |
|
Topic for #evergreen is now Action Items from Last Meeting (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-08-04) |
| 15:03 |
JBoyer |
First up, now that I notice he may not be here, csharp was going to ask around PINES if lp 1821094 is ready or needs more testing, terran, do you know how that went? |
| 15:04 |
pinesol |
Launchpad bug 1821094 in Evergreen 3.4 "Item status refresh after editing can get confusingly slow" [Medium,Confirmed] https://launchpad.net/bugs/1821094 |
| 15:04 |
terran |
I'm not sure |
| 15:04 |
miker |
#info mike = Mike Rylander, EOLI |
| 15:05 |
terran |
Elaine was fine with it |
| 15:06 |
alynn26 |
info alynn26 = Lynn Floyd Evergreen Indiana |
| 15:06 |
alynn26 |
#info alynn26 = Lynn Floyd Evergreen Indiana |
| 15:07 |
JBoyer |
Ok, given the pullrequest tag and the comments we can assume it does the thing re: performance and it just needs a signoff and commiting. |
| 15:07 |
JBoyer |
That's positive. |
| 15:07 |
JBoyer |
Action item 2, berick, have you had an opportunity to consider EDI availability codes? |
| 15:07 |
csharp |
#info csharp = Chris Sharp, GPLS |
| 15:08 |
berick |
I have not, but I will |
| 15:08 |
JBoyer |
Before I just add that back on berick, is anyone else working with EDI enough that they would like to take that on or assist? |
| 15:08 |
|
_sandbergja joined #evergreen |
| 15:09 |
csharp |
I can assist |
| 15:09 |
JBoyer |
csharp++ |
| 15:09 |
_sandbergja |
#info _sandbergja is Jane Sandberg, Linn-Benton Community College |
| 15:09 |
_sandbergja |
csharp++ |
| 15:09 |
csharp |
I'll need to refresh my knowledge of them, but yeah |
| 15:09 |
_sandbergja |
berick++ |
| 15:09 |
JBoyer |
#action berick and csharp to consider approaches to lp 1627373 |
| 15:09 |
pinesol |
Launchpad bug 1627373 in Evergreen "Acq: We need to fully implement EDI availability codes" [Wishlist,New] https://launchpad.net/bugs/1627373 |
| 15:10 |
csharp |
I'll follow up with bug 1821094 too - that got dropped (like so many things) |
| 15:10 |
pinesol |
Launchpad bug 1821094 in Evergreen 3.4 "Item status refresh after editing can get confusingly slow" [Medium,Confirmed] https://launchpad.net/bugs/1821094 |
| 15:11 |
JBoyer |
The last carried over action item, Dyrcona, did you have a chance to enter the LP bug about using jQuery in the OPAC? I didn't find it in a cursory search, but LP gonna LP. |
| 15:11 |
Dyrcona |
Nope. I didn't get to it. |
| 15:11 |
csharp |
"2020: I Didn't Get to It" |
| 15:12 |
JBoyer |
Was the intent more than "we should just use it and throw everything else away?" |
| 15:12 |
* csharp |
likes that better than "we're all in this together" and "in these unprecedented times" |
| 15:12 |
JBoyer |
Because I imagine many of us can get behind that. |
| 15:12 |
Dyrcona |
:) |
| 15:12 |
berick |
csharp: :) |
| 15:13 |
nfBurton |
The OPAC I'm targeting for 3.6 has jQuery always enabled |
| 15:13 |
Dyrcona |
The intent was pretty much just replace Dojo with jQuery, and add jQueryUI for datepickers and things. |
| 15:13 |
|
nfBurton34 joined #evergreen |
| 15:13 |
Dyrcona |
And, yeah, with nfBurton's work, it may be obsolete anyway. |
| 15:14 |
miker |
ISTM, since we added a fake $() eons ago, we might as well just make that the real thing |
| 15:14 |
nfBurton34 |
Ugh IRC, but yeah there are a bunch of additions there |
| 15:14 |
JBoyer |
That's what I was thinking. I wouldn't mind replacing all JS use with it, or at least requiring that it doesn't break when jQ is enabled. |
| 15:14 |
JBoyer |
and nfBurton34 , Is the goal of the new OPAC that it's THE OPAC, or one of 2 options? |
| 15:15 |
JBoyer |
miker +1 to that. |
| 15:15 |
nfBurton34 |
THE OPAC, but giving people time to OPT in |
| 15:15 |
nfBurton34 |
Or opt out? |
| 15:15 |
nfBurton34 |
IDK it was suggested it is an 'option' for a version |
| 15:15 |
nfBurton34 |
Kinda Beta-ing it out |
| 15:16 |
csharp |
@band add THE OPAC |
| 15:16 |
pinesol |
csharp: Band 'THE OPAC' added to list |
| 15:16 |
JBoyer |
Ok, so at least optional for 3.6. |
| 15:16 |
nfBurton34 |
Yes |
| 15:16 |
csharp |
nfBurton34++ |
| 15:16 |
gmcharlt |
yeah, agreed - optional for 3.6, maybe default for 3.7 |
| 15:16 |
csharp |
+1 |
| 15:16 |
JBoyer |
In that case I'd say it's still worth pursuing jQ in the meantime since it does cause problems in the existing OPAC. |
| 15:16 |
gmcharlt |
I think question is when do we want to deprecate the old OPAC - I'm inclined to say 3.7 |
| 15:17 |
nfBurton34 |
Yeah I had to change the load order of the jQuery |
| 15:17 |
JBoyer |
gmcharlt, with the intent that it's then gone in ~3.8? |
| 15:17 |
gmcharlt |
(which I realize is begging the question of whether to deprecate at all, but I think we should, in part so that we avoid a long-term committment that I don't believe we can colellectively make) |
| 15:17 |
gmcharlt |
JBoyer: yeah, gone in 3.8 |
| 15:18 |
Bmagic |
+1 deprecation 3.7, gone 3.8 |
| 15:19 |
csharp |
gmcharlt++ # proper use of "begging the question" |
| 15:19 |
csharp |
I'm good with the plan |
| 15:19 |
jeffdavis |
Not necessarily opposed but that is an aggressive timeline for the main public-facing component of EG, esp considering many of us have probably done some degree of OPAC customization. |
| 15:20 |
JBoyer |
Sounds like a plan then. We don't need to firm up the schedule today, but we should definitely look into making jQ work as expected. |
| 15:20 |
nfBurton34 |
It does make navigation FAR easier |
| 15:20 |
Bmagic |
jeffdavis: I have the same thoughts, though, I think that the OPAC that nfBurton34 has worked out is mostly what the customizations are trying to get to.... |
| 15:20 |
terran |
Should deprecation wait for 4.x? (In PINES we will consider moving to it sooner though) |
| 15:21 |
_sandbergja |
I would be interested in a longer timeline |
| 15:21 |
_sandbergja |
We only upgrade once a year, so it would go from optional to gone in one upgrade cycle |
| 15:21 |
_sandbergja |
And I don't think we're the only ones who upgrade annually... |
| 15:21 |
csharp |
deprecation doesn't necessary mean removal - like the XUL client stuck around in a "deprecated" state over a few releases |
| 15:21 |
csharp |
we also upgrade annually |
| 15:22 |
jeffdavis |
I don't think we need to decide now, main thing is to get the new OPAC in the next release, right? |
| 15:22 |
csharp |
maybe just delay removal? |
| 15:22 |
JBoyer |
The timing plans can probably be hashed out once the new OPAC is even an option, my primary point was "do we still pursue replacing dojo with jQuery?" and it sounds like yes. |
| 15:23 |
miker |
JBoyer: +1 to s/dojo/jquery/ in the opac |
| 15:23 |
_sandbergja |
JBoyer: yes to dojo -> jquery |
| 15:23 |
jeffdavis |
+1 to that (Overdrive API stuff will need to be de-Dojofied but that was always expected) |
| 15:23 |
nfBurton34 |
jQuery > dojo |
| 15:23 |
JBoyer |
So, does anyone feel strongly about taking that action item or will I do it after this meeting (lest I forget) |
| 15:24 |
Dyrcona |
JBoyer: You can have it if you like. I couldn't get to it in 3 months, so.... |
| 15:25 |
JBoyer |
#action JBoyer to file LP bug about replacing Dojo with jQuery |
| 15:26 |
JBoyer |
The three months in question does make it a bit more understandable though. |
| 15:26 |
JBoyer |
Moving on! |
| 15:26 |
JBoyer |
#topic OpenSRF Release Info |
| 15:26 |
|
Topic for #evergreen is now OpenSRF Release Info (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-08-04) |
| 15:26 |
JBoyer |
Is there any OpenSRF release info to discuss? |
| 15:26 |
gmcharlt |
short term, we have two patches that are enough to warrant cutting 3.2.1 IMO |
| 15:27 |
miker |
ooo, I know what they are! :) |
| 15:27 |
gmcharlt |
well, three, one's an easy merge |
| 15:27 |
gmcharlt |
so I propose to take an action item to release 3.2.1 this month the same time as the Evergreen maint releases |
| 15:28 |
JBoyer |
gmcharlt++ |
| 15:28 |
gmcharlt |
#action gmcharlt will cut OpenSRF 3.2.1 |
| 15:28 |
JBoyer |
#action gmcharlt to build an OpenSRF 3.2.1 release during the same timeframe as the Evergreen maintenance releases |
| 15:28 |
JBoyer |
Oops, too wordy I suppose. |
| 15:29 |
|
JBoyer left #evergreen |
| 15:29 |
Bmagic |
words bad. " " good. |
| 15:29 |
|
JBoyer joined #evergreen |
| 15:29 |
gmcharlt |
come back, JBoyer! a double #action is not the end of the world! ;) |
| 15:29 |
JBoyer |
Sigh. I may need a new IRC client. :/ |
| 15:30 |
csharp |
gmcharlt++ |
| 15:30 |
JBoyer |
On to Evergreen! |
| 15:30 |
JBoyer |
#topic Evergreen Release Info |
| 15:30 |
|
Topic for #evergreen is now Evergreen Release Info (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-08-04) |
| 15:30 |
JBoyer |
Are we still on schedule for August 19th for the monthly point releases? |
| 15:31 |
gmcharlt |
in ##eg-release I had proposed instead doing them on August 12 to avoid running into Feedback Fest |
| 15:31 |
csharp |
I'm good with either |
| 15:31 |
gmcharlt |
and I'm happy to continue with that plan, but want to confirm that other build team members are available |
| 15:31 |
Bmagic |
I'm available for either date |
| 15:31 |
Dyrcona |
What calendar is Feedback Fest on? I don't see it in Google. |
| 15:32 |
JBoyer |
Dyrcona, currently it's been mentioned in a couple of emails and the dev meeting agenda. I need to see if I have / can get community calendar editing powers. |
| 15:33 |
terran |
I can add it to the calendar - the schedule is here for now: https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap |
| 15:33 |
JBoyer |
terran++ |
| 15:33 |
Dyrcona |
I could add it to the development calendar. I don't think I can edit the others. |
| 15:33 |
JBoyer |
I'm also +1 to moving it away from Feedback Fest |
| 15:33 |
gmcharlt |
I've added it to the community calendar - is it showing up for folks now? |
| 15:34 |
terran |
Now it's on there twice :) |
| 15:34 |
gmcharlt |
I'll remove the one I added :) |
| 15:34 |
Dyrcona |
I wonder if doing the releases after feedback fest is better than before? |
| 15:34 |
terran |
I'll add bug squashing week if it's not on there yet too |
| 15:34 |
gmcharlt |
terran++ |
| 15:34 |
JBoyer |
I'd feel that way more about bugsquashing week, given their difference in focus. |
| 15:35 |
gmcharlt |
Dyrcona: feedback fest is more focused on enhancements rather than bugfixes; i.e., I agree with JBoyer |
| 15:36 |
Dyrcona |
OK. Fine with me. I was just wondering. |
| 15:37 |
_sandbergja |
I'd prefer August 12th for point releases, so I can actually participate in feedback fest. :-) |
| 15:37 |
_sandbergja |
And I am available then |
| 15:37 |
JBoyer |
I don't think that's a voting matter, but are enough build team members available to shift it? |
| 15:37 |
csharp |
sounds like it |
| 15:38 |
gmcharlt |
agreed |
| 15:38 |
JBoyer |
Huzaah. |
| 15:38 |
JBoyer |
#info the next Evergreen Maintenance Release date is August 12th |
| 15:38 |
|
JBoyer left #evergreen |
| 15:38 |
|
JBoyer joined #evergreen |
| 15:39 |
JBoyer |
So, Any other Evergreen release news? |
| 15:40 |
JBoyer |
Well, since I can't check my scrollback these may as well go in the minutes |
| 15:40 |
|
mantis1 left #evergreen |
| 15:40 |
JBoyer |
#info Feedback Fest is August 17 - August 21 |
| 15:41 |
JBoyer |
#info Bug Squashing Week is September 21 - September 25 |
| 15:41 |
csharp |
also remember http://irc.evergreen-ils.org/evergreen/2020-08-04 |
| 15:41 |
gmcharlt |
only other update is that mmorgan and I (and the other members of the RM team) will be sending out a summary on Monday |
| 15:41 |
JBoyer |
csharp++ |
| 15:41 |
JBoyer |
gmcharlt++ mmorgan++ |
| 15:42 |
JBoyer |
#topic Hatch Release info |
| 15:42 |
|
Topic for #evergreen is now Hatch Release info (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-08-04) |
| 15:42 |
berick |
no recent Hatch changes |
| 15:43 |
JBoyer |
It'll be nice when OpenJDK has all of the necessary parts to make it a single file install, but until then I don't suppose a lot needs to change. |
| 15:43 |
JBoyer |
That said, Is 3.6 maybe a good time to pull the band-aid on Hatch Local Storage, or should that go on as is for a while longer? |
| 15:44 |
JBoyer |
(In general, not trying to make more work for berick. ;) ) |
| 15:44 |
berick |
yeah we should remove that option from the config UI in the webstaff -- the bandaid has in essence been pulled already |
| 15:44 |
terran |
+1 |
| 15:44 |
csharp |
+1000 |
| 15:44 |
mmorgan |
+1 |
| 15:44 |
terran |
We still have staff that we find out are using it |
| 15:45 |
mmorgan |
Endless cause of confusion there. |
| 15:45 |
csharp |
yeah, it's a pain to troubleshoot |
| 15:45 |
berick |
i'll open a LP |
| 15:45 |
JBoyer |
berick++ |
| 15:45 |
csharp |
berick++ |
| 15:45 |
JBoyer |
#action berick to open LP bug re: the removal of Hatch Local Storage in web staff client |
| 15:46 |
JBoyer |
Onward! |
| 15:46 |
JBoyer |
#topic New Business |
| 15:46 |
|
Topic for #evergreen is now New Business (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-08-04) |
| 15:46 |
csharp |
I have something tangentially dev-related |
| 15:47 |
JBoyer |
csharp, go for it |
| 15:47 |
csharp |
GPLS is decommissioning our email list server, and we have five Evergreen-related lists that need to be migrated to the Evergreen community list server (open-ils-general, open-ils-dev, open-ils-docs & the commits lists) |
| 15:48 |
csharp |
so look for communications from me about when that will happen over the next couple of weeks |
| 15:48 |
gmcharlt |
csharp++ |
| 15:48 |
_sandbergja |
csharp++ |
| 15:48 |
JBoyer |
csharp++ |
| 15:48 |
rhamby |
csharp++ |
| 15:49 |
csharp |
we've been talking about that for nearly 10 years, so good to finally see it happen :-) |
| 15:50 |
JBoyer |
The new business entry on the agenda was mine; I wanted to remind people about LP 1703411 . Some good code that we needed came from it, but not SASL authentication, which we still need. |
| 15:50 |
pinesol |
Launchpad bug 1703411 in OpenSRF "OpenSRF: XMPP Non-SASL auth is being phased out" [Medium,Confirmed] https://launchpad.net/bugs/1703411 |
| 15:51 |
JBoyer |
I have the most bare-bones bit of the perl half of this working, so perl services can login via the PLAIN mechanism, but I may need some help with the C portions, and we should really aim for SCRAM support so we can remove "Turn off all of the security features" from our install instructions. |
| 15:52 |
JBoyer |
I don't have a working branch out there yet (just banging on it on a local VM) but does this sound like the sort of thing anyone is interested in poking at? |
| 15:52 |
gmcharlt |
I would be |
| 15:53 |
JBoyer |
gmcharlt++ |
| 15:53 |
JBoyer |
Obviously I'll have to get what I have to date in a collab wip branch, which I'll try to do asap. |
| 15:53 |
berick |
i'm definitely following along. |
| 15:53 |
JBoyer |
berick++ |
| 15:53 |
miker |
me too |
| 15:54 |
Bmagic |
seems like it's time |
| 15:54 |
JBoyer |
I'll try to remember to mention it in here once it's up, and FYI, at present it's really not commit-worthy. ;) |
| 15:55 |
JBoyer |
So, we move on to |
| 15:55 |
JBoyer |
#topic Feedback for new features |
| 15:55 |
|
Topic for #evergreen is now Feedback for new features (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-08-04) |
| 15:55 |
JBoyer |
berick, you've got the first one. |
| 15:55 |
berick |
hi.. |
| 15:55 |
berick |
heads up we have a new tag angularcatblocker |
| 15:55 |
berick |
any angular staff cat issues that prevent its use in production should get this tag |
| 15:56 |
berick |
or new regressions, etc. |
| 15:56 |
berick |
i'm tracking them closely |
| 15:56 |
berick |
also just curious if anyone has any strong feeling either way for making it the defult in 3.6 as it's one of the earlier-is-better things |
| 15:57 |
berick |
if we want to merge it |
| 15:57 |
Bmagic |
I like the launchpad tag. +1 3.6 |
| 15:57 |
gmcharlt |
I'm inclined to merge it sooner rather than later, in particular, before feedback fest |
| 15:58 |
berick |
i saw the comment re: removing the org setting, gmcharlt |
| 15:58 |
berick |
i'll look at that |
| 15:58 |
gmcharlt |
and specifically before feedback fest so that /all/ test systems set up for FF are implicitly testing it as well |
| 15:59 |
JBoyer |
That does make sense, should help with the slightly shorter release cycle also. |
| 15:59 |
_sandbergja |
+1 merging it soon for 3.6 |
| 16:00 |
JBoyer |
berick, do you want an action item for that or would you like someone else to give it another look first? |
| 16:00 |
_sandbergja |
As a side note, it will be really nice to have those broadcast messages in the Angular client |
| 16:01 |
berick |
JBoyer: i have one thing to fix (removing org setting), but other than that I thing someone else would need to volunteer for testing the branch |
| 16:01 |
_sandbergja |
I can volunteer |
| 16:01 |
berick |
thanks _sandbergja++ |
| 16:01 |
JBoyer |
_sandbergja++ |
| 16:02 |
JBoyer |
#action _sandbergja to do some testing on the Angular staff catalog branch with the aim of merging pre-feedback fest |
| 16:03 |
JBoyer |
And I suppose berick's second point on the agenda is fairly closely related, given the timing? |
| 16:03 |
berick |
right, Ang 9 (or 10) bug 1864371 |
| 16:03 |
pinesol |
Launchpad bug 1864371 in Evergreen "Upgrade to Angular 9" [Undecided,Confirmed] https://launchpad.net/bugs/1864371 |
| 16:03 |
gmcharlt |
yeah |
| 16:03 |
JBoyer |
#topic Angular 9 /10 update |
| 16:03 |
|
Topic for #evergreen is now Angular 9 /10 update (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-08-04) |
| 16:03 |
gmcharlt |
I've looked over the branch and am in favor of going all the way to Angular 10, and doing so ASAP |
| 16:04 |
JBoyer |
I just realized these minutes are going to be a bit sparse on what it is we;re actually talking about. |
| 16:04 |
Dyrcona |
The minutes usually are sparse, but there's a link for the full log. |
| 16:04 |
gmcharlt |
in part, selfishly, because I'd prefer to rebase the angular acq search branch at a predictable time to convert it from using ngbTabset to ngbNav |
| 16:05 |
berick |
gmcharlt: *nod* |
| 16:05 |
berick |
well, I can rebase the working branch and give it another once over this week |
| 16:05 |
gmcharlt |
and I'd happily take on putting the 1864371 branch through its paces |
| 16:05 |
berick |
even better! :) |
| 16:05 |
_sandbergja |
berick: gmcharlt: from glancing over that branch, it looks like it's not as impactful as Angular 8 adding static to all those ViewChilds |
| 16:05 |
berick |
_sandbergja: definitely not |
| 16:05 |
_sandbergja |
Yes! |
| 16:06 |
gmcharlt |
I also glanced over the ng-bootstrap and bootstrap release notes, and bumping up up to 7.0.0 and 4.5.1 respectively doesn't look like it will be too painful |
| 16:06 |
berick |
and the tab/nav changes are encouraged but not strictly required yet |
| 16:06 |
berick |
hold my last thought, i haven't tested latest bootstrap |
| 16:06 |
berick |
pretty sure it's still just deprecated, though |
| 16:06 |
_sandbergja |
I can take a look after you, gmcharlt |
| 16:06 |
gmcharlt |
_sandbergja++ |
| 16:07 |
berick |
gmcharlt++ _sandbergja++ |
| 16:07 |
JBoyer |
gmcharlt++ _sandbergja++ berick++ |
| 16:07 |
_sandbergja |
it would be nice to be able to rebase the course materials work on Angular 10 too |
| 16:07 |
_sandbergja |
:-) |
| 16:07 |
JBoyer |
Would the aim for that also be pre-FF week? |
| 16:07 |
_sandbergja |
That would be ideal, I think |
| 16:07 |
berick |
+1 to pre-FF |
| 16:08 |
_sandbergja |
So, when reviewing old PRs, we can easily check Angular 10 compatibility |
| 16:08 |
gmcharlt |
yeah |
| 16:09 |
JBoyer |
#action gmcharlt , _sandbergja , and berick will work to test and merge lp 1864371 to use Angular 10 in the staff client before Feedback Fest week. |
| 16:09 |
pinesol |
Launchpad bug 1864371 in Evergreen "Upgrade to Angular 9" [Undecided,Confirmed] https://launchpad.net/bugs/1864371 |
| 16:09 |
JBoyer |
That sounds great. |
| 16:09 |
JBoyer |
Given it's standing as a, uh, standing item, we can skip over discussionneeded for now. |
| 16:10 |
JBoyer |
#topic Curbside pickup discussion |
| 16:10 |
|
Topic for #evergreen is now Curbside pickup discussion (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-08-04) |
| 16:10 |
gmcharlt |
so, this one is mostly just a plea for reviewer and committer attention, especially now that we have some libraries using it in production |
| 16:11 |
gmcharlt |
not much to say otherwise unless there are questions |
| 16:11 |
JBoyer |
lp 1879983 for those reading the logs later |
| 16:11 |
pinesol |
Launchpad bug 1879983 in Evergreen "Curbside Pickup" [Wishlist,Confirmed] https://launchpad.net/bugs/1879983 |
| 16:12 |
mmorgan |
Is the test server with that code still available? |
| 16:13 |
gmcharlt |
mmorgan: as it happens, yeah, curbside.evergreencatalog.com is still up |
| 16:13 |
jeffdavis |
we're testing curbside here, will share any feedback via LP |
| 16:13 |
gmcharlt |
only thing it would need is refreshing it to the latest-and-greatest |
| 16:13 |
gmcharlt |
jeffdavis++ |
| 16:14 |
JBoyer |
Any other questions or curbside discussion? |
| 16:14 |
* mmorgan |
will try and devote some time to looking at curbside. |
| 16:15 |
gmcharlt |
mmorgan++ |
| 16:15 |
JBoyer |
mmorgan++ |
| 16:15 |
JBoyer |
#topic Angular Acquisitions Search (LP 1850547 ) |
| 16:15 |
|
Topic for #evergreen is now Angular Acquisitions Search (LP 1850547 ) (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-08-04) |
| 16:15 |
pinesol |
Launchpad bug 1850547 in Evergreen "Angular Acquisitions Sprint 3: Acquisitions Search" [Wishlist,Confirmed] https://launchpad.net/bugs/1850547 |
| 16:15 |
JBoyer |
I assume this is a similar request for eyes. |
| 16:16 |
gmcharlt |
so, same deal as the curbside branch, but with a specific request that some of the angular core component changes be looked at (and could be merged independently) |
| 16:16 |
berick |
i plan to review, but I'll wait until after Ang 10 rebase |
| 16:16 |
gmcharlt |
there are a bunch of them, including new eg-file-reader and eg-interval-input components and changes to org-select, date-select, eg-grid, and eg-combobox |
| 16:16 |
gmcharlt |
and even just eyeballing would be useful |
| 16:17 |
gmcharlt |
I will plan on rebasing that branch ASAP once the angular 10 branch is in |
| 16:17 |
* berick |
nods |
| 16:18 |
gmcharlt |
but otherwise, I've nothing else specific to sa |
| 16:18 |
gmcharlt |
y |
| 16:19 |
JBoyer |
I'll also try to poke around at those two. |
| 16:19 |
JBoyer |
#topic Patron API (LP 1887196) |
| 16:19 |
|
Topic for #evergreen is now Patron API (LP 1887196) (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-08-04) |
| 16:19 |
pinesol |
Launchpad bug 1887196 in Evergreen "Support PatronAPI-compatible auth via RemoteAuth" [Wishlist,New] https://launchpad.net/bugs/1887196 |
| 16:19 |
JBoyer |
jeffdavis, take it away |
| 16:20 |
jeffdavis |
I'm hoping to add support for PatronAPI, which is a patron authentication method used by III that a lot of vendors support. |
| 16:20 |
jeffdavis |
But I know some countries have strange/confusing laws around copyrightability of APIs so I'm not sure if there are issues adding a PatronAPI-compatible API to EG? |
| 16:21 |
gmcharlt |
IIRC, there's at least one shim running around that adds PatronAPI support to Evergreen, that TMK nobody's challenged |
| 16:21 |
|
stompro_ joined #evergreen |
| 16:22 |
JBoyer |
I don't recall if the Google / Oracle fight is over, but given that we've so little money to take I'd assume that's not an issue. |
| 16:22 |
JBoyer |
Unless Oracle buys III, in which case all bets are off. ;) |
| 16:24 |
jeffdavis |
It seems like a bit of a grey area and it would be adding the API to EG itself (rather than an external shim), so I just wanted to flag it before anything gets committed. If we don't think there's an issue then that's good with me. |
| 16:24 |
JBoyer |
Of note to potential testers, it requires LP 1850992 also, which would also be a great addition. |
| 16:24 |
pinesol |
Launchpad bug 1850992 in Evergreen "Use RemoteAuth for EZProxy authentication" [Wishlist,New] https://launchpad.net/bugs/1850992 - Assigned to Jane Sandberg (sandbej) |
| 16:25 |
|
Stompro joined #evergreen |
| 16:26 |
JBoyer |
Any more discussion for jeffdavis about PatronAPI? I've let things run a bit longer than expected today. |
| 16:26 |
gmcharlt |
there is also this: http://bricestacey.com/2009/06/03/Configure-EZProxy-to-Authenticate-Against-Voyager-ILS-for-WorldCat-Local-Navigator.html |
| 16:27 |
gmcharlt |
so, not adding PatronAPI support to Voyager, but code that provides its as an endpoint |
| 16:28 |
|
Stompro joined #evergreen |
| 16:29 |
gmcharlt |
but I've nothing more to say |
| 16:29 |
jeffdavis |
that's a handy link, thanks |
| 16:29 |
JBoyer |
That's the first I've seen of the output of PatronAPI, I'm a little bummed that's becoming a defacto standard. |
| 16:30 |
JBoyer |
Everyone is encouraged to check out LP bugs that have have pullrequests but need signoffs, and I don't believe we have any qa failing bugs at present. |
| 16:30 |
JBoyer |
Have a great day eveyone. |
| 16:30 |
JBoyer |
#endmeeting |
| 16:30 |
|
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:30 |
pinesol |
Meeting ended Tue Aug 4 16:30:55 2020 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 16:30 |
pinesol |
Minutes: http://evergreen-ils.org/meetings/evergreen/2020/evergreen.2020-08-04-15.01.html |
| 16:30 |
pinesol |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2020/evergreen.2020-08-04-15.01.txt |
| 16:30 |
pinesol |
Log: http://evergreen-ils.org/meetings/evergreen/2020/evergreen.2020-08-04-15.01.log.html |
| 16:31 |
gmcharlt |
JBoyer++ |
| 16:31 |
jeffdavis |
JBoyer++ |
| 16:31 |
berick |
JBoyer++ |
| 16:31 |
mmorgan |
JBoyer++ |
| 16:31 |
terran |
JBoyer++ |
| 16:32 |
phasefx_ |
JBoyer++ |
| 16:32 |
Dyrcona |
JBoyer++ |
| 16:32 |
JBoyer |
Hopefully if I don't leave the channel every randomly next meeting it won't take 90 minutes... |
| 16:32 |
Bmagic |
JBoyer++ |
| 16:33 |
Dyrcona |
Well, it has been 3 months since the previous meeting, so 30 minutes/month ain't that bad. |
| 16:33 |
JBoyer |
I can deal with ain't that bad. |
| 16:35 |
csharp |
JBoyer++ |
| 16:39 |
Bmagic |
reminds me of this https://www.youtube.com/watch?v=VakU20APPdw |
| 16:40 |
JBoyer |
Bmagic++ |
| 16:40 |
Bmagic |
"That ain't bad" always brings Jack Nicholson to mind. |
| 16:44 |
Dyrcona |
"Ain't That Pretty At All" |
| 17:36 |
|
mmorgan left #evergreen |
| 17:38 |
|
sandbergja_ joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:11 |
|
dbwells_ joined #evergreen |
| 18:20 |
|
sandbergja_ joined #evergreen |
| 18:57 |
|
RBecker joined #evergreen |
| 18:57 |
|
csharp joined #evergreen |
| 19:29 |
|
sandbergja_ joined #evergreen |
| 20:15 |
|
Stompro joined #evergreen |
| 23:24 |
|
sandbergja_ joined #evergreen |
