| Time |
Nick |
Message |
| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:09 |
|
agoben joined #evergreen |
| 07:37 |
|
dwgreen joined #evergreen |
| 07:54 |
|
kmlussier joined #evergreen |
| 08:05 |
|
collum joined #evergreen |
| 08:29 |
|
rlefaive joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:44 |
|
Dyrcona joined #evergreen |
| 08:57 |
Dyrcona |
Great. Custom 2.12.8 to 3.0.2 db upgrade failed. |
| 08:58 |
|
bos20k joined #evergreen |
| 08:59 |
Dyrcona |
heh. Blows up on this: UPDATE biblio.record_entry SET vis_attr_vector = biblio.calculate_bib_visibility_attribute_set(id); |
| 09:01 |
Dyrcona |
m</subfield></datafield><datafield tag="500" ind1=" " ind2=" "><subfield code="" |
| 09:01 |
Dyrcona |
:1: parser error : Couldn't find end of Start Tag subfield line 1 |
| 09:01 |
Dyrcona |
Also, looks like we have some bad records, but that one is likely deleted, though no record number is reported. |
| 09:02 |
csharp |
@marc 500 |
| 09:02 |
pinesol_green |
csharp: General information for which a specialized 5XX note field has not been defined. (Repeatable) [a,3,5,6,8] |
| 09:03 |
Dyrcona |
There are other parse errors after that one, likely the same record. |
| 09:04 |
Dyrcona |
Think I'll ditch this script and modify the 2.12.6 to 3.0.0 script to remove upgrades that we already have. |
| 09:04 |
Dyrcona |
I'll have to do this for production eventually.... |
| 09:06 |
Dyrcona |
The 2.12.6 to 3.0.0 upgrade succeeded on an earlier copy of our data, btw. So, I'm sure that issue is local to me and my custom db upgrade script. |
| 09:06 |
Dyrcona |
BTW, I think the modifications that I mentioned yesterday really should be backported to the numbered upgrade scripts. |
| 09:07 |
Dyrcona |
Am I the only one who uses makerelease (or pieces of it) to make custom db upgrade scripts? |
| 09:10 |
csharp |
I just start with the tarball versions and customize those as needed |
| 09:11 |
JBoyer |
Dyrcona, You will 100% want to not run that on deleted bibs or items. (I have a later upgrade script that cleans that up. Better to not make a mess in the first place.) |
| 09:13 |
JBoyer |
(should probably have modified the numbered upgrade scripts, but I thought that was much frowned upon.) |
| 09:15 |
Dyrcona |
JBoyer: Numbered upgrade scripts have been modified in the past. I've done it for one, and I know others have from time to time. |
| 09:15 |
csharp |
isn't the process to create a new numbered script that supercedes the old one? |
| 09:16 |
Dyrcona |
csharp: Sometimes. I think it depends on how soon the issue is caught. |
| 09:16 |
Dyrcona |
I know I did one that modified the original because the problem was caught within a few days of the script going into git. |
| 09:17 |
Dyrcona |
I don't remember which one, of course, but I remember doing it in the past 2 years or so. |
| 09:17 |
JBoyer |
Well, this issue began in 3.0.0 and was caught at the hackaway. about a month out makes me nervous. |
| 09:17 |
Dyrcona |
Anyway, I'm going to just modify the 2.12.6 to 3.0.0 this time. I usually use make_release and then modify that. |
| 09:18 |
Dyrcona |
JBoyer: Understood, but anyone running the numbered upgrades is going to have a bad time of it. |
| 09:18 |
Dyrcona |
Of course, I may have been the only one doing that, but assumptions.... :) |
| 09:18 |
csharp |
heh - you know my stance on that :-) |
| 09:18 |
JBoyer |
THAT SAID, changing a couple of the upgrade scripts (I'm assuming you're near 1057?) to include WHERE NOT deleted should get you going again. |
| 09:19 |
JBoyer |
We use them here since we upgrade to the latest rel_3_0 whenever a fix of interest appears. |
| 09:21 |
|
yboston joined #evergreen |
| 09:21 |
csharp |
yeah, I guess we do one offs here and there too |
| 09:22 |
Dyrcona |
Ok. Time to run the "magic" to determine what upgrades are needed from 2.12.8 to 3.0.0.... :) |
| 09:23 |
Dyrcona |
We could bring it up at the developers' meeting this afternoon. It might clear things up if we have a consensus on modifying or not modifying numbered upgrades. |
| 09:23 |
csharp |
maybe time to look at sqitch again?: http://sqitch.org/ (from berick's suggestion at 2015 Hack-A-Way)? |
| 09:23 |
csharp |
but that's prolly a rabbit hole |
| 09:25 |
Dyrcona |
Well, I don't know if sqitch would help. There are big differences between the version upgrade script and the relevant numbered upgrades. |
| 09:27 |
Dyrcona |
Hmm.... This'll be interesting.... How to figure which upgrade blocks to delete... I basically want to remove the upgrades that are in both lists. |
| 09:27 |
Dyrcona |
Does diff have a switch for that? |
| 09:27 |
csharp |
-u? |
| 09:28 |
csharp |
no, that's "unified", sorry |
| 09:29 |
Dyrcona |
:) |
| 09:29 |
Dyrcona |
There's an option to not output identical lines. |
| 09:30 |
Dyrcona |
Hm... I could diff both ways, then patch both files, and they should be identical and that would be the list of upgrades to remove.... |
| 09:32 |
Dyrcona |
No. That won't work..... |
| 09:33 |
Dyrcona |
Ha. Maybe if diff the diffs! |
| 09:35 |
Dyrcona |
Ah, I want comm |
| 09:36 |
Dyrcona |
comm -1 -2 new_upgrades.txt old_upgrades.txt |
| 09:38 |
Dyrcona |
Ah. I should add the 3.0.1 and 3.0.2 upgrade scripts as well. |
| 09:38 |
Dyrcona |
Because 2.12.8 includes upgrades from those. |
| 09:39 |
Dyrcona |
This is "fun." :) |
| 09:48 |
Dyrcona |
Why have I not heard of comm before? "A comm command appeared in Version 4 AT&T UNIX." |
| 09:53 |
csharp |
I know about comm, but I don't need it enough to always remember it until I've exhausted diff, sort, uniq etc. |
| 09:53 |
|
mllewellyn joined #evergreen |
| 09:54 |
Dyrcona |
Hm... That didn't seem to give me quite what I wanted. |
| 09:55 |
Dyrcona |
It produced a list of what are supposed to be the common upgrades, but I'm not finding the numbers in the upgrade script. |
| 09:55 |
Dyrcona |
I musta done something wrong... |
| 09:58 |
Dyrcona |
Oh. I see... These were applied before 2.12.6. :) |
| 09:58 |
Dyrcona |
I misunderstood my data. :) |
| 10:01 |
|
mmorgan1 joined #evergreen |
| 10:28 |
rjackson_isl |
kmlussier please see related comment on bug 1737985 |
| 10:28 |
pinesol_green |
Launchpad bug 1737985 in Evergreen "Volume Copy Editor Truncates Displayed Data " [Undecided,New] https://launchpad.net/bugs/1737985 |
| 10:30 |
kmlussier |
rjackson_isl: Yeah, it might be worthwhile to do some mockups to see if we can do something there. The problem is that you don't want to push the data-entry fields too far down. |
| 10:31 |
kmlussier |
I wonder if it would be worthwhile to use two columns for the copy editor instead of the three. There are just two fields living in that right-most column. |
| 10:33 |
rjackson_isl |
in the example scren shot if I look at that in the actual web client I need to scroll to see the existing data as it is. Having a unique 'section" for the identifying data if it is just one row wshouldn't add too much extra scrolling? |
| 10:34 |
rjackson_isl |
oh yeah - so much for spell checking... |
| 11:31 |
|
khuckins joined #evergreen |
| 11:58 |
|
rlefaive joined #evergreen |
| 12:09 |
csharp |
fcd4229f |
| 12:09 |
pinesol_green |
csharp: [evergreen|Galen Charlton] LP#1701001: carve out a reusable patron search service - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fcd4229> |
| 12:12 |
|
rlefaive joined #evergreen |
| 12:17 |
mmorgan |
Launchpad is cranky today :-( |
| 12:20 |
|
rlefaive joined #evergreen |
| 12:21 |
kmlussier |
mmorgan: Timing out? |
| 12:23 |
mmorgan |
Yes, it timed out a while ago, but then I got a "something went wrong" error. It's cooperating ATM. |
| 12:27 |
|
rlefaive joined #evergreen |
| 12:27 |
|
rjackson_isl_ joined #evergreen |
| 12:28 |
|
Christineb joined #evergreen |
| 12:43 |
berick |
Bmagic++ |
| 12:44 |
Bmagic |
berick++ |
| 12:44 |
berick |
oh I can do this all day |
| 12:44 |
Bmagic |
lol |
| 12:46 |
Dyrcona |
`:) |
| 12:50 |
kmlussier |
Bmagic++ berick++ |
| 12:50 |
kmlussier |
karma party! |
| 12:50 |
Bmagic |
berick++ |
| 12:51 |
Bmagic |
in-your-face |
| 12:51 |
Bmagic |
and |
| 12:51 |
Bmagic |
Dyrcona++ # cause you smiled |
| 12:53 |
kmlussier |
Also... |
| 12:53 |
kmlussier |
mmorgan++ JBoyer++ rjackson_isl++ csharp++ #For participating in IRC today. |
| 12:53 |
* kmlussier |
can get on board with participation trophies. |
| 12:53 |
jeffdavis |
kmlussier++ # you left yourself out! |
| 12:54 |
mmorgan |
jeffdavis beat me to it! |
| 12:54 |
kmlussier |
jeffdavis++ # for participating in the karma party |
| 12:54 |
kmlussier |
OK, /me has real work to do now. |
| 13:00 |
|
mllewellyn1 joined #evergreen |
| 13:02 |
|
rjackson_isl__ joined #evergreen |
| 13:02 |
|
rlefaive joined #evergreen |
| 13:07 |
kmlussier |
Dyrcona: I'm editing the dev agenda now. Do you want me to add something about the upgrade scripts there? |
| 13:11 |
kmlussier |
Never mind. I added it. |
| 13:20 |
|
mmorgan1 joined #evergreen |
| 13:25 |
kmlussier |
gmcharlt: Would you consider bug 1730752 to be eligible for backport to 3.0? |
| 13:25 |
pinesol_green |
Launchpad bug 1730752 in Evergreen "Webstaff option to show/hide multiple grid columns" [Undecided,New] https://launchpad.net/bugs/1730752 |
| 13:42 |
Dyrcona |
Is there a way to get the title of a bib record out of the database in title case without doing oils_xslt_process and oils_xpath_string? |
| 13:42 |
Dyrcona |
If I join with reporter.materialized_simple_record the title is normalized to lower case. |
| 13:43 |
Dyrcona |
And, if I try the oils_xslt_process and oils_xpatch_string method on all of the records in one query, I crash my test db server. :) |
| 13:45 |
csharp |
Dyrcona: depending on the need, you can also use initcap() which will capitalize the first letter in every word (not perfect and not preserving the original case, but maybe better?) |
| 13:45 |
Dyrcona |
Well, it's a dump for Novelist On-the-Shelf. |
| 13:46 |
csharp |
ah' |
| 13:46 |
JBoyer |
Dyrcona, well, once that upgrade is run the display fields should get you exactly what you're after. |
| 13:46 |
JBoyer |
But until then, not so much. |
| 13:46 |
Dyrcona |
JBoyer: I need the data from a pre-upgrade db. :) |
| 13:47 |
Dyrcona |
I can do it with an open-ils call, though I forget exactly which one. :) |
| 13:47 |
JBoyer |
I didn't think OTS was case sensitive? (I also thought it only really paid any attention to the ISBNs, though I may mis mistaken.) |
| 13:47 |
Dyrcona |
And, I just hosed that db that was running the upgrade. |
| 13:48 |
Dyrcona |
Regular Novelist only needs ISBNs. OTS uses the additional information, but I don't know exactly what they do with the tile. |
| 13:48 |
Dyrcona |
title. |
| 13:48 |
Dyrcona |
I'll send 'em all lower case and wait until they complain. :) |
| 13:50 |
JBoyer |
I think we've only ever sent the lowercase and our display looks fine. |
| 13:53 |
Dyrcona |
OK. |
| 13:53 |
Dyrcona |
Here's hoping that my rsync really picks up where it left off.... :) |
| 13:55 |
miker |
Dyrcona: are you on 3.0 yet? if so, metabib.display_entry |
| 13:55 |
Dyrcona |
You missed that bit. I'm not. |
| 13:55 |
miker |
I did, indeed. alas |
| 13:55 |
Dyrcona |
Guess it really wasn't that clear, either. |
| 13:56 |
Dyrcona |
anyway, at least it wasn't an important db server. :) |
| 13:57 |
Dyrcona |
Rebooting gives me a chance to update the kernel and other packages, too. :) |
| 13:57 |
JBoyer |
Woo! new updates, new potential problems. |
| 14:00 |
Dyrcona |
Pfft.... |
| 14:01 |
Dyrcona |
It's just updated packages on the LTS, not like I'm upgrading to a newer release. |
| 14:28 |
|
rlefaive joined #evergreen |
| 14:41 |
Dyrcona |
On the plus side, I think I've found a more efficient way to retrieve the data. |
| 14:41 |
Dyrcona |
Time will tell. |
| 14:45 |
|
stephengwills joined #evergreen |
| 14:46 |
gmcharlt |
development meeting in 15 minutes |
| 14:57 |
|
bos20k joined #evergreen |
| 14:58 |
|
mllewellyn joined #evergreen |
| 15:02 |
gmcharlt |
and ... showtime |
| 15:02 |
gmcharlt |
#startmeeting Development meeting, 13 December 2017 |
| 15:02 |
pinesol_green |
Meeting started Wed Dec 13 15:02:11 2017 US/Eastern. The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:02 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 15:02 |
pinesol_green |
The meeting name has been set to 'development_meeting__13_december_2017' |
| 15:02 |
gmcharlt |
#info Agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2017-12-13 |
| 15:02 |
gmcharlt |
#topic Introductions |
| 15:02 |
Dyrcona |
#info Dyrcona is Jason Stephenson, C/W MARS |
| 15:02 |
gmcharlt |
#info gmcharlt = Galen Charlton, Equinox |
| 15:02 |
remingtron |
#info remingtron = Remington Steed, Hekman Library (Calvin College) |
| 15:03 |
berick |
#info berick Bill Erickson, KCLS |
| 15:03 |
dbwells |
#info dbwells = Dan Wells, Hekman Library (Calvin College) |
| 15:03 |
jeffdavis |
#info jeffdavis = Jeff Davis, BC Libraries Coop (Sitka) |
| 15:03 |
miker |
#info miker = Mike Rylander, EOLI |
| 15:03 |
abneiman |
#info abneiman = Andrea Neiman, Equinox |
| 15:03 |
JBoyer |
#info JBoyer Jason Boyer, IN State Library |
| 15:04 |
rhamby |
#info Rogan Hamby, Equinox |
| 15:04 |
Bmagic |
#info Bmagic, MOBIUS |
| 15:05 |
gmcharlt |
#topic Action items from past peeting |
| 15:05 |
gmcharlt |
er |
| 15:05 |
gmcharlt |
#topic Action items from past meeting |
| 15:05 |
gmcharlt |
I guess we're all drinking Peets coffee now |
| 15:05 |
gmcharlt |
anyway |
| 15:05 |
gmcharlt |
one is just a carry-over |
| 15:05 |
gmcharlt |
#action gmcharlt will open and work on bugs for documentation changes for better ejabberd configuration during installation of OpenSRF |
| 15:06 |
gmcharlt |
no progress to report yet |
| 15:06 |
gmcharlt |
while the other does have progress |
| 15:06 |
gmcharlt |
namely |
| 15:06 |
gmcharlt |
#info Hatch extension is now available in the Chrome store |
| 15:06 |
gmcharlt |
berick++ |
| 15:06 |
dbwells |
berick++ |
| 15:06 |
JBoyer |
berick++ |
| 15:06 |
* berick |
had help |
| 15:06 |
berick |
yall++ |
| 15:07 |
JBoyer |
mjingle++ |
| 15:07 |
gmcharlt |
berick: JBoyer: any other updates on Hatch other than mention of bug 1733692 and bug 1708757 ? |
| 15:07 |
pinesol_green |
Launchpad bug 1733692 in Evergreen "Hatch Windows installer doesn't follow best practices" [High,New] https://launchpad.net/bugs/1733692 |
| 15:07 |
pinesol_green |
Launchpad bug 1708757 in Evergreen "Publish Hatch to Chrome web store" [Wishlist,New] https://launchpad.net/bugs/1708757 - Assigned to Galen Charlton (gmc) |
| 15:07 |
stephengwills |
#info stephengwills with Maine Balsam Libraries |
| 15:07 |
berick |
gmcharlt: just a note at the bottom of the agenda re: web site |
| 15:07 |
JBoyer |
I'm hoping to at least have some leads on FF support, but nothing is so close that it should be waited on. :/ |
| 15:07 |
gmcharlt |
ok |
| 15:07 |
JBoyer |
I suspect it can't be done on the work PC. |
| 15:08 |
gmcharlt |
then I'll wait until we get to that point in the agenda |
| 15:08 |
gmcharlt |
so, moving on |
| 15:08 |
gmcharlt |
#topic OpenSRF updates |
| 15:09 |
gmcharlt |
so, since I'll have a fair amount of quiet time with me, the cats, and the dust bunnies over the holidays, I'm going to work on dealing with the last of chunking and bundling breakages |
| 15:09 |
gmcharlt |
so ... |
| 15:10 |
gmcharlt |
#action gmcharlt will work on patches destined for a release of OpenSRF 3.0.1 in January |
| 15:10 |
gmcharlt |
and I'm looking for any other patches and bug nominations that folks care to offer |
| 15:11 |
gmcharlt |
#topic Evergreen update |
| 15:11 |
gmcharlt |
dbwells? |
| 15:12 |
dbwells |
Not a whole lot to report at this point, but a few things. |
| 15:12 |
dbwells |
I am in the process of breaking down the codebase into simple chunks to create a signup spreadsheet for any wishing to contribute to internal documentation. |
| 15:12 |
dbwells |
I expect that to be out by the new year at the latest. |
| 15:13 |
dbwells |
As a side note, we are also upgrading to 3.0 next week locally, so I am hoping that will give me a better view from the top, so to speak. |
| 15:13 |
dbwells |
Thank you to folks who have been updating the roadmap. |
| 15:13 |
* csharp |
rushes into the meeting, panting |
| 15:14 |
dbwells |
Here it is again, please do take a look and add anything you are planning at this point: https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:3.1 |
| 15:14 |
csharp |
#info csharp = Chris Sharp, GPLS |
| 15:15 |
dbwells |
Next schedule date ATM is Feb 9: feature slush, but as I said, I am expecting to organize some of the documentation push in the interim. |
| 15:15 |
dbwells |
That is all for now. |
| 15:15 |
dbwells |
Any questions? |
| 15:16 |
dbwells |
I did not get any feedback on the timeline posted last month, so I am assuming it is fine. Pretty standard at this point, I think. |
| 15:16 |
gmcharlt |
what... is your favorite color? |
| 15:16 |
gmcharlt |
seriously, +1 to the timeline |
| 15:16 |
dbwells |
Blue, I mean... aaaaahhhh! |
| 15:16 |
Dyrcona |
:) |
| 15:17 |
gmcharlt |
so, hearing no questions for dbwells... |
| 15:17 |
gmcharlt |
#topic Hatch update |
| 15:17 |
gmcharlt |
and I'll just move the downloads page discussion here |
| 15:17 |
gmcharlt |
so berick... what do you have in mind? |
| 15:17 |
berick |
for starters, just somewhere we can point people for fetching the windows installer |
| 15:18 |
berick |
was not sure how best to go about that |
| 15:18 |
gmcharlt |
beyond the links from https://evergreen-ils.org/egdownloads/? |
| 15:18 |
berick |
*headdesk* i've never scrolled down that far |
| 15:18 |
csharp |
heh |
| 15:18 |
JBoyer |
XD |
| 15:18 |
|
rlefaive joined #evergreen |
| 15:18 |
gmcharlt |
well, that does suggest a UX issue, or at least a datapoint |
| 15:19 |
JBoyer |
while on the subject though, I would recommend we not tie them to Eg versions yet (as is implied by the way they're laid out now) |
| 15:19 |
gmcharlt |
I know there was talk a while back of redesigning the downloads page... anybody have a desire to scratch that itch? |
| 15:19 |
Dyrcona |
Hatch is meant to be independent of EG version? |
| 15:19 |
JBoyer |
Nor should old versions be kept around (as of yet, if the API changes, we can revisit.) |
| 15:19 |
berick |
ok, so it's just like an EG update. put the files on the server and make a request of the web team. |
| 15:20 |
dbwells |
I think it makes good sense to put it near the Windows client download link, at least. |
| 15:20 |
csharp |
dbwells: +1 |
| 15:20 |
berick |
JBoyer: i was also expecting they'd be versioned separately. once it stabilizes, it should not need to be updated w/ the same frequency as EG -- that's the hope anyway |
| 15:21 |
remingtron |
dbwells: +1 |
| 15:22 |
berick |
gmcharlt: i think that gives me enough for now |
| 15:22 |
gmcharlt |
dbwells: do you want to take on that small tweak? |
| 15:22 |
berick |
and thanks |
| 15:22 |
dbwells |
gmcharlt: sure |
| 15:23 |
gmcharlt |
#action dbwells will tweak the Evergreen downloads page to unbury the Hatch download link |
| 15:23 |
* berick |
hi-fives dbwells |
| 15:23 |
gmcharlt |
and I have a question about the Hatch windows installer (and I suppose the XUL client installer, at least for a while longer)... is there any particular benefit to investing in a signing key? |
| 15:25 |
JBoyer |
It may change the appearance of the UAC prompt but it won't go away. It can be reassuring if an admin has strong a strong pref for signed software. |
| 15:26 |
JBoyer |
(And there may already be an option in Win10 to only install/run signed software, though it's off by default. For now.) |
| 15:26 |
gmcharlt |
so not presently a big deal unless Microsoft either tightens the screws or folks start expressing that lack of one is a showstopper? |
| 15:26 |
JBoyer |
Yeah, I'd wait for now. |
| 15:27 |
gmcharlt |
kk |
| 15:27 |
gmcharlt |
moving on |
| 15:27 |
gmcharlt |
in new business |
| 15:27 |
gmcharlt |
#topic mixed use of voids / account adjustment |
| 15:27 |
gmcharlt |
#link https://bugs.launchpad.net/evergreen/+bug/1671856 |
| 15:27 |
pinesol_green |
Launchpad bug 1671856 in Evergreen "Mixed use of Account Adjustment payments creates inconsistency" [Undecided,New] |
| 15:28 |
gmcharlt |
this is one that kmlussier raised |
| 15:28 |
gmcharlt |
so as far as the folks who have participated in that bug to date... is there a consensus? |
| 15:28 |
gmcharlt |
or does this bear further discussion? |
| 15:28 |
dbwells |
I added a reply to that bug just before the meeting. In essence, I am begging for my time to get a couple branches finished with an alternative direction. |
| 15:28 |
Dyrcona |
Well, #2 is the approach that I took in my original branch, so that would be my preference. |
| 15:29 |
Dyrcona |
dbwells++ # I saw the email but haven't had time to read your response in full. |
| 15:30 |
* berick |
also looks forward to reading |
| 15:30 |
berick |
thanks dbwells |
| 15:30 |
miker |
I need to catch up on that as well |
| 15:30 |
Dyrcona |
Option #3: Gut billing and start over? |
| 15:30 |
miker |
I have feelings, but I'm out of date |
| 15:30 |
* Dyrcona |
ducks. |
| 15:30 |
dbwells |
I also started drafting this page as a place to organize some thoughts (at least for my own sanity): https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:3.1:billing |
| 15:31 |
dbwells |
That page is linked from the 3.1 roadmap as well. |
| 15:31 |
gmcharlt |
so... it's kinda sounding to me that what we should do is discuss more and plan for (say as part of the January dev meeting?) a grand melee^W hashing out of the options? |
| 15:32 |
JBoyer |
2 options enter, a third option leaves. |
| 15:32 |
Dyrcona |
:) |
| 15:32 |
berick |
aww, a baby option |
| 15:32 |
csharp |
berick++ |
| 15:34 |
gmcharlt |
let the options multiply! |
| 15:34 |
gmcharlt |
... actually, let's not |
| 15:34 |
stephengwills |
lol |
| 15:34 |
gmcharlt |
but unless there's objection, I'll just add that as an agenda item for the January meeting |
| 15:34 |
JBoyer |
+1 |
| 15:34 |
Dyrcona |
+1 |
| 15:34 |
miker |
+1 |
| 15:34 |
dbwells |
+1 |
| 15:35 |
remingtron |
+1 |
| 15:35 |
gmcharlt |
k |
| 15:35 |
gmcharlt |
moving on |
| 15:35 |
gmcharlt |
#topic Updating numbered upgrade scripts to match what's in the version upgrade script |
| 15:35 |
* dbwells |
puts his code waders on, gets busy |
| 15:35 |
gmcharlt |
#info bug 1719726 |
| 15:35 |
pinesol_green |
Launchpad bug 1719726 in Evergreen "updates to monolithic schema update script for 3.0-rc" [Medium,Fix released] https://launchpad.net/bugs/1719726 |
| 15:36 |
Dyrcona |
So, I tried making a custom upgrade script using make_release, and it don't work, because fixes were made to the omnibus, 2.12.6-3.0.0 upgrade and not ported to the numbered upgrade scripts. |
| 15:37 |
Dyrcona |
So, the question is what is the consensus on porting such fixes to numbered upgrade scripts? Yay or nay? |
| 15:38 |
miker |
well, there will always be things from numbered that can be elided in omnibus. multiple reingests, etc |
| 15:39 |
miker |
so, my pref would be to make use of the supersedes logic, make /new/ numbered ones, and teach make_release how to use only the ones that aren't deprecated |
| 15:39 |
miker |
but, tuits |
| 15:39 |
Dyrcona |
Is there any supersedes logic started? |
| 15:39 |
miker |
and if we broke reingests out into their own, they could be superseded |
| 15:39 |
gmcharlt |
not to my knowledge |
| 15:40 |
miker |
there ... was. I'd have to refresh myself on the details |
| 15:40 |
miker |
and it may be 99% design ATM |
| 15:40 |
Dyrcona |
I know it has been discussed for some time. Maybe there's some code on a branch that didn't make it in? |
| 15:41 |
miker |
it predates git, actually... I will try to do some spelunking soon |
| 15:41 |
dbwells |
I've seen it somewhere, in some form, at some point. If that helps :) |
| 15:41 |
Dyrcona |
:) |
| 15:41 |
gmcharlt |
as an interim measure, would it be useful to start moving reingests into separate scripts |
| 15:41 |
gmcharlt |
i.e., |
| 15:42 |
gmcharlt |
1666.data.change-all-the-indexing-rule.sql |
| 15:42 |
gmcharlt |
1667.reingest.all-the-things? |
| 15:42 |
dbwells |
+1 to reindexes in separate files |
| 15:42 |
miker |
so, there is some, actually |
| 15:43 |
Dyrcona |
Do we really want to use numbers on ingests, though? |
| 15:43 |
berick |
+1 to separate files too |
| 15:43 |
miker |
config.db_patch_dependencies (table), and some functions: evergreen.upgrade_list_applied_deprecates and friends |
| 15:46 |
miker |
Dyrcona: it helps ordering, re make_release |
| 15:46 |
Dyrcona |
OK. +1 separate files |
| 15:46 |
gmcharlt |
doesn't look like any update script has ever inserted into config.db_patch_dependencies to date, though |
| 15:46 |
miker |
(note, the stuff I mention here is about making sure already-applied patches don't conflict -- not pending patch interdependencies, which is what we're really talking about now) |
| 15:46 |
miker |
gmcharlt: correct, there was a plan for a script to investigate special comments in the files |
| 15:47 |
miker |
but none of the db-external stuff has been written yet. and deserves a real plan |
| 15:48 |
dbwells |
I think editing of a numbered upgrade script is always fine in the case of an error, i.e. this script has never actually worked for anyone. Maybe that much is obvious. I also think it might be okay, in our current state, to make changes that are purely performance related, but will have the identical outcomes. Perhaps others will disagree there. |
| 15:48 |
miker |
I think the make_release use case for version-to-version shouldn't be too hard. the original, whole plan, though... |
| 15:49 |
miker |
dbwells: agreed on (1), and if the data is idempotent then also to (2) |
| 15:49 |
dbwells |
And when I say "worked", I mean completed, not necessarily doing the intended action :) |
| 15:49 |
miker |
and (1) is Dyrcona's original cause of pain, IIUC? |
| 15:50 |
gmcharlt |
as it, did it success in its transaction... even if dropped the database? ;) |
| 15:50 |
Dyrcona |
Well, that the changes were made to the big script and not to the numbered one, yes. |
| 15:50 |
Dyrcona |
But, I solved my immediate problem. |
| 15:50 |
Dyrcona |
I just wonder if anyone else will run into this. |
| 15:51 |
gmcharlt |
Dyrcona: to dive into specifics... which ones were there that were not purely about performance ? |
| 15:51 |
Dyrcona |
gmcharlt: There was a WHERE NOT deletd added to one that made all the difference between success and failure on my data, at least. |
| 15:52 |
Dyrcona |
For the update vis_attr_vector. |
| 15:52 |
miker |
Dyrcona: that should be backported, I agree |
| 15:54 |
JBoyer |
I should have asked around more at the time; that day I assumed we didn't mess with already-numbered scripts. |
| 15:54 |
JBoyer |
And this points more toward a final answer of "it depends." :) |
| 15:54 |
miker |
JBoyer: I share your shame, IIRC. :( |
| 15:55 |
gmcharlt |
and I get a slice of the shame as well |
| 15:55 |
gmcharlt |
but anyway... I think we have a clear path for a bugfix |
| 15:55 |
JBoyer |
well, we did all move on to a lot of other things rapidly after. |
| 15:55 |
gmcharlt |
and work to do for 3.1 |
| 15:56 |
gmcharlt |
so |
| 15:56 |
gmcharlt |
any other topics? |
| 15:56 |
dbwells |
To attempt to state the principle again, "Will a database successfully running version A be identical to the same database running version B? If yes, then the change is safe to make." Is this correct? (and ignoring corrections for other obvious tragic data-loss bugs...) |
| 15:57 |
miker |
dbwells: that is a fair statement of one "edit it" trigger |
| 15:58 |
gmcharlt |
dbwells: possibly modified to this: running the monolithic update or a set of point updates corresponding to the same start and end point should have the same results |
| 15:59 |
gmcharlt |
(as opposed to somebody using a dev machine tracking master, where despite best efforts there's more of a chance of oppsies happening) |
| 15:59 |
Dyrcona |
That works for me. :) |
| 15:59 |
dbwells |
Okay, sounds good. |
| 15:59 |
miker |
+1 |
| 16:00 |
|
khuckins joined #evergreen |
| 16:01 |
gmcharlt |
ok |
| 16:01 |
gmcharlt |
we're at the end of the hour, so... |
| 16:01 |
* Dyrcona |
moves to adjourn if there's no more business. |
| 16:01 |
gmcharlt |
#endmeeting |
| 16:01 |
pinesol_green |
Meeting ended Wed Dec 13 16:01:40 2017 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 16:01 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2017/evergreen.2017-12-13-15.02.html |
| 16:01 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2017/evergreen.2017-12-13-15.02.txt |
| 16:01 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2017/evergreen.2017-12-13-15.02.log.html |
| 16:01 |
gmcharlt |
thanks, folks! |
| 16:01 |
JBoyer |
gmcharlt++ |
| 16:01 |
miker |
gmcharlt++ |
| 16:01 |
JBoyer |
dbwells++ |
| 16:01 |
Dyrcona |
gmcharlt++ |
| 16:01 |
Dyrcona |
folks++ |
| 16:02 |
Bmagic |
gmcharlt++ |
| 16:02 |
dbwells |
gmcharlt++ |
| 16:02 |
remingtron |
gmcharlt++ |
| 16:05 |
jeffdavis |
dbwells: do I remember correctly that you had some local work around improved serials sorting? |
| 16:07 |
|
stephengwills left #evergreen |
| 16:07 |
dbwells |
jeffdavis: Yes, we have a number of sorting tweaks for different serials views. Is there a particular case you are interested in? |
| 16:11 |
jeff |
we're about to order serials holdings in our discovery layer by... date_published DESC, I think. |
| 16:12 |
* jeff |
reviews meeting |
| 16:14 |
miker |
dbwells: having read your bug update, you stated exactly my thoughts. void == mistake, adjustment == credit |
| 16:15 |
|
kmlussier joined #evergreen |
| 16:15 |
gmcharlt |
quick poll of the room |
| 16:15 |
gmcharlt |
ordinarily, the next developer meeting would fall on 1/3 |
| 16:16 |
gmcharlt |
but... I'm dubious about that time :) |
| 16:16 |
gmcharlt |
would folks prefer 1/10? |
| 16:17 |
Dyrcona |
I would. I have other meeting on 1/3, plus too close to holidays. |
| 16:18 |
dbwells |
gmcharlt: I support that as well. Always so much to catch up on after the break. |
| 16:18 |
jeff |
+1 to 1/10 |
| 16:18 |
gmcharlt |
k, I shall run with it |
| 16:24 |
|
Jillianne joined #evergreen |
| 16:25 |
kmlussier |
A belated +1 from me. |
| 16:26 |
jeffdavis |
dbwells: I'm following up on bug 1429317 - sorting serials chronologically in the main holdings display. |
| 16:26 |
pinesol_green |
Launchpad bug 1429317 in Evergreen "Serials in holdings view should be able to sort in ascending and descending order as well as by call number" [Wishlist,Incomplete] https://launchpad.net/bugs/1429317 |
| 16:27 |
dbwells |
jeffdavis: great, thank you |
| 16:55 |
mmorgan |
This goes back to lp 1736419 and friends - I notice when I do a keyword search on "tolkien" in the opac of webby.evergreencatalog.com, I get no hits. The tolkien records do come up in the staff client. |
| 16:55 |
pinesol_green |
Launchpad bug 1736419 in Evergreen "Search Showing Bibs with no Holdings" [High,Confirmed] https://launchpad.net/bugs/1736419 |
| 16:56 |
mmorgan |
On the mlnc4 demo server running 2.12, the tolkien records come up in the opac. |
| 16:56 |
Bmagic |
Anyone else seeing this error in the browser console when performing a patron search from the holds page? Error: egCore.env.actsc is undefined |
| 16:57 |
kmlussier |
mmorgan: Yes, that's right. I saw reference to that issue in the IRC logs when I was looking into the problem. |
| 16:58 |
mmorgan |
So seems like something is different with a new build vs upgrade? |
| 16:58 |
kmlussier |
I think I linked to the log in that bug. |
| 16:59 |
mmorgan |
Indeed you did! |
| 17:00 |
* kmlussier |
hasn't tested miker's patch for that issue yet. |
| 17:01 |
kmlussier |
mmorgan: But the upgrade vs. new build difference makes sense to me. It would explain why you didn't originally see the problem on the upgraded system until you added a new record with a Located URI, while I saw the problem with all the records on my newly-built system. |
| 17:04 |
* mmorgan |
is heading home, but is sure to have dreams about this bug :-( |
| 17:05 |
|
mmorgan left #evergreen |
| 17:22 |
|
kmlussier joined #evergreen |
| 17:28 |
|
kmlussier joined #evergreen |
| 17:41 |
|
mllewellyn left #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 21:36 |
|
mnsri joined #evergreen |
| 21:36 |
|
rashma joined #evergreen |
| 22:55 |
|
Christineb joined #evergreen |
