[00:24:40] Fundraising-Backlog, fundraising-tech-ops, Mail, Office-IT: Create email alias for benefactors@ - https://phabricator.wikimedia.org/T152641#2863956 (LeanneS) @eliza and @JGulingan thanks for your help gaining access. The forwarding address is set and it looks like there is just the final step of... [00:37:33] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Civi unresponsive for Engage in evenings - https://phabricator.wikimedia.org/T152786#2863985 (Eileenmcnaughton) I took a look at the scheduled jobs and could see nothing that would cause a regular slow query at this time. I also trawled through the slow... [00:40:14] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Unplanned-Sprint-Work: CRM-19752 Fix impact of financial acl code on query speed - https://phabricator.wikimedia.org/T152936#2863990 (Eileenmcnaughton) [01:04:16] (PS1) Eileen: CRM-19752 Fix slow query on contribution search. [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/326381 [02:05:53] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Dear God - please help us find another way to compile the donor list for the annual report - https://phabricator.wikimedia.org/T118822#2864029 (Eileenmcnaughton) @LeanneS we should discuss in the Civi call if this is still an issue [02:12:24] Fundraising-Backlog, fundraising-tech-ops, Mail, Office-IT: Create email alias for benefactors@ - https://phabricator.wikimedia.org/T152641#2864036 (eliza) @LeanneS - I believe this is something that @MBeat33 will have to confirm in the Admin Panel of Zendesk, but not 100% sure. I'd suggest eith... [03:46:50] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Dear God - please help us find another way to compile the donor list for the annual report - https://phabricator.wikimedia.org/T118822#1810132 (RLewis) @Eileenmcnaughton - I compiled it for this year already, but it's was a pretty slow going process. An... [05:16:33] (PS2) Eileen: Add extension with screen to do data entry on unsubscribing emails. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/323321 (https://phabricator.wikimedia.org/T147571) [11:23:51] Fundraising-Backlog, fundraising-tech-ops, Community-Liaisons, Mail, Office-IT: [politick segue] Discuss proper policy to follow for T152641 and what to do better next time - https://phabricator.wikimedia.org/T152917#2864467 (Aklapper) [14:38:12] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Civi unresponsive for Engage in evenings - https://phabricator.wikimedia.org/T152786#2864810 (Jgreen) > I'm not sure where to find slow query logs older than 24 hours - @Jgreen ? All the ./remote/* logs rotate into the archive, at indium:/a/archive/in... [16:02:36] Fundraising-Backlog, fundraising-tech-ops, Mail, Office-IT: [politick segue] Discuss proper policy to follow for T152641 and what to do better next time - https://phabricator.wikimedia.org/T152917#2865005 (Aklapper) [ Removing #community-liaisons tag as this is out of their scope ] [16:09:38] Fundraising-Backlog, fundraising-tech-ops, Mail, Office-IT: Create email alias for benefactors@ - https://phabricator.wikimedia.org/T152641#2865056 (Jgreen) Open>Invalid The task was bounced back to OIT because the account already exists and is under OIT administration. [18:00:03] fr-tech: Simon's Law: [18:00:03] Everything put together falls apart sooner or later. [18:00:03] -- discuss. [18:04:30] the-wub: hi! For T152602, maybe u could post the code you tried in the task, or in a Phabby paste? thx!!! :) [18:32:41] fr-tech I have some funky ideas for sharing our analytics code and csv's on the cluster, maybe a shared fr home dir on stat1002 [18:33:02] sorry, I guess they're not that funky [18:33:13] Just slightly mold-perfumed [18:46:01] AndyRussG: sounds interesting [18:47:09] dstrine_: what day and time did the mobile campaign start? [18:47:11] * AndyRussG checks CN admin ui, not sure if it'll show the right info [18:47:56] ejegg: for example, some code that runs standard queries for pageviews that should show CN on specific countries, and caches the result in a csv that we can all access easily [18:50:34] now, getting fancy, we could even have a teeny db that keeps track of these aggregates for us 8p [18:54:25] yeah! I meant to follow up with you about the predigested impressions db [18:54:48] I know we've each got our own hive dbs - is it easy to share those out? [18:54:59] well I think we can all see each others' [18:55:10] ah, cool [18:56:38] I bet the digested impressions would fit in a normal db [18:57:01] We could have a job that runs that daily and keeps them for a week or a month, whatever's practical [18:57:56] Sure, that makes sense. I had figured out the process for daily hive jobs once upon a time, but we ended up doing the email stats via pgehres. [18:58:07] i'll refresh my memory [18:58:43] we could combine something there about making impressions numbers public [18:59:49] k, let's see, you need a couple of .xml and .properties files for oozie [18:59:54] https://wikitech.wikimedia.org/wiki/Analytics/Cluster/Oozie [19:00:28] and an hql file with the parametrized query [19:00:42] then you can trigger it to run as soon as a new hour's worth of data is available [19:01:40] Hmmm [19:01:45] Iiiiinteresting [19:02:03] We should make a task to scope some requirements [19:02:29] I'll email you the stuff I had for an hourly donatewiki unique count rollup [19:02:49] ejegg: cool thx! :) [19:09:28] fr-tech anyone want to work through getting dash running in vagrant? [19:09:46] ejegg: yes, that sounds fun [19:10:08] cool! I'll hop in the -talk hangout [19:12:40] ejegg: AndyRussG XenoRyet cwd I just heard what hangouts sound like on awight 's computer. it's terrible. It sounds like a broken speak and spell [19:17:09] syslog flexibility: https://gerrit.wikimedia.org/r/326012 [19:17:11] ==> default: Error: Invalid parameter force at /vagrant/puppet/modules/crm/manifests/dash.pp:20 on node mediawiki-vagrant.dev [19:20:22] https://gerrit.wikimedia.org/r/326007 [19:26:35] dstrine: is that because bad speakers? [19:27:46] awight: node server.js -d -c ./settings.js [19:28:17] /vagrant/srv/fundraising-dash/logger.js:13 [19:28:17] } catch( ex ) { [19:28:17] ^^^^^ [19:32:31] (PS3) Ejegg: Support both node-syslog and modern-syslog [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/326012 (https://phabricator.wikimedia.org/T99869) [19:33:12] (PS2) Ejegg: Announce debug mode, skip DNS hackery [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/326007 [19:35:15] AndyRussG: unknown. I don't want to go near awight 's computer [19:35:31] at least this one doesn't sound like a hair dryer when it starts [19:46:22] ah hmmm [19:46:37] back in a little-ish while :) [19:57:54] awight: I am going to tidy up that unsubscribe stuff now - so I should create a gerrit repo - or just submodule to the github repo on my own github? [20:00:47] also how do I roll out a change to civicrm.settings.php? [20:02:30] eileen1: the settings file is in a local repo up on the deployment box [20:17:26] XenoRyet: want to deploy that CA form? looks like no other patches are stacked on it [20:18:57] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, FR-PayPal-ExpressCheckout, FR-Paypal, and 2 others: Make PayPal listener understand Express Checkout - https://phabricator.wikimedia.org/T130851#2148612 (Ejegg) Odd, gerrit says the patch is missing [20:19:18] I was waiting until they were ready to use it for the sake of not poking the bear, but sounds like now might be the time. [20:19:47] Yea, I'll go ahead and push it up. [20:20:38] thanks! [20:23:05] (CR) Ejegg: [C: -1] "Duplicate checks on line 181 and 185 also need updates" [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/325818 (https://phabricator.wikimedia.org/T138013) (owner: Awight) [20:24:16] eileen1: Sounded like you two had decided that a github repo made sense? Looking for that discussion... [20:25:11] k, see it in 1208 logs [20:26:29] ejegg: yeah so the thinking behind github repo is that I think this is a shareable extension [20:26:49] which means that it may get outside pull requests etc [20:27:50] right [20:28:24] ...but WMF should be the custodian [20:28:25] ? [20:28:55] eileen1: hi--we can't submodule to github cos that'll be undeployable [20:29:02] awight: ah, right! [20:29:06] sorry [20:29:24] (PS1) XenoRyet: Merge branch 'master' into deployment [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/326537 [20:29:28] I'd either * copy it all into the crm repo, or * gerrit and submodule [20:29:43] I'm happy to do either [20:29:51] I suspect submodule is more correct [20:29:57] however, the first option is probably much better, cos the current recommendation seems to be that if it's hosted in gerrit, that should be the development master [20:30:00] ah [20:30:00] well [20:30:12] (Abandoned) XenoRyet: Merge branch 'master' into deployment [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/326537 (owner: XenoRyet) [20:30:13] if you want more opinions, maybe #wikimedia-releng? [20:30:15] yeah - so the issue here will arise when people do PRs [20:30:46] right [20:30:50] ie. we are going to start to publish extensions people will want to 'improve' and managing that has some overhead [20:31:01] that makes me lean towards a straight copy into crm [20:31:53] awight: ok let's do that for now - I made some very small changes since you reviewed it [20:31:58] notably added some docs [20:32:23] nice, I'm happy to rereview if it's ready? [20:32:36] yes it is [20:32:41] Also I published it up here [20:32:42] https://civicrm.org/extensions/unsubscribe-email-data-entry-screen [20:33:03] I didn't specifically credit wmf looking at it - although the extension name does [20:34:46] As long as it has the All RIghts Reserved ;) [20:35:49] uh--eileen1 is it in Gerrit yet? Maybe I'll wait [20:36:14] awight: it is here https://gerrit.wikimedia.org/r/#/c/323321/ [20:36:20] since you looked there are 2 changes [20:36:25] ah great [20:36:27] 1) I added some docs [20:36:44] 2) I added a menu link - but it won't work without fixing something in core too :-) [20:37:10] I'll add a side menu link in drupal on live though cos that is where DS expects to see stuff like that [20:40:10] (PS1) XenoRyet: Merge branch 'master' into deployment [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/326541 [20:40:33] (CR) XenoRyet: [C: 2] Merge branch 'master' into deployment [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/326541 (owner: XenoRyet) [20:41:23] (Merged) jenkins-bot: Merge branch 'master' into deployment [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/326541 (owner: XenoRyet) [20:43:10] (PS1) XenoRyet: Update DonationInterface submodule [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/326542 [20:43:27] (CR) XenoRyet: [C: 2] Update DonationInterface submodule [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/326542 (owner: XenoRyet) [20:49:54] (Merged) jenkins-bot: Update DonationInterface submodule [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/326542 (owner: XenoRyet) [20:57:43] Fundraising-Backlog, fundraising-tech-ops, Mail, Office-IT: Create email alias for benefactors@ - https://phabricator.wikimedia.org/T152641#2866286 (DStrine) [20:57:45] Fundraising-Backlog, fundraising-tech-ops, Mail, Office-IT: [politick segue] Discuss proper policy to follow for T152641 and what to do better next time - https://phabricator.wikimedia.org/T152917#2866285 (DStrine) Open>declined [21:18:17] !log update payments-wiki from bd8012ce876db59142e28bf6f6e4a2bd549f4481 to 5b4ced90352ec2c51186f93946840af24eaef290 [21:18:29] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [21:21:27] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, FR-Adyen, Patch-For-Review, and 2 others: Adyen: setup a form for Canada - https://phabricator.wikimedia.org/T152123#2866357 (XenoRyet) This is deployed and ready for an internal test. [21:44:59] ejegg: I just pushed a change to localsettings [21:45:19] cool, will review in a sec! [21:45:21] (CR) Cdentinger: Support both node-syslog and modern-syslog (1 comment) [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/326012 (https://phabricator.wikimedia.org/T99869) (owner: Ejegg) [21:48:04] (CR) Ejegg: [C: 1] "This is really cool! Thanks for giving us an example of a modern Civi extension. Holding off +2 pending finding the right home." (1 comment) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/323321 (https://phabricator.wikimedia.org/T147571) (owner: Eileen) [22:06:40] (CR) Awight: Add extension with screen to do data entry on unsubscribing emails. (2 comments) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/323321 (https://phabricator.wikimedia.org/T147571) (owner: Eileen) [22:07:12] ejegg: What did you mean about finding the right home? [22:07:30] IMO the extension is good where it is in that patch... [22:08:29] awight: oh? [22:08:34] awight: I pushed a commit to local settings to configure prod to point to that dir for extensions - that would need to be deployed before it would be installable from there [22:09:58] ejegg: Are you still thinking about submodules/GH? [22:15:11] (CR) Awight: [C: 2] Announce debug mode, skip DNS hackery [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/326007 (owner: Ejegg) [22:16:47] (Merged) jenkins-bot: Announce debug mode, skip DNS hackery [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/326007 (owner: Ejegg) [22:17:47] awight: yeah, sorry, did we decide not to do the submodule? [22:17:55] ejegg: exactly [22:18:04] k, looks good to me then [22:18:15] We can't deploy it from GH, and if it's moved to gerrit then the CiviCRM community will have a hard with doing PRs [22:18:20] kk [22:18:32] (CR) Awight: [C: 2] "Works great!" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/323321 (https://phabricator.wikimedia.org/T147571) (owner: Eileen) [22:19:27] another item for our open source citizenship todo list... [22:20:53] ejegg: well I did put it on civicrm.org/extensions [22:21:50] eileen1: cool! [22:22:48] just maybe WMF should be able to take on the long-term job of supporting any further development and PRs [22:23:19] ejegg: yeah - I think we need to figure that out [22:23:28] because I see us doing more things like this [22:24:02] yeah, moving more of our drupal modules to civicrm extensions seems like the way to go [22:24:11] (Merged) jenkins-bot: Add extension with screen to do data entry on unsubscribing emails. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/323321 (https://phabricator.wikimedia.org/T147571) (owner: Eileen) [22:26:11] making a task to figure that out [22:28:31] cwd: I don't know if npm install --force is the right solution [22:28:59] Weren't we talking about getting the contrib libs out of the master branch? If we did that, none of the extra footwork (e.g. recurse_submodules=false) would be needed. [22:29:58] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Spike: where to host WMF CiviCRM extensions - https://phabricator.wikimedia.org/T153014#2866495 (Ejegg) [22:30:34] awight: how come? [22:30:48] awight: ah, right, we only had them in there for ease of development. vagrant is a good substitute [22:31:00] let's go ahead and rip it out of master [22:31:17] cwd: mostly for consistency with our other repos [22:32:04] do you mean for libs in general? don't know of any other node_modules dirs [22:32:04] (PS1) Awight: Parse Express Checkout charge [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/326829 (https://phabricator.wikimedia.org/T130851) [22:32:20] cwd: yeah, in that repo it's just node_modules and bower_modules [22:32:38] hmm, think we should do bower_modules too? [22:32:57] Is there a reason they should be in master? [22:33:00] you want to have submodules on deployment and gitignore on master? [22:33:12] Let's see what kind of version lockdown we can get with bower [22:33:25] cwd: IMO yeah [22:33:26] (CR) jenkins-bot: [V: -1] Parse Express Checkout charge [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/326829 (https://phabricator.wikimedia.org/T130851) (owner: Awight) [22:33:57] why not have the submodule on master? [22:34:28] Without open the holy can of worms, just to be consistent with our other repos [22:34:35] hehe [22:34:49] It's not my favorite arrangement, but it's been working well for us [22:34:56] it seems like a good opportunity to develop against the wrong thing [22:35:00] well [22:35:09] if you have version lock files checked in, you should be good [22:35:14] ejegg: awight ok so to deploy I was thinking to code the path to our extensions repo into civicrm.settings - which I would normally see as good practice - I guess the question is how to set it in people's local builds [22:35:27] awight: I don't think there are version lock files for node and bower though [22:35:29] and it makes it really unpleasant to experiment with different library versions [22:35:31] as long as you remember to manage the gitnigored stuff [22:35:56] eileen1: we have that problem in general... [22:36:09] does that mean I can ignore it for now? [22:36:10] eileen1: It's fair to just add that to the settings template in vagrant IMO [22:36:15] more or less :) [22:36:16] yeah [22:36:20] sure, sounds good [22:36:44] oho, npm-shrinkwrap.json is what we need [22:36:54] let's see if bower has something similar [22:36:55] I'm not even sure the version lock is so crucial [22:36:57] what is the downside of having the submodule on master? [22:36:57] ok - so I would like someone to confirm the civicrm.settings change & get that pushed out - so it doesn't get not checked & deployed by accident while deploying something else [22:37:18] eileen1: looking [22:42:49] cwd want me to write the dash patch getting rid of node_modules on master? [22:43:11] I'm not totally sure we want to do the same for bower, so we can do that as another step [22:43:34] (PS1) Eileen: Fix typos in unsubscribe extension [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/326832 (https://phabricator.wikimedia.org/T147571) [22:43:40] hmmm [22:43:53] what would be different about bower? [22:43:58] (CR) Ejegg: [C: 2] Fix typos in unsubscribe extension [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/326832 (https://phabricator.wikimedia.org/T147571) (owner: Eileen) [22:44:59] (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/326835 [22:45:26] cwd just want to keep some kind of control on dev library versions vs production [22:45:51] for example, when I updated c3 I had to change some CSS [22:46:45] heh, oops, looks like the bower.json file needs updating [22:46:57] (CR) Eileen: [C: 2] Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/326835 (owner: Eileen) [22:48:17] ejegg: seems like the different branches could point to different commits, but shouldn't production always basically trail development? [22:48:31] s/but// [22:50:48] (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/326837 [22:51:08] (CR) Eileen: [C: 2] Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/326837 (owner: Eileen) [22:55:40] (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/326838 [22:55:53] (CR) Eileen: [C: 2] Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/326838 (owner: Eileen) [22:56:17] (Abandoned) Eileen: Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/326835 (owner: Eileen) [22:56:23] (CR) jenkins-bot: [V: -1] Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/326837 (owner: Eileen) [22:56:27] (Abandoned) Eileen: Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/326837 (owner: Eileen) [23:00:10] go zuul go [23:03:30] had to run to the neighbor's house and take the bicycle box off her porch so her son doesn't see before xmas [23:05:02] hehe, nice elfing [23:05:09] which meant grabbing a fedex package and throwing it in my panel van and speeding off [23:05:13] hah! [23:05:14] * cwd looks out the window [23:05:21] no cops yet [23:05:33] way to supplement your income [23:06:09] so... yeah, I know for the vendor submodule we don't care 'cause we've got composer.lock [23:07:01] since we're using totally different versions of node, I guess we don't actually care about npm-shrinkwrap [23:07:18] especially since we're just doing front end work lately [23:07:37] but the different JS libraries could make things annoying [23:08:11] for example, there was a bug in c3 4.10 that busted chart click events in recent versions of chrome [23:08:36] (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/326838 (owner: Eileen) [23:08:47] and it would be a pain to have locally-unreproducable bugs for version reasons [23:10:30] ah, ok, let's just take the tildes out of bower.json [23:10:47] I don't see the version thing as such a pain, but I'm probably wrong-- [23:10:53] We develop with latest whatevers [23:11:03] If we need to reproduce a production issue, we check out the deployment branch [23:11:57] except, wouldn't it be better to not make the regression in the first place? [23:12:48] which regression? That master might have different versions? [23:14:04] Well, if I'm introducing a css change that depends on a lib update, shouldn't I indicate the lib update someplace? [23:14:19] just say in the commit message? [23:16:08] awight: yeah writing code that only works on master by virtue of the updated libs [23:17:03] hmm. Then how to know when you go to update deployment submodule that you're updating to the same version you developed on? [23:17:06] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Dear God - please help us find another way to compile the donor list for the annual report - https://phabricator.wikimedia.org/T118822#1810132 (DStrine) This task would make this much easier and expose donors who cumulatively donate enough in one year... [23:17:27] gah [23:19:03] well if it was the same submodule pointing to different commits, you could just make it work on dev and then update master [23:19:12] *update deployment [23:19:41] right, that's what we're doing now [23:20:07] for dash? [23:20:15] yah [23:20:38] i am not seeing the downside to that workflow [23:20:57] Well, we've got the one annoyance in vagrant with node_modules [23:21:21] i think i'm not clear on that [23:21:31] the nature of the annoyance [23:21:35] being different than our other repos is a problem in itself, cos the workflow is already terrible complex [23:21:48] it would be unfortunate to have to learn another special workflow just for one repo [23:21:56] *-ibly [23:22:09] how many repos are we talking about? [23:22:16] also, is this a wmf-wide practice? [23:22:31] yeah [23:22:37] aah [23:22:47] i thought "we" just mean frtech [23:22:49] (PS1) Ejegg: REVERT ON DEPLOYMENT: remove node_modules [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/326843 [23:23:20] The consistency mostly matters just within frtech, but yeah it's a style we borrowed from the rest of the org [23:24:27] k, I'm convinced. I do want to lock down the bower lib versions a bit more to compensate though [23:27:12] https://bugs.chromium.org/p/project-zero/issues/detail?id=693 [23:29:48] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: spike: list new round of common dedupe conflicts - https://phabricator.wikimedia.org/T153019#2866661 (DStrine) [23:31:36] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: add link to large donation bot emails - https://phabricator.wikimedia.org/T153020#2866675 (DStrine) [23:33:13] cwd: that's rich! > Rest assured that this will be investigated thoroughly. [23:33:43] the real virus is antivirus [23:35:21] !log civicrm updated from 85918f78b2588e4d7c94cec709f0d448fe0110f5 to 7c8536c799c6eee774027a949178d44400cff3bc [23:35:31] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [23:35:34] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Spike: Impressions abnormally low for Ireland - https://phabricator.wikimedia.org/T152650#2866729 (AndyRussG) I pulled the data for Dec. 7, and indeed, Ireland is abnormally way down... just above 50%. The... [23:38:23] Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, Fundraising Sprint Value Subtracting, Fundraising Sprint Waiting for Godot, and 3 others: Civi: restore the 'unsubscribe from spam' option to Main menu - https://phabricator.wikimedia.org/T147571#2696936 (Eileenmcnaughton... [23:42:35] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Spike: Spike: Investigate huge spike in StaleCampaignException messages since Dec 8 - https://phabricator.wikimedia.org/T152741#2866741 (awight) a:awight [23:43:16] (PS2) Ejegg: REVERT ON DEPLOYMENT: remove submodules [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/326843 [23:43:51] OK, fr-tech ^^ removes the submodules and locks down the bower versions [23:44:08] want to see if you can still make it run locally on master? [23:44:26] ejegg: Do you want to split that into two patches? unless we want to revert the bower.json on deployment? [23:44:38] awight: oops, good call [23:45:19] (PS3) Ejegg: REVERT ON DEPLOYMENT: remove submodules [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/326843 [23:46:12] (PS1) Ejegg: Lock down bower modules to deployed versions [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/326846 [23:49:10] (PS1) Ejegg: Update bootstrap-timepicker [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/326848 [23:51:16] (CR) Awight: [C: 2] REVERT ON DEPLOYMENT: remove submodules [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/326843 (owner: Ejegg) [23:51:58] (CR) Awight: [C: 2] "Nice to know we can do this!" [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/326846 (owner: Ejegg) [23:52:10] (CR) Awight: [C: 2] Update bootstrap-timepicker [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/326848 (owner: Ejegg) [23:53:04] (Merged) jenkins-bot: REVERT ON DEPLOYMENT: remove submodules [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/326843 (owner: Ejegg) [23:54:49] (Merged) jenkins-bot: Lock down bower modules to deployed versions [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/326846 (owner: Ejegg) [23:54:51] (Merged) jenkins-bot: Update bootstrap-timepicker [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/326848 (owner: Ejegg) [23:57:59] (CR) Ejegg: "Interesting! I plan to move modern-syslog out of optional deps and get rid of the try/catch as soon as we get the prod box updated. Maybe " [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/326012 (https://phabricator.wikimedia.org/T99869) (owner: Ejegg) [23:58:28] cwd is the try/catch acceptable as a temporary workaround pending dash host upgrade? ^^^ [23:59:23] fine with me [23:59:37] seems to be what people do [23:59:56] (CR) Cdentinger: [C: 2] Support both node-syslog and modern-syslog [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/326012 (https://phabricator.wikimedia.org/T99869) (owner: Ejegg)