[00:00:12] It's all just transient stuff that can be recalculated, right? Probably no reason to flush even in production? [00:00:46] 58723:M 12 Apr 11:33:15.084 * 100 changes in 300 seconds. Saving... [00:01:14] NB - the RAM in use by the end of the test was nearly a GB [00:01:27] wat [00:01:31] I think I know where a memory leak lives that is causing some of that [00:01:31] that's scary [00:02:09] yeah - to be fair the test I ran would hammer it more than anything else: Tests: 2560, Assertions: 48168, Incomplete: 489. [00:04:41] Fundraising-Backlog, fundraising-tech-ops: IP/firewall changes for PayPal audit SFTP (deadline April 13) - https://phabricator.wikimedia.org/T132413#2197678 (awight) [00:04:53] Fundraising Sprint Ghostbusting , Fundraising-Backlog, fundraising-tech-ops, Unplanned-Sprint-Work: IP/firewall changes for PayPal audit SFTP (deadline April 13) - https://phabricator.wikimedia.org/T132413#2197690 (awight) [11:38:02] Wikimedia-Fundraising, Operations, Traffic, HTTPS, Patch-For-Review: delete links.email.donate.wikimedia.org (and all other email.donate.*?) from DNS - https://phabricator.wikimedia.org/T130414#2198434 (BBlack) [11:38:06] fundraising-tech-ops, Operations, Traffic, Patch-For-Review: Decide what to do with *.donate.wikimedia.org subdomain + TLS - https://phabricator.wikimedia.org/T102827#2198433 (BBlack) [13:48:21] Fundraising-Backlog, fundraising-tech-ops, DNS, Operations, and 2 others: Updating DNS records for Major Gifts subdomain (benefactors.wikimedia.org) - https://phabricator.wikimedia.org/T130937#2151449 (BBlack) Before I merge the patch above: is all of the outbound benefactors email stopped for th... [14:08:21] Fundraising-Backlog, fundraising-tech-ops, DNS, Operations, and 2 others: Updating DNS records for Major Gifts subdomain (benefactors.wikimedia.org) - https://phabricator.wikimedia.org/T130937#2198881 (CCogdill_WMF) Yes @BBlack, you're good to go. We aren't pushing any events right now so the sys... [14:11:18] Fundraising-Backlog, fundraising-tech-ops, DNS, Operations, and 2 others: Updating DNS records for Major Gifts subdomain (benefactors.wikimedia.org) - https://phabricator.wikimedia.org/T130937#2198884 (BBlack) Open>Resolved [14:28:34] (Abandoned) Awight: Update packages [extensions/DonationInterface/vendor] - https://gerrit.wikimedia.org/r/280124 (owner: Awight) [14:34:26] cwd: how's the stink :) [14:34:59] i showered at the gym [14:35:37] * awight wafts flies away [14:35:39] and made modest progress on the bathroom. today the tile backing goes up and i think the perceived speed of progress will increase [14:36:01] ;) got the priorities straight [14:36:44] i learned my lesson about bathrooms [14:36:53] it's always fun to slither under a muddy house & disconnect the hot water. Totally Kafkaesque [14:36:59] what lesson? Don't do it? [14:37:12] pretty much. unless you are very prepared. [14:37:21] especially if you only have one bathroom [14:37:46] hehehe [14:37:55] Or, do it in the summer [14:38:35] if i would have approached this with an actual plan it might not have gone so poorly [14:38:41] ejegg|away: ccogdill: Please paste me that etherpad link when you have a chance... [14:38:59] https://etherpad.wikimedia.org/p/Fundraising_Bulk_Email_Documentation [14:39:02] there you go awight [14:39:06] but i framed in my first window in a complete panic as the rain was starting...not a recipe for success [14:39:53] cwd: I'm so bad at plumbing. The last time I tried to teach myself that stuff, I brazed all new copper everywhere, and saved the most downhill joint for last. [14:39:58] That was really hard to get out of. [14:40:19] hehe ouch. my plumbing experience is limited to the plastic stuff under sinks. [14:40:32] Turns out I could have cut the uphill pipe and put a union in when I was done. Or stuffed some white bread around the joint! [14:40:53] Instead, I had to rig up a crazy adapter to go from a friend's air compressor to one of the faucets [14:41:16] and basically hair blasted that thing until I could get a dry 5 seconds to solder [14:41:19] blargh. [14:41:25] ccogdill: Thank you! [14:41:31] oh man that's amazing [14:41:45] you couldn't turn the main water off? [14:42:08] There was a trickle... [14:42:29] damn [14:42:31] the plastic is suddenly very appealing [14:43:22] there is a $15 bag of plastic parts at home depot that is basically the "i have no idea what i'm doing" kit [14:43:33] but you can solve most household plumbing problems with it [14:43:47] ccogdill: I'm leaning towards wikitech.wmo, cos this seems like a specific WMF configuration thing. Does that sound right? [14:43:52] cwd: That's awesome! [14:43:58] I wish that existed for everything ;) [14:44:04] ya [14:44:14] I think pieces belong on both meta & wikitech [14:44:24] my pieces on meta. I’ll link to yours [14:44:28] ooh [14:44:37] you can copy over whatever you like, I guess? [14:44:57] I haven't really thought about what makes meta the appropriate venue--you have a rubric? [14:45:14] I want to have high level documentation of our email program there [14:45:23] that doesn’t currently exist but it should [14:45:34] Ah--for the community to read, that makes much sense [14:45:39] so things like remind me later should be explained there, I think [14:45:59] but yeah, maybe wikitech has the more in-depth info [14:46:16] I don’t even have a wikitech account, I believe :| [14:46:34] That works for me. Eesh, yeah I think it's an exception to SUL huh [14:46:51] yup. :( [14:47:03] hmm [14:47:21] I actually need an account [14:47:26] for something else... [14:47:35] wikitech is ldap login [14:47:39] Thanks for pointing that out! [14:47:44] oh [14:47:50] same as gerrit and phab (depending on your setup :P) [14:48:04] i log in to phab through mediawiki.org because reasons [14:48:42] I guess I don’t understand how that works [14:49:03] I don’t see a clear way to login through ldap on wikitech… it’s obvious on phab [14:49:33] ccogdill: well ldap is a whole thing...but you just need to use the same credentials [14:50:05] unless of course you also log in to phab through mediawiki.org? [14:50:36] and you don't log in to gerrit in which case...maybe you _don't_ have an ldap account? i don't know of anything else that uses it. [14:51:06] It seems to be synced with your original gmail password [14:51:15] oh yes I log in using mediawiki [14:51:45] awight: i think there is a separate ldap directory used by OIT for a few things (maybe gmail?) [14:52:22] ccogdill: try resetting your password on wikitech? [14:52:31] Actually, https://wikitech.wikimedia.org/w/index.php?title=Special:ListUsers&offset=Carpinteyrovir&username=CC&group= [14:52:39] Wikimedia-Fundraising, Operations, Traffic, HTTPS, Patch-For-Review: delete links.email.donate.wikimedia.org (and all other email.donate.*?) from DNS - https://phabricator.wikimedia.org/T130414#2198998 (Dzahn) Hi @CCogdill_WMF i'm back and you said Tuesday or Friday are good days for your s... [14:53:25] There is no user by the name "CCogdill (WMF)" [14:53:26] :( [14:53:38] doh, yep, well dzahn can probably hook you up (just saw he commented above) [14:53:44] Fundraising Sprint Ghostbusting , Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Unplanned-Sprint-Work: Document mass email components - https://phabricator.wikimedia.org/T132369#2199000 (awight) [14:54:08] okay, so it’s an ops request? [14:54:48] LDAP != OIT/corp LDAP [14:55:01] OIT/corp LDAP is what controls the @wikimedia.org google apps accounts [14:55:02] Wikimedia-Fundraising, Operations, Traffic, HTTPS, Patch-For-Review: delete links.email.donate.wikimedia.org (and all other email.donate.*?) from DNS - https://phabricator.wikimedia.org/T130414#2199003 (CCogdill_WMF) Sure @Dzahn, I can make today work. [14:55:06] I think you can use the normal Create account page? [14:55:24] wikitech hasn't required you to request an account manually for years... [14:55:24] k [14:55:42] I think maybe since back when it was called labsconsole [14:56:08] Krenair: ooh, thanks for clarifying. That explains why the passwords aren't synchronized :) [14:59:54] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, MediaWiki-extensions-DonationInterface: Check that vendor matches composer.lock during fundraising_code_update - https://phabricator.wikimedia.org/T131313#2162630 (cwdent) Is this as simple as diffing composer.lock with the one that's in vendor? FW... [15:07:06] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, MediaWiki-extensions-DonationInterface: Check that vendor matches composer.lock during fundraising_code_update - https://phabricator.wikimedia.org/T131313#2162630 (awight) >>! In T131313#2199013, @cwdent wrote: > Is this as simple as diffing compose... [15:10:09] breaking fast... [15:25:44] wow awight finally beat me to work.... unless he hasn't gone to sleep yet :) [15:26:08] cwd: sorry to hear of the trouble. I hope the rest goes well! [15:26:19] hehehe [15:26:31] I had to cheat like hell [15:26:40] dstrine: thanks! i think things are on the right track [15:26:43] Set my clocks forward (j/k) [15:28:36] cwd: I've always been afraid of tile work. Let me know your first-timer lessons when you are through! [15:29:04] will do! yeah i'm intimidated but sorta excited [15:43:52] Fundraising-Backlog, FR-Ingenico: Multiple gateway transaction IDs with the same merchant ref - https://phabricator.wikimedia.org/T131212#2199242 (cwdent) I just noticed this while researching the missing transactions but I think @MBeat33 said it didn't surprise him too much, maybe he has more context? [15:47:54] Wikimedia-Fundraising, Operations, Traffic, HTTPS, Patch-For-Review: delete links.email.donate.wikimedia.org (and all other email.donate.*?) from DNS - https://phabricator.wikimedia.org/T130414#2199292 (Dzahn) @CCogdill_WMF @bblack great, we can merge it now then it looks [15:57:28] Fundraising-Backlog, FR-Ingenico: Multiple gateway transaction IDs with the same merchant ref - https://phabricator.wikimedia.org/T131212#2199345 (MBeat33) @cwdent, I'd put these transactions in {T122730} as they were in the batch from 12/29 that didn't make it to Civi. Just to pile on, they also were so... [15:57:35] Wikimedia-Fundraising, Operations, Traffic, HTTPS, Patch-For-Review: delete links.email.donate.wikimedia.org (and all other email.donate.*?) from DNS - https://phabricator.wikimedia.org/T130414#2199348 (Dzahn) @CCogdill_WMF We have merged the config change on the DNS servers. Changes should... [15:58:05] Blocked-on-Fundraising-Tech, Wikimedia-Fundraising, Operations, Traffic, HTTPS: links.email.donate.wikimedia.org should offer HTTPS - https://phabricator.wikimedia.org/T74514#2199353 (BBlack) [15:58:09] fundraising-tech-ops, Operations, Traffic, Patch-For-Review: Decide what to do with *.donate.wikimedia.org subdomain + TLS - https://phabricator.wikimedia.org/T102827#2199352 (BBlack) [15:58:13] Wikimedia-Fundraising, Operations, Traffic, HTTPS, Patch-For-Review: delete links.email.donate.wikimedia.org (and all other email.donate.*?) from DNS - https://phabricator.wikimedia.org/T130414#2199351 (BBlack) Open>Resolved [15:58:24] fundraising-tech-ops, Operations, Traffic, Patch-For-Review: Decide what to do with *.donate.wikimedia.org subdomain + TLS - https://phabricator.wikimedia.org/T102827#1374642 (BBlack) Open>Resolved a:BBlack They're gone! [16:38:07] (PS8) Awight: [DO NOT MERGE] Calculate opt-outs using change log [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/282304 (https://phabricator.wikimedia.org/T122411) [16:48:29] ccogdill: The giant google spreadsheet is amazing. Looks totally solid, and a perfect candidate for automation, of course ;) [16:48:50] glad you like it ;) [16:48:52] also, "appx. $ for life of reccuring:" is a neat way to compare recurring with one-time [16:49:06] yeah we need to do more tests pushing recurring [16:49:20] saw some promising stuff there last year, the numbers are just so small [16:49:59] I wonder if the value of one-time donations should be prorated the same way, to compare? [16:50:21] cos drawing someone into a longer annual one-time donation regimen is worth something [16:51:06] hm, potentially [16:51:30] but you can’t say you won’t get that same longer regimen from someone whose recurring ends [16:51:55] because the avg is only 14 months, right? so most of these only last through one annual cycle [16:52:28] perhaps to compare most accurately we would value recurring annually? [16:52:45] Oh. yeah that's already perfect, then! [16:55:59] :) [17:26:10] awight: https://github.com/caseydentinger/frig/blob/master/com.py [17:27:34] Honest work! [17:28:53] seems reliable enough [17:30:26] but i'm not sure if making frig do that will help all that much, considering how vendor is set up across branches and stuff, seems like fr_code_update would be the place right? [17:31:34] I guess it will give double errors when the package is present, but at a different version [17:31:47] yeah [17:32:12] I would lean towards giving frig the responsibility for error checking the submodule [17:32:13] dstrine: one sec! [17:32:20] AndyRussG: ok thanks [17:32:34] there are no other lint functions in fr_code_update, that I can think of. [17:33:25] awight: make frig do like...submodule update -i on the deployment branch and then this check? [17:33:30] cwd vendor is actually just supposed to be for master [17:33:42] so frig is a great place to do it [17:33:55] I think it would have already, cos frig should also create the vendor lock in the first place [17:34:08] oh, make it do composer install? [17:34:19] err, update? [17:34:25] awight: oh, I think maybe we want to still control .lock manually [17:34:27] ejegg: hi! whatchu mean just for master? I thought it was only for deployment? [17:34:35] derp, that's what I meant [17:35:03] that makes sense, but maybe vendor/ is synced to composer.lock by frig? [17:35:07] I think we still want to be able to upgrade selectively [17:35:15] hehe. "composer install" [17:35:21] yeah, definitely frig could fix up vendor to match [17:35:27] ejegg: cool. like, a flag to update? [17:35:40] maybe... [17:35:59] I like having .lock checked in on master though, and frig has been only messing with deploy so far [17:36:10] hmm. that is sounding like something composer already does [17:36:23] why control .lock manually? [17:36:36] cwd so we can update certain packages and not all [17:36:38] seems like if we get it set up proper-like update shouldn't break anything [17:36:46] I'm thiniking cos composer ("manually') already does everything we want to do with that file [17:36:54] frig should just follow whatever it finds there [17:37:02] meh. that's a bunk argument [17:37:27] yeah, basically just composer install; cd vendor; git commit -m "update libs" [17:37:51] Maybe, frig should check for updates and commit them in a separate patchset? [17:38:10] cwd only problem is for the libs we're maintaining as dev-master [17:38:19] ooh, right. [17:38:20] we either have to get serious about versioning them [17:38:38] or keep control of versions in .lock [17:38:45] versioning +1 [17:38:48] and so far .lock has been less work [17:38:58] hmm [17:39:00] at least, during periods of rapid development [17:39:13] all things being equal i'd love to version it and use the tools composer provides for this [17:39:15] but "composer update" will try to update your module, right? [17:39:21] but...maybe it's a terrible headache [17:39:29] I'd like to start versioning everything we do. [17:39:33] payments, especially [17:39:45] update will update your .lock to whatever semver matches .json [17:39:48] deployments from a tag or branch head are really elegant [17:39:53] yeah, versioning is good [17:40:02] perhaps frig should do versioning. [17:40:15] Every deployment is sort of undebateably a version. [17:40:20] push a tag to gerrit with deploy date or something? [17:40:23] s/ea/a/ [17:40:28] pretty much [17:40:35] yeah that could be cool [17:40:40] but does it address teh composer thing? [17:40:48] grab extension version from the extension.json, then add a build stamp [17:41:08] oh man there is a brutal script for this on prod [17:41:08] nah, the composer issue is versioning our dependencies [17:41:19] uh no I guess that would be using frig on the libraries as well as on DI [17:41:42] like repackaging and updating packagist.org every time we tweak an audit parser lib in smashpig [17:41:47] i.e. frig could help version the libraries [17:42:01] get a load of this https://github.com/wikimedia/mediawiki-tools-release/blob/master/make-wmf-branch/MakeWmfBranch.php [17:42:05] ah, cool [17:42:13] ejegg: but we only need to version the ones we deploy, so it's not quite every patch [17:42:41] awight: we still need to indicate which version to run tests against, no? [17:42:58] cwd: that's really... codey :) [17:43:10] ejegg: eh? in the lockfile? [17:43:16] I think so, yeah [17:43:50] Especially so, cos we won't be able to skeeze by just by merging the library change before the DI change [17:43:56] so still use the lockfile in master to track lib commits? [17:44:18] oh eh hehe no, the SHA in the lockfile prevented that [17:44:18] i'm beginning to think that composer.lock is basically an admission that the whole ecosystem is broken [17:44:25] ejegg: yeah totally [17:44:32] then do a real version and check in an update to .json when we want to deploy? [17:44:35] cwd: +1 [17:44:53] hmm [17:45:24] I wouldn't want to deploy any set of dependencies that hadn't had tests run against it [17:45:53] So I'd want to do the composer update against master and make sure .lock matches between master and deploy [17:46:46] yeah if comp update changes .lock at deploy time something should explode [17:47:04] hmm--to pick a concrete library, SmashPig CI should test DI with the SP commit under examination. But DI CI should always use the stable version of the library, right? [17:47:26] even though, theoretically that's the proper workflow: comp update shouldn't break anything because semver [17:47:29] but...here we are [17:47:31] ejegg: Ah i see what you mean--local testing on the wrong version [17:48:08] awight: right, then we have to release a stable version for every change we push to review that depends on a lib change [17:48:09] ejegg: That does seem like a conclusive argument for not doing composer update from frig. [17:48:43] ejegg: Wait, explain that last thing? [17:49:09] you're hacking on php-queue, and you add some extra thing [17:49:24] The scenario is, a DI change which depends on a PHP-Queue change. So we update composer.lock as part of the DI commit... [17:49:28] following so far [17:49:35] you update .lock to point to the commit with that and check it in with a DI commit that uses the new thing [17:49:57] and when you deploy, frig does a "composer install" to sync vendor with your .lock [17:50:16] isn't this where the semver arbitration committee decides what a "breaking change" is? [17:51:10] awight: sure, it just doesn't do a composer update [17:51:34] this would only be a problem for things using dev-master right? [17:51:48] yeah, that's all I'm concerned about [17:51:57] ooh [17:52:02] unless there's a way to pin those in .json [17:52:07] couldn't we just pin all those to whatever they're at right now? [17:52:17] since everything seems to be working [17:52:28] Let's assume we switch to using tagged versions. I thought that was the context [17:53:26] oh, if we're versioning everything there's no problem [17:53:45] I don't even know if we need a flag for this in the repo's frig config. [17:53:56] We should go ahead and version everything. [17:54:06] it just looked like a pain in the butt when we were doing rapid iterations with inter-repo dependencies [17:54:16] And uh if composer.json exists and has a package name, we go ahead and upload to packagist [17:54:39] ejegg: without automation this would be grueling [17:54:45] s//has been/ [17:57:26] going to move frig to differential btw [17:57:32] or should i say [17:57:34] phrig [17:58:56] we are soon? [17:59:12] oh, moving that project there! [17:59:13] cool [18:01:33] afaik exactly zero projects have moved over in 2016 :( [18:01:59] we should move tools/ over [18:04:57] it seems like if these code review tools were built properly you could just point them at git repos, rather than re-hosting stuff [18:05:31] well at least, if i built one i like to think it'd work that way :] [18:09:28] I can't imagine what they're gaining by virusing through layers of encapsulation around the repo [18:10:27] Having a built-in git lichen to host repos makes sense, but it should be optional like you say [18:10:56] I'm still completely broken by the concept of JGit, in other words. [18:11:00] and despite the massive software endeavors, still requiring machine readable nonsense in the commit message [18:11:26] i mean it's not like there's a unique identifier you could use to refer to a commit or someting [18:11:48] This sounds like communism [18:14:55] Fundraising-Backlog, Wikimedia-Fundraising, Operations, Traffic, and 2 others: delete links.email.donate.wikimedia.org (and all other email.donate.*?) from DNS - https://phabricator.wikimedia.org/T130414#2199926 (DStrine) [18:15:06] Fundraising-Backlog, Wikimedia-Fundraising, fundraising-tech-ops, Operations, and 3 others: delete links.email.donate.wikimedia.org (and all other email.donate.*?) from DNS - https://phabricator.wikimedia.org/T130414#2135390 (DStrine) [18:18:28] Fundraising-Backlog, Wikimedia-Fundraising, fundraising-tech-ops, Operations, and 3 others: delete links.email.donate.wikimedia.org (and all other email.donate.*?) from DNS - https://phabricator.wikimedia.org/T130414#2199931 (CCogdill_WMF) p:High>Unbreak! Hi @Dzahn, I think a record was... [18:18:45] Fundraising Sprint Ghostbusting , Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Unplanned-Sprint-Work: Document mass email components - https://phabricator.wikimedia.org/T132369#2199933 (awight) [18:20:17] fundraising-tech-ops, Operations, Traffic, Patch-For-Review: Decide what to do with *.donate.wikimedia.org subdomain + TLS - https://phabricator.wikimedia.org/T102827#2199938 (Dzahn) [18:20:21] Blocked-on-Fundraising-Tech, Wikimedia-Fundraising, Operations, Traffic, HTTPS: links.email.donate.wikimedia.org should offer HTTPS - https://phabricator.wikimedia.org/T74514#2199939 (Dzahn) [18:20:25] Fundraising-Backlog, Wikimedia-Fundraising, fundraising-tech-ops, Operations, and 3 others: delete links.email.donate.wikimedia.org (and all other email.donate.*?) from DNS - https://phabricator.wikimedia.org/T130414#2199936 (Dzahn) Resolved>Open yes, checking [18:20:43] grr, why are my log triggers STILL using connection_id() ? [18:26:36] Fundraising-Backlog, Wikimedia-Fundraising, fundraising-tech-ops, Operations, and 3 others: delete links.email.donate.wikimedia.org (and all other email.donate.*?) from DNS - https://phabricator.wikimedia.org/T130414#2199957 (Dzahn) >>! In T130414#2199931, @CCogdill_WMF wrote: > Hi @Dzahn, I thi... [18:26:59] Fundraising-Backlog, Wikimedia-Fundraising, fundraising-tech-ops, Operations, and 3 others: delete links.email.donate.wikimedia.org (and all other email.donate.*?) from DNS - https://phabricator.wikimedia.org/T130414#2199962 (CCogdill_WMF) Whew, thanks so much for the quick fix! [18:27:09] dstrine the fire is out! [18:29:46] Blocked-on-Fundraising-Tech, Wikimedia-Fundraising, Operations, Traffic, HTTPS: links.email.donate.wikimedia.org should offer HTTPS - https://phabricator.wikimedia.org/T74514#2199972 (Dzahn) [18:29:50] fundraising-tech-ops, Operations, Traffic, Patch-For-Review: Decide what to do with *.donate.wikimedia.org subdomain + TLS - https://phabricator.wikimedia.org/T102827#2199971 (Dzahn) [18:29:54] Fundraising-Backlog, Wikimedia-Fundraising, fundraising-tech-ops, Operations, and 3 others: delete links.email.donate.wikimedia.org (and all other email.donate.*?) from DNS - https://phabricator.wikimedia.org/T130414#2199970 (Dzahn) Open>Resolved [18:34:07] ahh, my logging_uniqueid_date was in the wrong group [18:34:37] ccogdill: yay!! [18:36:00] https://phabricator.wikimedia.org/diffusion/1888/ [18:37:03] cwd: Great idea! Just saw your PM [18:39:13] We need irc notification... [18:51:41] (CR) Ejegg: [C: 2] CRM-18193 Make log_date optional for revert / retrieving changes where uniqueID is in play [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/282088 (owner: Eileen) [19:05:11] TIL we can use differential for code review without changing the gerrit hosting. just set up arcanist on a project and use it to push the diffs the phabricator. it will land them on gerrit. [19:05:40] ideally we eventually move stuff to phab so it controls permissions and so on, but there are baby steps [19:09:19] (CR) Ejegg: [C: 2] "nice little contained change, i see more stuff in descendent patches to make it actually optional" [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/282089 (owner: Eileen) [19:09:38] wat [19:09:55] yeah, imo we should do this and see what all the fuss is about [19:10:01] cwd: Want to make some tasks for that? [19:10:28] Did my inline comment make it through? [19:11:33] awight: on phab? [19:12:01] (CR) Ejegg: [C: 2] "wow, how were log tables even being created with that missing comma?" [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/282090 (https://phabricator.wikimedia.org/T131223) (owner: Eileen) [19:13:24] Fundraising-Backlog, Documentation: Cut redundant bloat from https://wikitech.wikimedia.org/wiki/Fundraising and move to MediaWiki.org - https://phabricator.wikimedia.org/T132490#2200280 (awight) [19:13:31] cwd: yah [19:13:51] Fundraising Sprint Ghostbusting , Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Unplanned-Sprint-Work, Patch-For-Review: Change JPMorgan Import Field Values - https://phabricator.wikimedia.org/T131802#2200293 (LeanneS) @awight I just tested a few donations and received the response belo... [19:14:16] awight: hrm i don't think so... https://phabricator.wikimedia.org/R1888:f2089c26150e84e0c3f0a3082262394cca0d118f [19:15:28] (CR) XenoRyet: [C: 2] Only scream about missing parents for negative txns [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/281478 (https://phabricator.wikimedia.org/T120430) (owner: Ejegg) [19:15:49] cwd: https://phabricator.wikimedia.org/R1888:66253a184dab3681003562e2a83c1ef1bf39d883 [19:16:01] thanks XenoRyet ! [19:16:24] No worries. Looked good, and I like the readability cleanup lumped in. [19:16:35] Hmm, I want to test that out in a sec [19:17:04] but I should take a good look at the rest of these recent merges before I deploy anything [19:17:08] awight: neat! i am lost in the UI forest still [19:17:15] well, logging isn't on in prod yet, is it? [19:17:25] anyway i have to get working on the bathroom now, ttyl! [19:17:56] ejegg: Not yet [19:18:08] cool [19:18:49] I set up a task to ignite fireworks, here: https://phabricator.wikimedia.org/T132056 [19:19:20] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, fundraising-tech-ops: Enable CiviCRM change logging on staging - https://phabricator.wikimedia.org/T118336#2200345 (awight) Open>Resolved a:awight This happened--we're iterating on it now. [19:19:22] Fundraising Sprint Bloodletting 2016, Fundraising Sprint Cat Herding, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Spike: Scope & plan work for making manual deduplicates reversible. - https://phabricator.wikimedia.org/T124089#2200348 (awight) [19:23:05] Fundraising Sprint Ghostbusting , Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Unplanned-Sprint-Work, Patch-For-Review: Change JPMorgan Import Field Values - https://phabricator.wikimedia.org/T131802#2200403 (awight) Thanks for the reminder--no, they haven't. I'll do that right now! [19:26:01] (PS1) Awight: Merge master into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/283003 [19:26:31] (CR) Awight: [C: 2] Merge master into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/283003 (owner: Awight) [19:27:45] !log update crm from a20ac4c64e195732a27d0e9cfd33f0c23f4a8d4e to 5877ee71abc21140e60934aef627003cfb2d11cc [19:27:50] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log, Master [19:29:04] Fundraising Sprint Ghostbusting , Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Unplanned-Sprint-Work, Patch-For-Review: Change JPMorgan Import Field Values - https://phabricator.wikimedia.org/T131802#2178970 (awight) Ready for another try... [19:29:37] thanks awight ! [19:30:23] of course! [19:31:05] k, let's see if I totally busted GC audit [19:32:01] /o\ [19:34:00] oh... doesn't look like that change made it into this deploy [19:34:50] Yea, looks like zuul is still chewing on it. [19:34:57] k [19:36:02] oops! ah that's why I felt undeserving of the thanks [19:36:26] heh, i'll deploy again soon [19:36:36] I wonder if I killed the zuul by submitting crm#deployment [19:37:16] It's a little bit hard to fathom why we have a button available to us which kills CI for everyone else [19:37:45] right? [19:37:55] it should at least be red [19:38:08] Submit: be that asshole [19:38:57] urp. php 5.3 fail, https://integration.wikimedia.org/ci/job/php53lint/4209/console [19:39:14] traits again [19:39:23] gotta delete that file [19:40:33] hmm, lint just shouldn't be looking at vendor [19:40:44] +1 [19:42:02] I think that's code is even written to be safe under php 5.3... One would hope, cos https://wiki.civicrm.org/confluence/display/CRMDOC/CiviCRM+PHP+Requirements [19:42:50] yeah, it's just the PSR loggerAware trait in the lib, which civi's not using [19:43:50] huh, how is DI passing lint if it's doing composer install? [19:44:06] Fundraising Sprint Ghostbusting , Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Unplanned-Sprint-Work: Document mass email components - https://phabricator.wikimedia.org/T132369#2200574 (awight) a:CCogdill_WMF [19:44:56] Fundraising Sprint Ghostbusting , Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Unplanned-Sprint-Work, FR-Ingenico: iDEAL cancel returns donor to Thank You page - https://phabricator.wikimedia.org/T131904#2182480 (awight) a:awight [19:45:12] Fundraising Sprint Ghostbusting , Fundraising-Backlog, fundraising-tech-ops, Unplanned-Sprint-Work: IP/firewall changes for PayPal audit SFTP (deadline April 13) - https://phabricator.wikimedia.org/T132413#2200578 (awight) a:Jgreen [19:45:54] Fundraising Sprint Ghostbusting , Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Unplanned-Sprint-Work, Patch-For-Review: Change JPMorgan Import Field Values - https://phabricator.wikimedia.org/T131802#2200580 (LeanneS) The import was successful! Thanks, @awight [19:48:36] Fundraising Sprint Ghostbusting , Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Unplanned-Sprint-Work, Patch-For-Review: Change JPMorgan Import Field Values - https://phabricator.wikimedia.org/T131802#2200591 (awight) Open>Resolved Great to hear! [19:54:22] Fundraising-Backlog: ALREADY SORTED INTO Q4^^^^^^^ - https://phabricator.wikimedia.org/T132497#2200599 (DStrine) [19:58:20] Fundraising Sprint Ghostbusting , Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Unplanned-Sprint-Work, FR-Ingenico: iDEAL cancel returns donor to Thank You page - https://phabricator.wikimedia.org/T131904#2200636 (awight) We're incorrectly passing a returnto param of Thank_You/... [20:00:31] Sigh, I've already run into a situation where the encapsulated staging functions are annoying. [20:00:43] what's that? [20:00:54] Searching for places we set returnto, there are now an infinite number of files I need to look through >,< [20:01:23] I mean... on the other hand, one of those places being globalcollect_gateway/IngenicoReturntoHelper.php is pretty great [20:02:31] (CR) XenoRyet: "Good call, done." (1 comment) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/282416 (https://phabricator.wikimedia.org/T130673) (owner: XenoRyet) [20:02:42] (PS2) XenoRyet: Allow clicking on payment method to submit form. [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/282416 (https://phabricator.wikimedia.org/T130673) [20:02:51] AndyRussG: awight XenoRyet eileen meeting? [20:03:29] dstrine: yea one sec [20:04:07] (Merged) jenkins-bot: Only scream about missing parents for negative txns [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/281478 (https://phabricator.wikimedia.org/T120430) (owner: Ejegg) [20:07:38] Fundraising-Backlog: Clicktracing data not matching up with donation totals - https://phabricator.wikimedia.org/T132500#2200676 (CCogdill_WMF) [20:07:50] Fundraising-Backlog: Clicktracing data not matching up with donation totals - https://phabricator.wikimedia.org/T132500#2200690 (CCogdill_WMF) p:Triage>High [20:12:04] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Store reasons for recurring donation failure - https://phabricator.wikimedia.org/T132409#2200702 (DStrine) p:Triage>Normal [20:13:07] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Store reasons for recurring donation failure - https://phabricator.wikimedia.org/T132409#2200709 (awight) [20:13:29] Fundraising-Backlog, FR-Smashpig: Add SmashPig config to settings repo - https://phabricator.wikimedia.org/T129706#2200716 (DStrine) p:Triage>Normal [20:14:10] Fundraising-Backlog, Epic: [EPIC] Apply machine learning to fraud detection - https://phabricator.wikimedia.org/T129628#2200718 (DStrine) [20:15:12] Fundraising-Backlog: Clicktracking data not matching up with donation totals - https://phabricator.wikimedia.org/T132500#2200721 (awight) [20:16:47] Fundraising-Backlog: Clicktracking data not matching up with donation totals - https://phabricator.wikimedia.org/T132500#2200676 (awight) @CCogdill_WMF Can you paste your query here? We're wondering about left joins, etc. [20:25:54] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Make "Primary" address default address to export - https://phabricator.wikimedia.org/T88446#1011881 (awight) @CaitVirtue Would you test this again? If it's still misbehaving, please give us more detailed steps to reproduce, i.e. the exact type of expo... [20:27:11] Fundraising Tech Backlog, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Patch-For-Review: Fix performance problems recording thank you emails to CiviMail records - https://phabricator.wikimedia.org/T86863#2200788 (DStrine) p:Triage>Normal [20:27:15] Fundraising-Backlog: Clicktracking data not matching up with donation totals - https://phabricator.wikimedia.org/T132500#2200791 (CCogdill_WMF) I don't think there are left joins involved, but ecom is a murky mystery to me... clicks (in pgehres): select utm_source, sum(count) from donatewiki_counts where ut... [20:29:23] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Can the CIVI import function show what rows in a file aren't imported? - https://phabricator.wikimedia.org/T88460#2200798 (awight) @LeanneS Feel free to comment here, do you think it's still useful? [20:32:20] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Add all used custom Civi fields to install scripts - https://phabricator.wikimedia.org/T131858#2200825 (Ejegg) @awight suggests a regular process that looks at the logging tables and generates a .install function for things that have been changed by adm... [20:32:30] Fundraising-Backlog: JCB card not an option for recurring donation in Japanese form - https://phabricator.wikimedia.org/T126268#2200827 (DStrine) p:Triage>Normal [20:33:32] Fundraising-Backlog: Create WMF-hosted unsubscribe page - https://phabricator.wikimedia.org/T127401#2200831 (DStrine) p:Triage>Low [20:35:58] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, § Fundraising Sprint Devo: Gateway Reconciliation Report not pulling all donations - https://phabricator.wikimedia.org/T89288#2200861 (awight) Oops--I thought this might have been resolved by the Engage work, but it was not. We still need to decide... [20:37:46] Fundraising Tech Backlog, Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Easy: Write API for campaign creation and use it to create browser test fixtures - https://phabricator.wikimedia.org/T107376#2200868 (DStrine) p:Triage>Low [20:38:56] Fundraising-Backlog: Create WMF-hosted unsubscribe page - https://phabricator.wikimedia.org/T127401#2200870 (awight) p:Low>Triage Unsetting priority, I think we need @CCogdill_WMF and @MBeat33 input here. The links in bulk emails look highly sketchy (pages04.notwikimedia.com) and would benefit from... [20:39:07] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Can the CIVI import function show what rows in a file aren't imported? - https://phabricator.wikimedia.org/T88460#2200873 (LeanneS) @awight Yes - absolutely! [20:53:21] Fundraising Sprint Ghostbusting , Fundraising-Backlog, fundraising-tech-ops, Unplanned-Sprint-Work: IP/firewall changes for PayPal audit SFTP (deadline April 13) - https://phabricator.wikimedia.org/T132413#2200947 (Jgreen) [20:53:41] Fundraising Sprint Ghostbusting , Fundraising-Backlog, fundraising-tech-ops, Unplanned-Sprint-Work: IP/firewall changes for PayPal audit SFTP (deadline April 13) - https://phabricator.wikimedia.org/T132413#2197678 (Jgreen) Open>Resolved duplicate of T128516, already done [20:56:35] Fundraising-Backlog: Create WMF-hosted unsubscribe page - https://phabricator.wikimedia.org/T127401#2200957 (CCogdill_WMF) I don't think we have any data to support user concern, and our unsubscribe rates on emails are low. I think there are probably more important priorities, unless this is fairly trivial w... [21:07:50] (PS2) Krinkle: Convert begin/commit calls to (start|end)Atomic [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/282747 (https://phabricator.wikimedia.org/T120791) (owner: Aaron Schulz) [21:08:15] (CR) Krinkle: [C: 2] Convert begin/commit calls to (start|end)Atomic [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/282747 (https://phabricator.wikimedia.org/T120791) (owner: Aaron Schulz) [21:14:15] Fundraising Tech Backlog: please do a round of activemq cleanup - https://phabricator.wikimedia.org/T131787#2201040 (Jgreen) >>! In T131787#2179454, @Ejegg wrote: > We definitely need to add more queues to the 'old message consume' job. Here's what it's currently clearing (queue name: age in days) How do w... [21:14:39] eileen: fwiw https://phabricator.wikimedia.org/diffusion/WFTO/browse/master/dedupe/ [21:15:54] awight: cool [21:19:02] (Merged) jenkins-bot: Convert begin/commit calls to (start|end)Atomic [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/282747 (https://phabricator.wikimedia.org/T120791) (owner: Aaron Schulz) [21:21:14] eileen: It's not appropriate any more--and the civi core dedupe author has much more efficient queries... but this new schema and batching is an approach we might use once we move on to the fuzzier dedupe rules [21:24:46] awight: hmmm - we'll have to see how efficient the queries seem when we run them! [21:29:15] (PS1) Eileen: Fix call to Setting.getvalue [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/283083 [21:29:42] ejegg: https://gerrit.wikimedia.org/r/#/c/283083/ [21:30:10] looking [21:30:44] aha, thanks! [21:31:22] (CR) Ejegg: [C: 2] "Thanks!" [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/283083 (owner: Eileen) [21:32:45] yeah - you were right it was incorrect! [21:33:17] heh, i'm never sure if it's just my aging, mistreated dev install [21:33:25] :-) [21:33:53] (Merged) jenkins-bot: Fix call to Setting.getvalue [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/283083 (owner: Eileen) [21:36:35] |vpn [21:43:33] awight_: know anything about the donations-gc-garbage queue? [21:43:46] * ejegg suddenly remembers documentation [21:44:23] * ejegg sees a big ? in the doc [21:44:32] source it is [21:44:41] ejegg: I think it's not being written to... [21:44:46] * awight_ actually reads doc [21:45:00] 15765 pending messages chilling there now [21:45:13] SmashPig-listener-ingenico [21:45:17] It's being written to [21:45:59] oh, looks like that's already in the list for old message consume, with a 1 day expiry [21:46:02] moving on... [21:46:07] :) [21:46:14] * awight wipes brow clear [21:57:00] Fundraising Sprint Ghostbusting , Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Unplanned-Sprint-Work: Document mass email - https://phabricator.wikimedia.org/T132369#2201274 (awight) [22:03:15] (CR) Eileen: "I think the comma broke it - I am officially confused" [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/282090 (https://phabricator.wikimedia.org/T131223) (owner: Eileen) [22:04:10] awight / K4-713 : just sent an email 'New queue settings for old message consume job' - want to take a look and let me know if the new queues are correct? [22:04:29] Sure! [22:04:41] Also, I see three old lonely amazon refunds in a 'refund' queue which I think I need to move to 'refund-notifications' [22:04:56] will also check to make sure they're not still going to the wrong place [22:05:09] ejegg: Interesting point about paypal recurring... [22:05:28] yah, I haven't had to mess with that particular thing ever [22:05:35] One question, though. What's "huge"? [22:05:58] oh, 59 thousand messages [22:07:15] oh hey, just read the other column of awight's documentation table [22:07:21] "Written to by the legacy PayPal listener, but only 20% of messages are read again." [22:10:54] 59K! [22:10:56] ejegg: That was a lifetime (over last uptime of activemq or that queue) average [22:11:13] ...actually, that's not super bad. [22:11:16] awight: looks to be about the same [22:11:25] but we definitely should expire those [22:11:28] mhm [22:11:43] There was something odd, about the pruner, last time I ran it. [22:11:53] And by "ran" I mean "modified". [22:12:13] Like, the queue names weren't just passed through as parameters. Some of them were aliased by the script to something else. [22:12:14] I think it's configured directly in the Jenkins script chunk [22:12:24] ooh [22:12:31] But I think new ones are all just taken literally. [22:12:36] But. [22:12:41] But, but, but. [22:12:44] any reason not to move the pruner queue settings into the main smashpig config as opposed to the jenkins-box-only config? [22:13:31] Hum. [22:14:41] Eh... maybe in another card? [22:15:05] (PS1) Awight: [WIP] Donors using Ingenico should always return to the resultswitcher [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/283093 [22:15:21] ok, I'll email jeff with the lines we need in the puppet-controlled file [22:15:26] ejegg: +1 [22:15:45] awight: you might need different switchers there. [22:16:04] K4-713: yeah, we'll be leaning heavily on the session contents [22:16:12] I probably did terrible things that assume credit card, deep in the depths of the deep deep deep argh [22:16:20] hehe it's all love [22:16:29] the shit still works! [22:16:35] Wat. [22:16:46] I certainly didn't write it to... work nicely. [22:16:50] wth [22:17:04] well I mean, there's a small bug I'm fixing, but it's been remarkably stable and maintenance free in there, otherwise... [22:17:15] (CR) jenkins-bot: [V: -1] [WIP] Donors using Ingenico should always return to the resultswitcher [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/283093 (owner: Awight) [22:17:18] Again, I say: Wat. [22:17:25] :p [22:17:29] oops, gotta head out for a bit! I'll email Jeff soon and update the job when I hear back [22:17:40] K4-713: were you going to reply to my email so I can forward it on? [22:19:15] Oh. I can, sure. [22:19:26] I thought there was something more official-looking. [22:22:15] oh is there [22:22:23] hmm - [22:29:27] eileen: It's entirely possible that I just made that up. [22:30:11] :-) [22:38:17] Fundraising Sprint Ghostbusting , Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Unplanned-Sprint-Work, FR-Ingenico: iDEAL cancel returns donor to Thank You page - https://phabricator.wikimedia.org/T131904#2201505 (awight) It got fun. The Ingenico result switcher needs to be me... [22:44:56] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Investigation: dedupe exact matches - https://phabricator.wikimedia.org/T132396#2196890 (Eileenmcnaughton) Adam pointed out this link https://phabricator.wikimedia.org/diffusion/WFTO/browse/master/dedupe/ [22:45:50] Fundraising-Backlog, MediaWiki-extensions-DonationInterface: Get QA attention on DonationInterface - https://phabricator.wikimedia.org/T132526#2201520 (awight) [22:47:21] (CR) AndyRussG: "Aaarg! /me splits hairs with thick skull!" (2 comments) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/254326 (https://phabricator.wikimedia.org/T111456) (owner: Krinkle) [22:48:22] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Investigation: dedupe exact matches - https://phabricator.wikimedia.org/T132396#2196890 (awight) The idea behind that tool was that it would regularly comb through limited batches of new contacts, and apply a suite of matching algorithms against what wa... [22:52:02] Fundraising Sprint Freshmaking, Fundraising Sprint Ghostbusting , Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Reassure ourselves about triggers & replication - https://phabricator.wikimedia.org/T132527#2201542 (Eileenmcnaughton) [22:52:49] Fundraising Sprint Freshmaking, Fundraising Sprint Ghostbusting , Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Reassure ourselves about triggers & replication - https://phabricator.wikimedia.org/T132527#2201542 (Eileenmcnaughton) a:Eileenmcnaughton>Jgreen Assigning to you in the ho... [22:55:13] eileen: I have finally replied to your email. Looks like you have to forward that whole thing to travel now? [23:11:05] K4-713: thanks! [23:21:05] (PS2) Awight: [WIP] Donors using Ingenico should always return to the resultswitcher [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/283093 (https://phabricator.wikimedia.org/T131904) [23:21:07] (PS1) Awight: [WIP] Ingenico uses generic response handling controller [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/283105 (https://phabricator.wikimedia.org/T131904) [23:22:54] (CR) jenkins-bot: [V: -1] [WIP] Donors using Ingenico should always return to the resultswitcher [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/283093 (https://phabricator.wikimedia.org/T131904) (owner: Awight) [23:23:57] (CR) jenkins-bot: [V: -1] [WIP] Ingenico uses generic response handling controller [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/283105 (https://phabricator.wikimedia.org/T131904) (owner: Awight) [23:35:37] Fundraising Tech Backlog, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Recurring-Donations: Move base functionality from recurring_globalcollect into recurring - https://phabricator.wikimedia.org/T107373#2201655 (awight) [23:36:37] Fundraising Tech Backlog, Fundraising-Backlog, MediaWiki-extensions-DonationInterface, FR-Paypal, Patch-For-Review: Assisted currency conversion for PayPal is broken again - https://phabricator.wikimedia.org/T98447#2201658 (awight) [23:36:55] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Recurring-Donations: Recurring Payments Reporting - https://phabricator.wikimedia.org/T90630#2201659 (awight) [23:38:33] Fundraising-Backlog, Recurring-Donations, FR-Paypal: Recurring PayPal donations not reaching Civi if subscription is older than a few years - https://phabricator.wikimedia.org/T120692#2201663 (awight) [23:47:29] Fundraising-Backlog: Create WMF-hosted unsubscribe page - https://phabricator.wikimedia.org/T127401#2201689 (awight) p:Triage>Normal [23:52:27] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Can the CIVI import function show what rows in a file aren't imported? - https://phabricator.wikimedia.org/T88460#2201726 (awight) One thing to work out here, we probably don't want to log the entire file if there are many errors. Should we fail hard a... [23:53:11] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Can the CIVI import function show what rows in a file aren't imported? - https://phabricator.wikimedia.org/T88460#2201729 (awight) ah--how about 10 contiguous erroring rows. That way long files aren't at a disadvantage. [23:55:57] awight: cwd|afk: ejegg|away: XenoRyet: dstrine-away: any thoughts/objections to me putting a CN update on the tomorrow's SWAT deploy?