Evergreen ILS Website

IRC log for #evergreen, 2017-12-13

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

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/do​ku.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/evergr​een/2017/evergreen.2017-12-13-15.02.html
16:01 pinesol_green Minutes (text): http://evergreen-ils.org/meetings/evergr​een/2017/evergreen.2017-12-13-15.02.txt
16:01 pinesol_green Log:            http://evergreen-ils.org/meetings/evergree​n/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

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat