15:02:11 <gmcharlt> #startmeeting Development meeting, 13 December 2017
15:02:11 <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:11 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:11 <pinesol_green> The meeting name has been set to 'development_meeting__13_december_2017'
15:02:18 <gmcharlt> #info Agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2017-12-13
15:02:46 <gmcharlt> #topic Introductions
15:02:49 <Dyrcona> #info Dyrcona is Jason Stephenson, C/W MARS
15:02:52 <gmcharlt> #info gmcharlt = Galen Charlton, Equinox
15:02:58 <remingtron> #info remingtron = Remington Steed, Hekman Library (Calvin College)
15:03:16 <berick> #info berick Bill Erickson, KCLS
15:03:25 <dbwells> #info dbwells = Dan Wells, Hekman Library (Calvin College)
15:03:29 <jeffdavis> #info jeffdavis = Jeff Davis, BC Libraries Coop (Sitka)
15:03:32 <miker> #info miker = Mike Rylander, EOLI
15:03:32 <abneiman> #info abneiman = Andrea Neiman, Equinox
15:03:34 <JBoyer> #info JBoyer Jason Boyer, IN State Library
15:04:14 <rhamby> #info Rogan Hamby, Equinox
15:04:33 <Bmagic> #info Bmagic, MOBIUS
15:05:14 <gmcharlt> #topic Action items from past peeting
15:05:18 <gmcharlt> er
15:05:23 <gmcharlt> #topic Action items from past meeting
15:05:39 <gmcharlt> I guess we're all drinking Peets coffee now
15:05:45 <gmcharlt> anyway
15:05:50 <gmcharlt> one is just a carry-over
15:05:59 <gmcharlt> #action gmcharlt will open and work on bugs for documentation changes for better ejabberd configuration during installation of OpenSRF
15:06:05 <gmcharlt> no progress to report yet
15:06:14 <gmcharlt> while the other does have progress
15:06:15 <gmcharlt> namely
15:06:31 <gmcharlt> #info Hatch extension is now available in the Chrome store
15:06:33 <gmcharlt> berick++
15:06:39 <dbwells> berick++
15:06:43 <JBoyer> berick++
15:06:51 * berick had help
15:06:56 <berick> yall++
15:07:06 <JBoyer> mjingle++
15:07:20 <gmcharlt> berick: JBoyer: any other updates on Hatch other than mention of bug 1733692 and bug 1708757 ?
15:07:21 <pinesol_green> Launchpad bug 1733692 in Evergreen "Hatch Windows installer doesn't follow best practices" [High,New] https://launchpad.net/bugs/1733692
15:07:22 <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:30 <stephengwills> #info stephengwills with Maine Balsam Libraries
15:07:39 <berick> gmcharlt: just a note at the bottom of the agenda re: web site
15:07:48 <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:54 <gmcharlt> ok
15:07:59 <JBoyer> I suspect it can't be done on the work PC.
15:08:09 <gmcharlt> then I'll wait until we get to that point in the agenda
15:08:24 <gmcharlt> so, moving on
15:08:36 <gmcharlt> #topic OpenSRF updates
15:09:20 <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:29 <gmcharlt> so ...
15:10:20 <gmcharlt> #action gmcharlt will work on patches destined for a release of OpenSRF 3.0.1 in January
15:10:36 <gmcharlt> and I'm looking for any other patches and bug nominations that folks care to offer
15:11:31 <gmcharlt> #topic Evergreen update
15:11:34 <gmcharlt> dbwells?
15:12:06 <dbwells> Not a whole lot to report at this point, but a few things.
15:12:15 <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:39 <dbwells> I expect that to be out by the new year at the latest.
15:13:09 <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:27 <dbwells> Thank you to folks who have been updating the roadmap.
15:13:59 * csharp rushes into the meeting, panting
15:14:00 <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:19 <csharp> #info csharp = Chris Sharp, GPLS
15:15:10 <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:24 <dbwells> That is all for now.
15:15:29 <dbwells> Any questions?
15:16:13 <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:18 <gmcharlt> what... is your favorite color?
15:16:25 <gmcharlt> seriously, +1 to the timeline
15:16:29 <dbwells> Blue, I mean... aaaaahhhh!
15:16:35 <Dyrcona> :)
15:17:02 <gmcharlt> so, hearing no questions for dbwells...
15:17:05 <gmcharlt> #topic Hatch update
15:17:14 <gmcharlt> and I'll just move the downloads page discussion here
15:17:24 <gmcharlt> so berick... what do you have in mind?
15:17:44 <berick> for starters, just somewhere we can point people for fetching the windows installer
15:18:00 <berick> was not sure how best to go about that
15:18:05 <gmcharlt> beyond the links from https://evergreen-ils.org/egdownloads/?
15:18:31 <berick> *headdesk* i've never scrolled down that far
15:18:39 <csharp> heh
15:18:40 <JBoyer> XD
15:18:49 <gmcharlt> well, that does suggest a UX issue, or at least a datapoint
15:19:12 <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:34 <gmcharlt> I know there was talk a while back of redesigning the downloads page... anybody have a desire to scratch that itch?
15:19:35 <Dyrcona> Hatch is meant to be independent of EG version?
15:19:37 <JBoyer> Nor should old versions be kept around (as of yet, if the API changes, we can revisit.)
15:19:52 <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:01 <dbwells> I think it makes good sense to put it near the Windows client download link, at least.
15:20:09 <csharp> dbwells: +1
15:20:52 <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:26 <remingtron> dbwells: +1
15:22:35 <berick> gmcharlt: i think that gives me enough for now
15:22:36 <gmcharlt> dbwells: do you want to take on that small tweak?
15:22:44 <berick> and thanks
15:22:48 <dbwells> gmcharlt: sure
15:23:11 <gmcharlt> #action dbwells will tweak the Evergreen downloads page to unbury the Hatch download link
15:23:28 * berick hi-fives dbwells
15:23:55 <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:26 <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:03 <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:34 <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:53 <JBoyer> Yeah, I'd wait for now.
15:27:02 <gmcharlt> kk
15:27:03 <gmcharlt> moving on
15:27:17 <gmcharlt> in new business
15:27:35 <gmcharlt> #topic mixed use of voids / account adjustment
15:27:45 <gmcharlt> #link https://bugs.launchpad.net/evergreen/+bug/1671856
15:27:45 <pinesol_green> Launchpad bug 1671856 in Evergreen "Mixed use of Account Adjustment payments creates inconsistency" [Undecided,New]
15:28:02 <gmcharlt> this is one that kmlussier raised
15:28:27 <gmcharlt> so as far as the folks who have participated in that bug to date... is there a consensus?
15:28:39 <gmcharlt> or does this bear further discussion?
15:28:48 <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:52 <Dyrcona> Well, #2 is the approach that I took in my original branch, so that would be my preference.
15:29:20 <Dyrcona> dbwells++ # I saw the email but haven't had time to read your response in full.
15:30:17 * berick also looks forward to reading
15:30:20 <berick> thanks dbwells
15:30:25 <miker> I need to catch up on that as well
15:30:41 <Dyrcona> Option #3: Gut billing and start over?
15:30:43 <miker> I have feelings, but I'm out of date
15:30:44 * Dyrcona ducks.
15:30:49 <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:16 <dbwells> That page is linked from the 3.1 roadmap as well.
15:31:48 <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:09 <JBoyer> 2 options enter, a third option leaves.
15:32:14 <Dyrcona> :)
15:32:30 <berick> aww, a baby option
15:32:43 <csharp> berick++
15:34:00 <gmcharlt> let the options multiply!
15:34:05 <gmcharlt> ... actually, let's not
15:34:29 <stephengwills> lol
15:34:38 <gmcharlt> but unless there's objection, I'll just add that as an agenda item for the January meeting
15:34:43 <JBoyer> +1
15:34:46 <Dyrcona> +1
15:34:48 <miker> +1
15:34:58 <dbwells> +1
15:35:08 <remingtron> +1
15:35:23 <gmcharlt> k
15:35:27 <gmcharlt> moving on
15:35:29 <gmcharlt> #topic Updating numbered upgrade scripts to match what's in the version upgrade script
15:35:30 * dbwells puts his code waders on, gets busy
15:35:38 <gmcharlt> #info bug 1719726
15:35:38 <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:34 <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:11 <Dyrcona> So, the question is what is the consensus on porting such fixes to numbered upgrade scripts? Yay or nay?
15:38:01 <miker> well, there will always be things from numbered that can be elided in omnibus. multiple reingests, etc
15:39:03 <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:08 <miker> but, tuits
15:39:40 <Dyrcona> Is there any supersedes logic started?
15:39:47 <miker> and if we broke reingests out into their own, they could be superseded
15:39:47 <gmcharlt> not to my knowledge
15:40:16 <miker> there ... was. I'd have to refresh myself on the details
15:40:42 <miker> and it may be 99% design ATM
15:40:51 <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:19 <miker> it predates git, actually... I will try to do some spelunking soon
15:41:32 <dbwells> I've seen it somewhere, in some form, at some point.  If that helps :)
15:41:41 <Dyrcona> :)
15:41:47 <gmcharlt> as an interim measure, would it be useful to start moving reingests into separate scripts
15:41:50 <gmcharlt> i.e.,
15:42:06 <gmcharlt> 1666.data.change-all-the-indexing-rule.sql
15:42:12 <gmcharlt> 1667.reingest.all-the-things?
15:42:28 <dbwells> +1 to reindexes in separate files
15:42:29 <miker> so, there is some, actually
15:43:07 <Dyrcona> Do we really want to use numbers on ingests, though?
15:43:30 <berick> +1 to separate files too
15:43:37 <miker> config.db_patch_dependencies (table), and some functions: evergreen.upgrade_list_applied_deprecates and friends
15:43:58 <miker> Dyrcona: it helps ordering, re make_release
15:44:36 <Dyrcona> OK. +1 separate files
15:45:51 <gmcharlt> doesn't look like any update script has ever inserted into config.db_patch_dependencies to date, though
15:45:56 <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:35 <miker> gmcharlt: correct, there was a plan for a script to investigate special comments in the files
15:47:08 <miker> but none of the db-external stuff has been written yet. and deserves a real plan
15:48:15 <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:20 <miker> I think the make_release use case for version-to-version shouldn't be too hard. the original, whole plan, though...
15:49:09 <miker> dbwells: agreed on (1), and if the data is idempotent then also to (2)
15:49:31 <dbwells> And when I say "worked", I mean completed, not necessarily doing the intended action :)
15:49:52 <miker> and (1) is Dyrcona's original cause of pain, IIUC?
15:50:09 <gmcharlt> as it, did it success in its transaction... even if dropped the database? ;)
15:50:15 <Dyrcona> Well, that the changes were made to the big script and not to the numbered one, yes.
15:50:43 <Dyrcona> But, I solved my immediate problem.
15:50:54 <Dyrcona> I just wonder if anyone else will run into this.
15:51:01 <gmcharlt> Dyrcona: to dive into specifics... which ones were there that were not purely about performance ?
15:51:46 <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:11 <Dyrcona> For the update vis_attr_vector.
15:52:40 <miker> Dyrcona: that should be backported, I agree
15:54:10 <JBoyer> I should have asked around more at the time; that day I assumed we didn't mess with already-numbered scripts.
15:54:50 <JBoyer> And this points more toward a final answer of "it depends." :)
15:54:52 <miker> JBoyer: I share your shame, IIRC. :(
15:55:09 <gmcharlt> and I get a slice of the shame as well
15:55:22 <gmcharlt> but anyway... I think we have a clear path for a bugfix
15:55:30 <JBoyer> well, we did all move on to a lot of other things rapidly after.
15:55:30 <gmcharlt> and work to do for 3.1
15:56:26 <gmcharlt> so
15:56:30 <gmcharlt> any other topics?
15:56:49 <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:58 <miker> dbwells: that is a fair statement of one "edit it" trigger
15:58:29 <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:15 <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:16 <Dyrcona> That works for me. :)
15:59:25 <dbwells> Okay, sounds good.
15:59:28 <miker> +1
16:01:29 <gmcharlt> ok
16:01:37 <gmcharlt> we're at the end of the hour, so...
16:01:39 * Dyrcona moves to adjourn if there's no more business.
16:01:40 <gmcharlt> #endmeeting