[00:26:15] fundraising-tech-ops, Monitoring: overhaul fundraising cluster monitoring - https://phabricator.wikimedia.org/T91508#2911791 (Peachey88) [00:31:30] fundraising-tech-ops, Operations: SSL cert for payments-listener.wikimedia.org expires on 2017-01-09 (~6 days) - https://phabricator.wikimedia.org/T154448#2911794 (fgiunchedi) cc @Jgreen @RobH [00:32:49] fundraising-tech-ops, Operations: SSL cert for payments-listener.wikimedia.org expires on 2017-01-09 (~6 days) - https://phabricator.wikimedia.org/T154448#2911796 (Dereckson) p:Triage>High [06:59:44] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Patch-For-Review: Stop adding "Review" tag to everything in Civi - https://phabricator.wikimedia.org/T118904#1812330 (Eileenmcnaughton) Cleanup query on staging : 885.259405 seconds. 15374298 row(s)s subjec... [15:47:46] fundraising-tech-ops, Operations: SSL cert for payments-listener.wikimedia.org expires on 2017-01-09 (~6 days) - https://phabricator.wikimedia.org/T154448#2912920 (RobH) Open>declined This is a dupe of T153097. Processing it now. [17:09:08] (PS2) Ejegg: Do not write address to the database if all data is empty. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/328607 (https://phabricator.wikimedia.org/T153804) (owner: Eileen) [17:09:17] (CR) Ejegg: [C: 2] Do not write address to the database if all data is empty. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/328607 (https://phabricator.wikimedia.org/T153804) (owner: Eileen) [17:14:24] (Merged) jenkins-bot: Do not write address to the database if all data is empty. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/328607 (https://phabricator.wikimedia.org/T153804) (owner: Eileen) [17:15:25] (PS2) Ejegg: Consolidate test data into one directory. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329354 (owner: Eileen) [17:15:47] (CR) Ejegg: [C: 2] "more conventional!" (2 comments) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329354 (owner: Eileen) [17:19:38] (Merged) jenkins-bot: Consolidate test data into one directory. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329354 (owner: Eileen) [17:29:12] (PS2) Ejegg: Consolidate test cleanup routine into parent class [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329356 (owner: Eileen) [17:30:41] (CR) Ejegg: [C: 2] "This works, though if it's for a single transaction it might make sense to pass the trxn_id in as a method argument." [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329356 (owner: Eileen) [17:34:43] (Merged) jenkins-bot: Consolidate test cleanup routine into parent class [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329356 (owner: Eileen) [17:35:12] (PS2) Ejegg: Add preliminary CoinBase Test. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329357 (https://phabricator.wikimedia.org/T153791) (owner: Eileen) [17:35:26] (CR) Ejegg: [C: 2] Add preliminary CoinBase Test. (2 comments) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329357 (https://phabricator.wikimedia.org/T153791) (owner: Eileen) [17:36:41] (PS2) Ejegg: Remove duplicate field in import fields array. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329358 (https://phabricator.wikimedia.org/T153791) (owner: Eileen) [17:36:49] (CR) Ejegg: [C: 2] Remove duplicate field in import fields array. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329358 (https://phabricator.wikimedia.org/T153791) (owner: Eileen) [17:39:48] (Merged) jenkins-bot: Add preliminary CoinBase Test. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329357 (https://phabricator.wikimedia.org/T153791) (owner: Eileen) [17:43:55] (Merged) jenkins-bot: Remove duplicate field in import fields array. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329358 (https://phabricator.wikimedia.org/T153791) (owner: Eileen) [17:46:00] (PS2) Ejegg: Fix test that was not running to run. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329646 (owner: Eileen) [17:46:04] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Spike: Impressions abnormally low for Ireland - https://phabricator.wikimedia.org/T152650#2913401 (AndyRussG) Found it!!! The lost mobile impressions in Ireland are from a little over 400 IP addresses belo... [17:46:48] (CR) Ejegg: [C: 2] "Huh, seems to be a maintenance script we haven't used in my time here. Thanks for converting the script!" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329646 (owner: Eileen) [17:51:11] o/ [17:51:38] ejegg: thinking i'll revert the vendor update i did to crm since adam already updated phpmailer specifically [17:52:07] cwd oh? [17:52:14] k, makes sense [17:52:20] https://gerrit.wikimedia.org/r/#/c/329497/ [17:52:30] yeah that updates a ton of unnecessary stuff [17:52:43] yep, let's keep it to phpmailer for now [17:52:51] although i do think we might benefit from composer updating more often [17:53:02] so that we don't have to make such big leaps [17:53:16] on all our vendor repos [17:53:25] fr-tech someone want to merge https://gerrit.wikimedia.org/r/329531 so we can update phpqueue lib in vendor dirs? [17:53:28] (PS1) Cdentinger: Revert "Update PHPmailer for CVE-2016-10045 and CVE-2016-10033" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/330253 [17:56:37] (CR) Cdentinger: "I would like to find out why we were not seeing the expected exception that the current code should have been throwing so we can be positi" [wikimedia/fundraising/php-queue] - https://gerrit.wikimedia.org/r/329531 (owner: Ejegg) [17:58:35] (Merged) jenkins-bot: Fix test that was not running to run. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329646 (owner: Eileen) [18:00:30] fr-tech: Afternoon, n.: [18:00:30] That part of the day we spend worrying about how we wasted the [18:00:30] morning. [18:00:30] -- discuss. [18:07:03] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Spike: Impressions abnormally low for Ireland - https://phabricator.wikimedia.org/T152650#2913475 (Dzahn) Ah, so is this a thing to report to Maxmind as a bug / request for correction via that form after al... [18:14:59] slander_: hahahaha [18:20:16] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Spike: Impressions abnormally low for Ireland - https://phabricator.wikimedia.org/T152650#2913544 (AndyRussG) >>! In T152650#2913475, @Dzahn wrote: > Ah, so is this a thing to report to Maxmind as a bug / r... [18:21:06] fr-tech! morning, and happy new year! Pls lmk if anyone's doing tech-talk :) thx!! [18:30:45] (PS1) Ejegg: Fix JsonException extends statement [wikimedia/fundraising/php-queue] - https://gerrit.wikimedia.org/r/330256 [18:32:14] (CR) Ejegg: "Thanks for prompting me to keep digging, cwd! We were trying to throw the unthrowable - JsonException wasn't extending the right thing. I1" [wikimedia/fundraising/php-queue] - https://gerrit.wikimedia.org/r/329531 (owner: Ejegg) [18:33:28] I'm in fr-tech-talk if anyone has anything to discuss [18:33:48] And happy new year to all as well! [18:34:20] ejegg: :) joining in a minute! [19:26:27] Fundraising-Backlog, fundraising-tech-ops: create and/or automate tools for auditing composer-installed php packages - https://phabricator.wikimedia.org/T154509#2913824 (Jgreen) [19:32:15] cwd are you about? I was looking to deploy & hit a merge conflict on composer.json which I know you wrestled with... [19:32:31] eileen: yep [19:32:39] composer.lock I think actually [19:32:49] hmm, i reverted a change...one sec [19:33:15] eileen: https://gerrit.wikimedia.org/r/#/c/330253/ [19:33:32] adam updated phpmailer in a diff commit [19:33:52] oh wow that's confusing - do you need to then re-fix the composer stuff? [19:34:26] rgh yeah i didn't think of that, reverting this will undo the other change [19:34:32] eileen: I'll resume reviewing the last few patches in that chain after I relocate to the library [19:34:44] and snag a bite of food [19:35:48] ejegg[m]: thanks [19:39:07] eileen: sorry for screwing up your repo :-\ [19:39:11] i was flailing [19:41:50] cwd no that's cool - I was just trying to make sense of it all [19:42:11] it feels like you fixed up composer & now we will undo that ? [19:43:34] I'm kind of confused about whether reverting is helpful - or whether just getting the right commit done makes more sense [19:43:42] good point [19:43:56] (PS2) Eileen: Add support for importing campaign source, medium for CoinBase. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329647 (https://phabricator.wikimedia.org/T153791) [19:44:48] (PS2) Eileen: Do not keep 'artificial' contribution_tracking record on failure. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329650 (https://phabricator.wikimedia.org/T153791) [19:45:05] eileen: except, i think adam's work was only on deployment branch [19:45:42] ouch [19:46:05] (CR) Addshore: [C: 2] Remove donationinterface-desc from extension.json [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/329683 (owner: Umherirrender) [19:46:06] can we cherry pick that back to master? [19:46:16] * cwd goes crosseyed [19:46:25] :-) [19:46:42] i guess it will probably conflict with this, unless we go through with the revert [19:46:50] revert it and then cherry-pick back to master? [19:47:12] OK - I'm Ok to ci the revert I think [19:47:29] it really is just a revert - you didn't have any merge conflicts? [19:47:48] cr not ci [19:48:37] eileen: i just pressed the revert button on gerrit [19:49:00] ok - I'll + 2 it [19:49:20] weird thing is, i don't have that commit on local master [19:49:47] (CR) Eileen: [C: 2] "This is a straight up revert - composer will be in not-quite right state but this is a step towards sorting that." [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/330253 (owner: Cdentinger) [19:50:02] the revert one? [19:50:44] ooh yes i do there was just a lot of merges today [19:51:05] (the commit to be reverted) [19:51:05] (CR) Eileen: "This is purely about syncing up trivial discrepancies with upstream in order to apply the upgrade" [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/329720 (owner: Eileen) [19:52:15] (Merged) jenkins-bot: Remove donationinterface-desc from extension.json [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/329683 (owner: Umherirrender) [19:53:02] (Merged) jenkins-bot: Revert "Update PHPmailer for CVE-2016-10045 and CVE-2016-10033" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/330253 (owner: Cdentinger) [19:53:10] Should I feel concerned that I feel a little bit excited about getting rid of that review tag? [19:53:27] eileen: there were like 5 commits on deployment during that mess [19:53:38] maybe i should just copy composer.* from deployment to master [19:54:06] that might work [19:54:22] then it should be possible to do a merge commit & they will be in sync [19:54:53] I must say I saw you & AndyRussG discussing the whole composer thing & figured you had it under control [19:55:06] I may not have been sensitive enough to your pain :-) [19:55:30] because I think I left to go to the beach. [19:56:03] hehe [19:56:07] sounds nice [19:56:32] heh don't worry :) [19:56:35] i got pretty confused that day [19:56:57] And I mainly just added to the confusion :) [19:57:33] yeah things just seemed to all roll into one too - one minute it was crashed disks next it was security issues [19:57:47] Obvious answer is to find someone who isn't here & blame them [19:58:06] it was trump [19:58:28] :-) [19:58:39] heheh and his lies about millions of failed composer disks [20:03:26] eileen: to continue the pattern of woe, the composer files are quite different between deployment and master [20:03:33] well just the lockfile [20:03:46] but i'm guessing it has had edits that never made it back to master [20:05:12] I think you can literally copy it over the top & commit.... [20:05:19] git diff deployment master -- composer.lock | wc -l [20:05:21] 1439 [20:05:27] yuck [20:05:44] but yeah deployment is i suppose canonical [20:06:09] * cwd imagines what CI has been doing [20:06:09] we have good reason to believe it works in production.... [20:06:43] Like WP, "only works in practice, not in theory" ;p [20:06:51] heh [20:06:52] :-) [20:07:28] good t-shirt [20:13:58] eileen: deployment/composer.lock doesn't have the dev deps either [20:14:14] i guess cause --no-dev can be run on either install or update [20:14:18] oh yeah ug [20:14:51] the longer i do this the more i think it's composer that sucks and not me [20:15:30] :-) [20:15:32] besides the autoloader, the rest seems better handled by git [20:16:13] dev deps? put them on the dev branch [20:17:29] well, autoloader and dependency chains [20:17:49] submodules can represent dependency chains [20:18:28] http://stackoverflow.com/questions/12896780/should-composer-lock-be-committed-to-version-control [20:18:30] yeah, it's just no fun to manually recursively track 'em all down for install [20:18:44] reminds me of rpms in the bad old days [20:18:48] this person argues get your composer.json specific & don't commit the lock file [20:19:23] yeah i think that's the workflow most dependency managers use [20:19:30] composer.lock seems like an official hack [20:20:01] hmm long discussion on there actually [20:20:11] but at the same time i think the thing it's really making easy is quickly installing a lot of unvetted code [20:20:45] from random githubs etc [20:20:54] hang on though... [20:21:07] if you run composer install with or without require-dev [20:21:22] wouldn't you get a different result, even if you have the same lock file? [20:21:32] eileen: yep [20:21:36] I mean the lock file can have dev things in it but they won't install [20:21:44] so our .lock file can have all the dev deps in it [20:21:46] yeah [20:21:58] but if you do update --no-dev it will strip dev stuff from the lockfile [20:21:59] no need to snip 'em for the deploy merge [20:22:05] which must have happened on crm/deployment [20:22:16] ah right [20:22:25] which is an anti-feature [20:22:45] imo [20:22:58] I assume the line that actually runs on boron is composer install —no-dev ? [20:23:18] we only deploy the submodule [20:23:27] so it shouldn't run composer anything [20:23:56] doesn't that fundraising_code_update run composer? [20:24:12] i don't think so [20:24:31] just updates the submodule, but whatever state those are in is up to the whims of the developer [20:24:53] and the update commits are unreadable if you do more than one package at a time [20:25:09] which seems like the same problem as submodules [20:25:12] I'm getting confused - which submodule? [20:25:21] eileen: vendor [20:25:32] is a submodule on the deployment branch of the various projects [20:25:46] but that isn't a submodule in our local repos is it? where does it become a submodule [20:25:56] it's not on master [20:26:00] it's gitignored on master [20:26:08] i find this terribly confusing [20:26:56] hmm what IS in that fundraising_code_update then [20:27:09] i think it's basically git pull in all the places [20:27:24] you can look at what it does, it's perl :) [20:29:42] yeah I can see it now [20:30:08] is this why awight went on parenting leave- to avoid questions about this? [20:30:15] hehehe [20:30:18] hah [20:30:42] We messed with different ways of doing this when we first started using composer [20:30:56] and this ended up being the least painful, given our constraints [20:31:35] isn't it standard wmf practice? [20:31:43] submodule on deployment only [20:31:58] Oh, maybe it is! [20:32:19] I think we came to that independently though [20:32:47] definitely started with it on master, then got rid of it when that was too tedious [20:33:42] the submodule? [20:33:54] yeah [20:34:10] OK so the process should be.... [20:34:16] sync the composer files [20:34:26] yeah, deployment should match master [20:34:34] after checking out deployment run the composer install --no-dev [20:34:43] commit the vendor dir on deployment? [20:34:47] yep! [20:34:51] deployment has a ton of updates that haven't made it to master [20:35:16] ugh, OK, so the .lock file should match what's actually in vendor now [20:35:35] we don't actually want to deploy any updates besides phpmailer right now [20:35:44] though we should do that soon [20:36:06] oh, that's already deployed [20:36:15] but only happened on deployment [20:37:02] (PS3) Ejegg: Add support for importing campaign source, medium for CoinBase. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329647 (https://phabricator.wikimedia.org/T153791) (owner: Eileen) [20:37:04] but since we can't reasonably do composer update [20:37:20] it will be hard to get the changes back to master without losing the dev deps [20:37:58] (CR) Ejegg: [C: 2] "This works! Too bad we've been inserting it during the normalization, though, since that will always make us do another table write to up" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329647 (https://phabricator.wikimedia.org/T153791) (owner: Eileen) [20:39:02] so - the composer.json & composer.lock on deployment DO generate the vendor submodule don't they [20:39:34] eileen: i think only composer.lock [20:39:57] this is why i agree that one shouldn't check in composer.lock [20:40:14] if it is not generated from composer.json it is wrong [20:40:21] why create that opportunity for dissonance? [20:40:24] what I mean is - if you are on deployment & fun composer install —no-dev do you get the vendor unchanged? [20:40:50] ie. first check - is deployment consistent with itself? [20:40:58] eileen: yep that worked [20:41:01] cool [20:41:15] so. then if you copy those 2 files back to master & commit [20:41:27] & then run again on master without no-dev [20:41:36] you would get the 'correct' files [20:42:03] & then in theory if you put those on the deployment branch & run with —no-dev vendor should still be unchanged? [20:43:18] well, other thing i tried was composer update --no-dev on deployment [20:44:13] which makes a ton of changes to composer.lock [20:44:41] since the files don't resolve with each other it seems scary to copy both to master [20:45:02] and do updating there that hasn't been done on deployment [20:45:48] won't composer update update all the packages - we don't want that at this stage [20:46:38] we just want to get the dev packages into the composer.lock & json & confirm that even with them there the vendor dir is unchanged [20:46:48] if we run with —no-dev ? [20:46:56] I think? [20:47:06] (CR) Ejegg: "Dang, we should really be handling this the same way between queue consumers and offline importers. The queue consumers that call message_" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329650 (https://phabricator.wikimedia.org/T153791) (owner: Eileen) [20:47:11] (Merged) jenkins-bot: Add support for importing campaign source, medium for CoinBase. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329647 (https://phabricator.wikimedia.org/T153791) (owner: Eileen) [20:47:44] cwd wait, does composer.lock in deployment match versions in the vendor dir? [20:47:58] ejegg: yea [20:48:10] eileen: well won't we have to run update to get the dev deps back? [20:48:23] K, let's just copy-paste the whole non-dev part into master's composer.lock [20:48:45] cwd - not sure I thought install would do it if the json is right [20:49:45] (CR) Eileen: "So this is like the bigger change - ie. move the create out of the normalisation?" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329650 (https://phabricator.wikimedia.org/T153791) (owner: Eileen) [20:53:15] (CR) Ejegg: "The safest move now would be to have ChecksFile call message_import within a transactionalCall, so it'll roll back automatically if there'" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/329650 (https://phabricator.wikimedia.org/T153791) (owner: Eileen) [20:55:08] ejegg: what about composer.json? [20:56:28] (CR) Ejegg: [C: 2] Upstream 4.7.11 mulilingual upgrade fix which was merged after we forked our version [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/329720 (owner: Eileen) [20:56:44] cwd wait, the .json files are out of sync too? [20:56:56] that's more disturbing [20:57:29] (CR) Ejegg: [C: 2] Upstream whitespace variant [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/329721 (owner: Eileen) [20:58:23] ejegg: ah nm those are ok [20:58:41] not as bad as i thought [20:58:45] whew! [20:59:57] (PS1) Cdentinger: Pull composer changes from deployment [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/330310 [21:00:24] and once packages-dev wasn't in there the diff isn't too bad [21:01:19] (Merged) jenkins-bot: Upstream 4.7.11 mulilingual upgrade fix which was merged after we forked our version [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/329720 (owner: Eileen) [21:01:21] (Merged) jenkins-bot: Upstream whitespace variant [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/329721 (owner: Eileen) [21:01:54] oh cool, that looks sane [21:02:15] (PS2) Ejegg: Pull composer changes from deployment [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/330310 (owner: Cdentinger) [21:02:30] (CR) Ejegg: [C: 2] "Looks sane!" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/330310 (owner: Cdentinger) [21:09:36] (Merged) jenkins-bot: Pull composer changes from deployment [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/330310 (owner: Cdentinger) [21:37:30] ejegg: any reason not to merge the dev deps back into deployment? since we should be installing with --no-dev anyway [21:44:35] i would be all for not keeping .lock in the repo [21:44:50] since vendor is a submodule we already have a decoupled manual step of updating libs [21:46:34] from top SO answer: "Having it in the repository assures you that each developer is using the same versions." [21:47:37] cwd yeah, let's bring the dev deps back over into deploy's lock file [21:48:29] i think we do need the lock files as long as we're using dev-master versions of any project [21:49:10] i'm pretty sure it's advised to not use dev-master in production [21:49:51] although it would take longer to update some things, i think that's what jeff/pci wants: more scrutiny of deployed code [21:59:04] cwd did you see I figured out the why we didn't see the php-queue error in the jenkins log? [21:59:21] last comment on https://gerrit.wikimedia.org/r/329531 [21:59:29] and other fix in https://gerrit.wikimedia.org/r/330256 [21:59:50] So, we can get off dev-master for phpqueue and amazon pay sdk once we upstream those fixes [22:00:09] is that a matter of making pull requests? [22:00:32] but smashpig might be dev-master for a while longer while we push donationinterface functionality down into sp [22:00:33] whoop, meeting [22:02:31] hangouts is doing some awful new thing where it won't let me switch accounts [22:06:14] Fundraising-Backlog, MediaWiki-Vagrant: Replace upstart with systemd unit in crm::dash - https://phabricator.wikimedia.org/T154264#2905818 (ggellerman) a:cwdent [22:07:34] Fundraising-Backlog, fundraising-tech-ops: create and/or automate tools for auditing composer-installed php packages - https://phabricator.wikimedia.org/T154509#2914731 (ggellerman) p:Triage>High [22:12:13] Fundraising-Backlog: Version control Jenkins config - https://phabricator.wikimedia.org/T154208#2914753 (ggellerman) p:Triage>Normal [22:13:10] Fundraising-Backlog, fundraising-tech-ops: Version control Jenkins config - https://phabricator.wikimedia.org/T154208#2904150 (ggellerman) [22:22:30] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, Patch-For-Review, Unplanned-Sprint-Work, WMF-deploy-2017-01-03_(1.29.0-wmf.7): Fail mail on 'city is too long' - https://phabricator.wikimedia.org/T152022#2914780 (Eileenmcnaughton) Open>Resolved [22:23:44] Fundraising Dash, Fundraising Sprint Waiting for Godot, Fundraising-Backlog, Patch-For-Review: Dash: change the "Totals Earned " widget cutoff to default to $999 - https://phabricator.wikimedia.org/T152031#2914784 (Ejegg) Open>Resolved [22:23:53] Fundraising Dash, Fundraising Sprint Waiting for Godot, Fundraising-Backlog, Patch-For-Review: Top days / top hours widget - https://phabricator.wikimedia.org/T152028#2914785 (Ejegg) Open>Resolved [22:27:53] Fundraising Sprint Value Subtracting, Fundraising Sprint Waiting for Godot, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, FR-2016-17-Q2-Bugs: Move creation of contribution tracking create for offline to within the transaction loop - https://phabricator.wikimedia.org/T154528#2914791 (Eile... [23:49:35] (PS1) Eileen: Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/330330 [23:50:13] OK I have a deployment ready… https://gerrit.wikimedia.org/r/#/c/330330/ [23:50:41] I guess I should test running composer install —no-dev over it [23:55:25] well that seems ok ... [23:56:25] (CR) Eileen: [C: 2] "self-merging : merge to deployment" [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/330330 (owner: Eileen) [23:57:04] (Merged) jenkins-bot: Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/330330 (owner: Eileen) [23:59:23] nice