[00:26:55] Hey ccogdill: What are y'all going to be editing on the 6th floor? [00:27:27] I’m working on a little practice article - just fixing a citation, but then looking into some French history stuff [00:27:44] Victoria is working on an article about a Russian blogger [00:28:19] Cool. :) [00:28:19] want to join? :) [00:28:37] If I come and frown helpfully at my own lack of public-facing fundraising documentation, would that count for something? [00:29:18] Actually, a complete lack would be better. [00:29:28] There's a lot of it, and it's all wrong. [00:29:44] So... Lots of frowning. [00:33:09] Possibly even frowning at templates. [00:38:16] :( [00:38:35] Yes, just like that. [00:38:41] I am good at frowns [00:38:45] Maybe also like :/ [00:38:50] 10,000 hours in frowning [00:38:56] or even >:{ [00:39:12] Malcolm Gladwell would be like duuude [00:39:13] haha K4 this is non-WMF edits! forget about fundraising [00:39:15] I mean... [00:39:46] Awwww. [00:40:16] [frowning needed] [00:41:04] I have this theory about getting out from under my job. [00:42:01] I'd tell you here, but I just realized it's really long. [00:43:40] orly [00:44:02] Maybe I can nutshell it. [00:44:31] There are not currently enough hours in the day in order for me to create the thing that will allow there to be a sufficient number of hours in the day. [00:45:07] I try to only do off-hours work that helps me not have to do any more off-hours work. [00:46:20] yeah :( [00:48:17] Yow: https://www.mediawiki.org/wiki/Category:Fundraising#mediaviewer/File:Wikimedia.fundraising-misc.queue_handler.jpg [00:48:24] No wonder nobody wants to help us. [00:49:37] *eyes dont blink for 12 minutes but tears are running out of them* [00:50:20] *reaches for emergency beer* [00:50:39] The best thing about this diagram, is that it's supposed to explain a codebase I basically tore apart and rebuilt from the ground up, and *I don't even understand it*. [00:51:11] wowww [00:51:26] *puts beer away and grabs whiskey* [00:51:56] I think the reason I don't understand it, is that it doesn't really map to any reality I've ever been acquainted with. [00:54:20] But I'm still not really sure, and that worries me. [00:54:44] sounds like it's….not correct [00:54:57] What I really need, is a huge whiteboard and like 80 pens. [00:55:59] Possibly some early 80s techno and a case of red bull wouldn't hurt either. [00:56:01] sounds doable [00:56:17] did you look straight ahead recently? :) [00:56:22] I did. [00:56:34] you need 77 more pens [00:57:06] I've got the techno so very covered. [00:58:06] Red bull is not difficult to acquire. [01:00:24] If you come in tomorrow and I'm staring blankly at a new diagram that will fuel a series of talks for the next two years, while listening to Kraftwerk and... hovering slightly, that's what happened. [01:02:38] hehe [01:09:54] The problem with this whiteboard, is that there isn't a place from which I can take a reasonable picture of it. [01:10:29] That should be a requirement. [01:11:13] I suppose it could be wheeled out when you were ready to snap a shot [01:11:43] I can't even really... rotate. But, yeah: We could probably drag it out sideways and block all traffic to a quadrent of this room. [01:15:35] \M/ [01:20:42] Er... [01:20:58] Oh Good. Globalcollect disappeared. [01:22:39] um what [01:22:50] They're back now. [01:23:08] ha [01:23:13] That happens sometimes. [01:23:28] Hopefully it's not going to be doing that all night. [01:24:09] Sometimes it's so quick they think nobody noticed, and we get no outage report. [01:24:24] And we have to go "Hey, what happened at [whatever] UTC?" [01:24:39] ...I like them to know that we notice these things. [01:25:13] K4-713 - I'd started to feel quite excited about the possibilities of making your queuing available to others ... until I saw that diagram you just posted [01:25:22] omg, don't look at that. [01:25:49] I'll make a better one. :) [01:26:05] will it be less scary? [01:26:19] Oh yes. [01:26:20] I promise. [01:26:29] it is very pretty though! [01:27:06] I don't know.... I find semi-realistically-rendered post-it notes to be sort of... hm. What's the word? [01:27:12] Off-putting, anyway. [01:27:34] trying to pretend to be casual & friendly? [01:27:40] (the notes I mean) [01:27:56] Yes. It's almost an Uncanny Valley kind of thing. [01:29:01] :-) [01:29:50] eileen: At any rate: Hello! I've been off on vacation for what feels like somebody's lifetime. How's it going? [01:30:39] K4-713 not bad - I caught up with Tim yesterday & started to get some input / engagement from him [01:31:02] Ah, cool. I need to read more about the ground he's been covering in the last few weeks, too. [01:31:19] you mean on the test stuff? [01:31:23] Oh yes. [01:31:30] I can't wait. [01:31:51] I can't even begin to explain how much that's going to help. [01:32:00] it's pretty cool that my PRs to core now get tested before merge too [01:32:33] NB - I did work for someone else on integrating Omnipay into CiviCRM & here is my write-up on it https://civicrm.org/blogs/eileen/rethinking-payment-processing [01:34:02] * K4-713 saves the link [01:34:24] heh. "If you love a contribution set it free - if it comes back, change it to completed. " [01:34:44] yeah - I'm good at ruining classic quotes :-) [01:34:46] Did anybody explain our... orphan rectifier to you? [01:34:56] that sounds very ominous [01:35:02] haha [01:35:27] The idea was basically that we send a bunch of people off to a 3rd party workflow, and they are generally expected to come back. [01:35:31] & also - if are kids are ratbags can we fake their birth certificates & pass them in [01:35:42] (hehe) [01:36:26] For a while, though, between 1 and 5 percent of our donors weren't coming back to finish off processing, but finished payments were being recorded in nightly reconciliation files form the gateway. [01:36:34] Those we started calling "orphans". [01:37:18] Not being able to recreate the problem ourselves, I resorted to writing a thing that recorded a message in a temporary queue when they left, and we expected them to return. [01:37:31] ok [01:37:40] When they returned, a matching message would get written to the same queue, that just indicated that they came back. [01:38:07] The rectifier matched all the messages and "antimessages" (those that indicated a return) and threw them out. [01:38:13] Kind of a collider. [01:38:16] ok [01:38:41] & the ones that don't come back? [01:38:41] Then, we'd ask the gateway for the payment status for all the remaining orphans, and finish off their process if they were in a valid state. [01:38:59] right - so you obviously weren't getting an IPN either? [01:39:04] Yep. [01:39:19] Also, some processors don't do realtime messaging like that. [01:39:29] & asking the gateway is gateway dependent? ie. hopefully they have an api you can query but.... [01:39:43] yeah. That's also hugely variable. [01:40:49] so, what I've been trying to get my head around is that the hardest part of offering Global Collect up to CiviCRM (which is the main gateway not yet available) is the form building side of it [01:41:03] some of the flows are currently supported within CiviCRM [01:41:12] but, notably the iframe flow isn't [01:41:19] Yeah, the form-building is basically evil. [01:41:34] :-;-) [01:41:51] when you pass them from the gateway chooser to the payment form / Donation Interface [01:41:51] Hopefully, the need for that semi-hosted iframe business is going to go away with the rise of what one of our gateways is referring to as "Silent Post" forms. [01:42:11] silent post aka transactional redirect? [01:42:24] Yeah, it looks like that's what you were calling it in your blog post. [01:42:31] which is what Worldpay would be if you didn't interced with js & do it all in place? [01:42:48] Actually, the js drives the silent post bits. [01:43:00] Basically, it ensures that we never ever see credit card numbers on the server side. [01:43:24] yep - that's what I mean [01:43:31] That is critical to us, and probably will be unless the new PCI rules say we need to up our game to Level D or something with 3.0. [01:43:36] so transactional redirect can be done in two ways [01:43:42] either like I did in that blog [01:43:48] or like you do with world pay [01:44:10] (which I think is probably a better user experience ) [01:44:53] so, you think iFrame is enough on it's way out that it could be disregarded at this stage? iFrame & direct debit seem like the thorny ones to me [01:45:42] direct debit because from what I understand the fields are so variable & presumably any validation too - really based on Antrik's comments on my blog [01:46:04] Well... I think we're stuck with iframe madness for... probably another year, at least. [01:46:22] if iFrame does have a future I guess the problem is I don't think I fully understand what data you capture at what point with that flow [01:46:51] Hopefully the SEPA stuff will help normalize direct debit more than somewhat, but... not really even everywhere in euro territory until 2016 or something. [01:47:24] I can explain that part. [01:47:46] In order to request the iframe in the first place, we need to have all the donor data sent back to us. [01:48:01] Including, for some stupid reason, the card type they want to use. [01:48:41] We capture everything we need in the session, and send all of it off to GC and get a link to an iframe back. [01:49:12] I think that's currently done with an ajax request to ourselves. [01:49:23] ...yep [01:49:53] ah ok - I think that makes sense with what I've seen - once I choose credit card type it pops up more fields - so in the background you are storing my details to your orphan queue & returning the iframe html? [01:50:29] Mostly it comes out of the session, unless there's a problem. [01:50:41] the iframe does? [01:50:58] because it is generally the same so it's cached there? [01:51:03] Nah, the orphan queue. That only becomes relevant if they don't come back in the "normal" workflow, in realtime. [01:51:08] but it's a gc requirement to have the card type? [01:51:30] And, yes: GC requires that you supply the card type you want to use, to get their iframe content. [01:51:36] OK - so where do you store my details when I request an iFrame - presumably you are a-b tracking me at that point? [01:51:50] The iframe can't be cached: It's all dependent on the current transation. [01:51:55] ah ok [01:52:16] On our payments servers, I store your details in the session. [01:52:53] Then, as far as the servers care, it is as if you are redirected to the GC form asking for only your credit card details. [01:52:53] hmm - when you say session I'm thinking of $_SESSION - but you don't mean that do you - you mean something more queryable [01:53:01] Nope. [01:53:10] $_SESSION is ultimately correct. [01:53:39] So, at the end of your time on GC's cc form (on their servers), it sends you back to us. [01:53:41] at what points do you track my movements for checking abandon rate etc [01:54:07] When you come back, we check the session to make sure you're trying to finish off a valid transaction that you started, and actually record the information. [01:54:21] As far as movement tracking for the purposes of abandonment... [01:54:41] ...that's basically the same for every payment type. [01:55:08] Let's see... where to start. [01:55:12] We have a table, for tracking contributions. [01:55:19] It also tracks attempts. [01:55:35] It's called "contribution_tracking". [01:56:16] You get a row in contribution_tracking as soon as you hit something that exclusively lives in the donation pipeline. [01:56:26] When you move through it, that row updates. [01:57:20] OK - so as soon as I hit the donate button or the banner? [01:57:41] so, as long as I come back after my payment you can update me [01:57:44] As soon as you make a request to donate.wikimedia.org, or payments.wikimedia.org. [01:58:02] & the main ways I would do that are? [01:58:25] Banners, the sidebar, email campaigns, social media links... [01:59:05] And you don't really have to come back after your payment, as long as the gateway provides some mechanism for telling us that we got the money. [01:59:33] what about the orphans? when you query the outcome & find out they paid without returning then are you able to associate & update the tracking row [01:59:50] We just have to handle the movement of pending data on a case-by-case basis, because most processors (maddeningly) don't give any donor details in their nightly reconciliation files. [02:00:42] In the case of orphans, that's on a cron that runs on a box that has a near-identical setup to the live payments boxes. [02:00:56] OK - so your queue manager process updates the orphans using it's crystal ball? [02:01:05] So, it basically pretends it's got a live user and finishes off the transaction as if they came back, but on the command line and without any forms. [02:01:35] If the GET_STATUS api request indicates it's worth doing. [02:02:27] Re-writing things to work in a batch mode when you initially assume that you get a new environment with every request, by the way, is basically awful. [02:03:27] so, I guess with the form I guess the flows for the silent post & iFrame & js magic are essentially submit some details to your site then submit credit card details to their site & then update your site (with outcome + possible token) [02:04:19] Those kinds of tokens are sort of new to us, but that's basically accurate, yes. [02:04:37] We haven't had to record a token anywhere yet. [02:04:44] yeah - you are hitting them in Worldpay I think [02:04:50] ...but, we are going to have to start, for WP recurring. [02:04:55] yep [02:04:57] Also SEPA everything. [02:05:02] oh ok [02:05:23] But that was kind of sudden. [02:05:30] really? [02:05:33] Yeah. [02:06:36] what are the tricky parts with SEPA? [02:06:36] The other thing about the contribution_tracking table, is that the autonumber ID is used on our end to disambiguate donations. [02:07:02] & that id is treated as the invoice/ transaction id? [02:07:10] More or less. [02:07:43] ok [02:07:46] Individual payments usually get an order ID (unique to the payment processor and our account) and a contribution_tracking id for our side. [02:07:59] Sometimes the formats are not compatible. [02:08:10] ...which is why we have both. [02:08:43] Tricky parts of SEPA... [02:08:55] ...Everything about mandates is kind of fiddly. [02:09:19] Particularly the part where they're technically supposed to be on a physical piece of paper. [02:09:36] hmmm [02:09:39] (This is why we don't have SEPA Direct Debit deployed now) [02:10:31] makes sense [02:12:10] The other tricky part that we decided not to care about, was going to be all tied up in legacy recurring transactions. [02:12:28] The whole point of SEPA was to normalize everything and make it easy. [02:12:52] that sounds like a good thing.... [02:12:57] What it actually did was create a completely new way of doing direct debit that had to live alongside all the old ways, none of which matched the new one. [02:13:14] One of those "Getting worse before getting better" things. [02:13:33] ah - like when your kids learn to crawl [02:13:48] The reason to keep all the old codepaths, would be the old legacy direct debit transactions. [02:13:59] They wouldn't actually migrate to the new stuff. [02:15:21] But, it turns out we'd need a paper mandate for those as well, so everything is stuck on that. [02:16:02] :-( [02:16:40] I hate it when they change the rules. [02:18:01] oh other news - my kids wonder why there is a picture of a sticker on the computer screen. [02:18:13] because you guys gave me all those wikipedia stickers [02:18:17] Hah! [02:18:27] Cool. :) [02:18:28] so when the see the logo on the computer they think it is copying the stickers [02:20:24] K4: this has been very informative for us lurkers! [02:20:42] Yay! [02:20:51] I was hoping. [02:20:56] ejegg - yes you now know the power of stickers [02:21:03] hehehe [02:21:21] heh [02:21:41] Incidentally, I was going to use this conversation to help direct the push for good public-facing documentation I'm hoping to dig in to in the near future. [02:21:43] btw - I don't know if you you've seen this link but this is where I have been congealing the information I have been gathering [02:21:44] https://docs.google.com/document/d/1Aa-oL-y2nq1UoHvcW4vzup0fM0H8HEoYeaSAXEzVUjA/edit [02:21:50] Oooooooooo. [02:22:17] wow, nice! [02:22:44] (congealing seems like a good world for it - it has been melding into a globulous somewhat accurate mass) [02:23:01] I can relate. [02:23:17] I have my own globular mass to wrangle. [02:24:23] :-) [02:25:14] let me know if anything in there is inaccurate [02:26:59] I'm interested in talking about the form builder at some point. [02:27:21] Probably not tonight, though, as I probably should have gone home a while ago. [02:27:51] K4-713 cool - I was also going to try a follow up blog to that last one focussing on the form builder [02:28:30] Forms have moved into the seemingly odd position in our code, of being the authority on whether or not certain payment methods/localities/currencies are enabled or not. [02:28:43] It ends up making sense, but it's still vaguely maddening. [02:30:10] yeah - there is a cross-over between gateway chooser & form builder there isn't there? [02:30:17] I think so, yes. [02:30:55] In a nutshell, we keep a bunch of form metadata that outlines what forms are allowed to try to process what. [02:31:33] Kill the metadata that specifies a form for what the user is trying to do, and they get a polite error message instead of a form that lets them initiate a payment. [02:31:35] one more question - global collect isn't integrated into many apps. Is that lack demand because not many orgs are global, too tricy technically - or is it because it's hard for people to get an account? [02:31:51] That is an excellent question. [02:32:04] My first wild stab in the dark is that it's a scale thing. [02:32:26] Scale + global need. [02:33:13] Could also be that other options (paypal) are simply easier. [02:34:05] yes [02:35:56] Okay everybody: I'm going to take off for the evening. [02:36:08] g'night [02:36:24] * K4-713 waves [02:36:29] Have a good one! :) [03:48:49] (PS1) Ejegg: Transliterate non-ascii characters for Worldpay [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/155190 [03:49:01] (CR) jenkins-bot: [V: -1] Transliterate non-ascii characters for Worldpay [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/155190 (owner: Ejegg) [16:44:02] (CR) Ejegg: [C: 2] Get rid of thank-you synchronous mode [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/153415 (owner: Awight) [16:49:35] (CR) Ejegg: "Can you explain whether the "Imported checks to review" group is no longer used or if there is/will be an alternate way to tag checks?" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/153416 (owner: Awight) [16:57:01] (CR) Ejegg: [C: 2] Move HTML->plaintext conversion down to Mailer class. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/153422 (owner: Awight) [17:02:00] (CR) Ejegg: "Now needs to move the default currency fallback logic over to the adapter too, but that would probably be a good thing." [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/63823 (owner: Awight) [17:15:10] (CR) Ejegg: [C: 2] Fix totally mangled recurring code [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/154361 (owner: Awight) [17:22:23] (PS1) Ssmith: Fix widget width [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/155299 [17:22:27] (CR) jenkins-bot: [V: -1] Fix widget width [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/155299 (owner: Ssmith) [17:42:30] Jeff_Green: Good Aftermath! [17:42:48] oh hi! [17:43:05] How's it going? [17:43:11] ok! you? [17:43:18] K4-713 do you know if Adam is in today? [17:44:02] Jeff_Green: Oh, you know. Same ol' story. :) I just realized we haven't checked in (formally or otherwise), in a really long time. [17:44:15] ya, true [17:44:28] also I should mention that I'm out next week, vacation [17:47:52] Jeff_Green: Yay, vacation! [17:47:55] Good. [17:48:01] I'll try to break everything before you go. [17:48:09] pizzzacat: awight should be... there he is. [17:48:13] great [17:48:21] K4-713 where [18:22:19] ejegg: are we on the schedule for 1200 PDT? [18:22:21] yikes! [18:24:47] yep, and im afraid youll have to drive. 3 day waitinperiod for shell access. [18:25:09] sorry, be back at regular kbd in 3 min [18:25:12] no worries! [18:25:20] k, I'm gonna try to see Oliver's presentation in 5 min [18:25:25] but will be back for our deploy [18:30:00] ok, enjoy the pres [18:32:39] (CR) Ejegg: [C: 2] Add dates to banner-hiding cookies (server side) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/144991 (owner: Ejegg) [18:38:41] ejegg: rats, it's in the wrong order to see Smallivor [18:38:59] They're recording. [18:39:03] so, we're deploying AndyRussG's patches as well, right? I should update the deploy calendar fwiw [18:39:12] But then you can't stick him with weird questions. [18:39:16] K4-713: well, heckle like hell for me! [18:39:18] oh, I can update that [18:39:19] exactly :p [18:39:22] :D [18:39:26] Hi awight and K4-713 [18:39:32] AndyRussG: "morning"! [18:39:39] Hi AndyRussG. [18:39:53] Pffff ah yes it's still morning there :) [18:40:03] Though barely [18:40:09] lazy-ass programmer morning ;) [18:40:20] (works until 5pm) [18:40:27] "woke up quick / at about noon"... [18:40:52] heee [18:40:54] Here it's crazy programmer and parent trying to get act together afternoon [18:41:23] lol [18:41:26] git cherry -v origin/wmf_deploy origin/master | grep -v Localisation [18:41:29] + ab7534eceb2ea465cdf7db90e66ff5399312980d Fix banner name filter and put it in URLs [18:41:32] + baa15db00aaea21af3a1d5f2dee4f5914ae83f70 Schema change for comments on changes for logs [18:41:35] + 0ea4befef323cd7ae4f6e902a662fccc18d156be Add comments on changes, for logs and revisions [18:41:38] + 832f60bb8435c0390234216b1f381a08c00bbf82 Add dates to banner-hiding cookies (server side) [18:41:41] + 8f437b1f916cfc5e8eaba835a6d05eaec349675f Use correct field names with addExtensionUpdate [18:41:44] + a87e8063b993e531c060bb979e26cabc8ddef164 Fix @returns >> @return phpdoc [18:41:47] + e8cd2c42127457694642ebb47d2b6b94c77538a1 Use public instead of var in classes [18:41:50] looks like we should just do the merge rather than cherry-pick [18:41:56] awight: sounds good [18:41:57] Huh [18:41:57] yeah I was gonna say, the schema change correciton is important [18:42:12] Anything you wouldn't take going to ride in that way? [18:42:39] The schema change is still pending AFIK but it should be OK [18:42:44] nope, all of that is good. The two last ones are just style [18:43:04] Those the only diffs between prod and master? [18:43:05] AndyRussG: I think we run the specific sql scripts we need [18:43:12] K4- yep [18:43:15] woot [18:43:23] ...I'll shut up now. [18:43:26] K4-713: I'll definitely scrub tests/ after the merge [18:43:44] I wish we had a hook to do that. [18:43:56] Can we do the schema change? I thought someone with ops rights had to [18:44:05] Or do we have 'em? [18:45:25] awight, what exactly do you type for merge? I tried 'git merge origin/master' from the wmf_deploy branch, then when I tried to review it had me submitting 27 commits [18:46:09] or is that expected? [18:46:16] ejegg: that's not right [18:46:19] git fetch --all [18:46:30] sounds like you have a stale local "gerrit" remote [18:46:41] no, i was up to date - most of those were i18n updates [18:46:50] or l10n rather [18:46:54] ejegg: it should be one commit [18:47:20] ok, will investigate [18:49:16] AndyRussG: good question, I'm not clear on that, we should ask. I think generally the db ops just want to take a look before we run insanely expensive alter statements. [18:49:58] The schema change bug is filed: https://bugzilla.wikimedia.org/show_bug.cgi?id=69654 [18:50:16] AndyRussG: great, thx. [18:50:49] AndyRussG: well, would you rather we avoid deploying your logging patch until this is resolved? [18:51:27] AndyRussG: oh, you already got hashar's approval in CR! [18:51:27] Nah it'll be fine (famous last words) [18:51:39] Just leeme see one more patch 2 include [18:51:40] Yeah, we can run those migrations ourselves [18:51:45] Ahh woo [18:51:58] Ah no https://gerrit.wikimedia.org/r/#/c/152145/ could use ops review [18:52:08] that's... the business one [18:53:31] AndyRussG: I'm pinging some people in wikimedia-dev... [18:54:29] awight: remember 152145 needs the other to fix the hook column names [18:54:48] AndyRussG: yah that's gotten hashar's sign-off [18:55:39] awight: bah. if I try merge --ff-only origin/master it says it can't fast-forward, and if I just do the regular merge, review submits all the changes since the last deploy individually. [18:55:56] ejegg: you're definitely on origin/wmf_deploy? [18:56:06] I set up a tracking branch [18:56:21] git branch --track wmf_deploy origin/wmf_deploy [18:56:26] git checkout wmf_deploy [18:56:33] git merge origin/master [18:56:37] git review [18:57:04] (PS1) Awight: Merge remote-tracking branch 'origin/master' into HEAD [extensions/CentralNotice] (wmf_deploy) - https://gerrit.wikimedia.org/r/155315 [18:57:08] ejegg: seems fine. but it's working as expected for me ^^ [18:57:10] (CR) jenkins-bot: [V: -1] Merge remote-tracking branch 'origin/master' into HEAD [extensions/CentralNotice] (wmf_deploy) - https://gerrit.wikimedia.org/r/155315 (owner: Awight) [18:57:18] git checkout origin/wmf_deploy [18:57:22] git merge origin/master [18:57:25] git rm -r tests [18:57:28] git commit --amend [18:57:33] git review [18:58:17] maybe git checkout origin/master is subtlely different from the branch --track / checkout I did? [18:58:41] awight: Ah OK I see now :) [18:59:57] AndyRussG: pinging more in wikimedia-operations [19:00:28] awight: thanks!! [19:01:17] ejegg: I don't understand... your tracking branch fu should have worked. [19:01:58] awight: If you like I'll look to see who specifically to ping there... [19:02:30] AndyRussG: Mark Bergsma just told me to ping springle. I think. [19:03:49] awight: also, why is Jenkins trying to run tests that don't exist? [19:03:57] AndyRussG: it's not looking good for db ops review today. I missed your reply earlier, you're fine with deploying these without the schema? [19:04:11] yeah [19:04:17] ejegg: argh [19:04:27] AndyRussG: ok cool, that makes sense. [19:04:32] Just lemme find the patch that corrects the typo, that one should go in too [19:06:39] (PS2) Awight: Merge remote-tracking branch 'origin/master' into HEAD [extensions/CentralNotice] (wmf_deploy) - https://gerrit.wikimedia.org/r/155315 [19:06:47] ejegg: I think we were not removing the tests in CentralNotice until now. [19:07:58] ohh, and there's that UnitTestsList hook [19:08:22] awight: https://gerrit.wikimedia.org/r/#/c/153882/ [19:08:49] (CR) Ejegg: [C: 2] Fix a typo in code that handles an old db schema [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/153882 (owner: AndyRussG) [19:08:50] I thought it was merged, turns out it isn't [19:08:57] Ah noww it is! :) thanks ejegg [19:09:09] Yeah if we could add that in that'll be dandy [19:09:46] Of course we may scare away users who try to add comments for logs and then are frustrated that the comments aren't actually saved in some cases [19:10:06] (PS1) Awight: Merge remote-tracking branch 'origin/master' into HEAD [extensions/CentralNotice] (wmf_deploy) - https://gerrit.wikimedia.org/r/155317 [19:10:09] (Abandoned) Awight: Merge remote-tracking branch 'origin/master' into HEAD [extensions/CentralNotice] (wmf_deploy) - https://gerrit.wikimedia.org/r/155315 (owner: Awight) [19:10:10] But if it's likely the schema change will come quickly it's likely cool I think [19:10:50] AndyRussG: oof, that's a good point. Maybe we should hold off on deploying the code. [19:11:12] Yeah one thing is that it won't break the wiki. But it'll deteriorate the UX a bit [19:11:34] It's just the fundraising dept, right? [19:11:36] AndyRussG: well, displaying a feature that doesn't work is gonna be bad for the feature's acceptance [19:11:50] Heheh true [19:11:53] ejegg: no, the biggest users of CN are the community [19:11:53] We can let them know not to use it till the schema update goes through [19:11:58] Oh, ok [19:12:08] ejegg: we do have a mailing list now, to communicate with this group... [19:12:29] AndyRussG: definitely nbd to schedule another deployment for after the schema change [19:12:55] (Abandoned) Awight: Merge remote-tracking branch 'origin/master' into HEAD [extensions/CentralNotice] (wmf_deploy) - https://gerrit.wikimedia.org/r/155317 (owner: Awight) [19:13:31]