[00:00:17] K! [00:10:04] AndyRussG: ejegg: fwiw, I just learned I can work tomorrow :) see you in the mines! [00:10:41] aww, we're stealing you from your family... [00:10:46] Heh the coal mines are the best for ur lungs [00:10:54] awight: yeah what ejegg said :( [00:11:07] nah I'm swapping for Friday. Don't work too hard, suckas! [00:12:11] what you don't know is tha actually my kids to all my programming for me [00:12:36] yes, I have a similar system. Sometimes I have to remove a few hundred random characters, but what's left seems to work [00:12:38] They also work the teleprompters telling me what to say during video calls [00:12:42] :) [00:12:58] It's a convincing act [00:13:17] In exchange I do their homework for them [00:15:11] AndyRussG: oops, in BannerChoiceDataProvider.php, wfGetDB( DB_SLAVE, $wikiId ), I think wikiId is actually supposed to be the third parameter. [00:15:23] the second param defaults to $groups = array() [00:16:40] awight: nice catch! [00:16:55] still scratching my head about how to test... [00:18:50] automated or smoke? [00:19:33] Yea may have to do some refactoring to unit test that bit (?) [00:19:35] either, really [00:19:42] yeah I'll get it [00:21:03] we may want to rework Special:BannerAllocations display once buckets are per-campaign-ized [00:21:43] yeah, that will definitely make sense [00:22:52] (PS4) Ejegg: WIP: start using BannerChoiceDataProvider for allocations [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172914 [00:23:18] OK, moved the new allocation calculations out of the special page [00:23:36] cool! [00:23:55] yesss [00:24:02] awight is this one in a different status than backlog? https://wikimedia.mingle.thoughtworks.com/projects/online_fundraiser/cards/2151 [00:24:32] ejegg: my only nitpick so far is the underscore vs camelCase for var names.. [00:24:47] atgo: thanks! [00:25:50] Oh yeah, the special page was all underscores but the provider has camels. Will adapt the code to its new surroundings [00:26:05] (PS5) Awight: WIP BannerChoicesResourceLoaderModule test [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172882 [00:26:37] ejegg: thx :) [00:26:37] (CR) jenkins-bot: [V: -1] WIP BannerChoicesResourceLoaderModule test [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172882 (owner: Awight) [00:27:29] ejegg: I think allocations thing is actually a separate responsibility... [00:27:47] -v: calculateAllocations [00:28:08] k, will bust it out entirely [00:28:13] yes pls [00:35:40] (PS5) Ejegg: WIP: start using BannerChoiceDataProvider for allocations [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172914 [00:39:02] (CR) Awight: WIP bannerChoiceData and bannerController.lib modules (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172299 (owner: AndyRussG) [00:40:10] (PS6) Awight: BannerChoicesResourceLoaderModule test [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172882 [00:40:34] AndyRussG: ok, not sure if I'm cheating or not, but the RL module tests pass, using wgInfrastructureWikiId = wfWikiID() [00:40:41] (CR) jenkins-bot: [V: -1] BannerChoicesResourceLoaderModule test [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172882 (owner: Awight) [00:41:19] hehe they really do pass. there's just a typo, see here: https://gerrit.wikimedia.org/r/#/c/172299/8/CentralNotice.php,unified [00:41:24] awight: sounds good enough for a unit test! Anything more would be integraiton testing, really [00:43:12] awight: bllrrg, and the var should be neither of those [00:43:26] :) [00:55:04] (CR) Awight: "An aside--let's disable Special:GlobalAllocations as part of this commit..." [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172914 (owner: Ejegg) [00:55:41] awight: disabling that sounds [00:55:46] good [00:55:56] songbirds [00:56:17] just gonna rebase on top of AndyRussG's patch that adds the chooseOnClient switch [00:57:03] ejegg: if u wait 30 seconds there's an update coming [00:57:23] cool [00:58:00] (PS9) AndyRussG: WIP bannerChoiceData and bannerController.lib modules [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172299 [00:58:10] Hmm that was 57 seconds [00:58:19] twice as long! [00:58:20] close enough! [00:58:35] * awight shows up to the test an hour late [01:00:43] just don't tear out the page about power and discourse [01:01:12] aaaargh [01:01:17] * awight drops out for the fourth time [01:03:30] nooo [01:09:21] (CR) Awight: WIP: start using BannerChoiceDataProvider for allocations (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172914 (owner: Ejegg) [01:11:12] I'm thinking the fixtures should be in json, so we can use them from QUnit... [01:11:55] separating data from logic, i love it [01:13:15] iiiiiiiinteresting [01:13:42] well. yeah cos you two are now working on parallel reimplementations of the twitchiest piece of CN [01:14:13] we just have to... make sure the new special:allocations page and client-side banner chooser are exactthefuckingly the same. [01:14:22] matching the old chooser is a bonus [01:14:24] I'm so fried [01:14:44] So we're throttling per priority level - given a 50% emergency campaign, a 50% high pri campaign, and a 100% normal pri campaign, does the normal campaign show up 0% or 25% of the time? [01:14:57] 0 [01:15:00] cool [01:15:11] thanks! [01:15:26] I'm fried and going for re-frying [01:15:28] we're not exactly throttling per level. it's more like, portions of the 100% are dished out in turn to each prio level [01:16:29] ok, makes sense. per level would be the 25% scenario [01:16:58] one more thought about how to make this sane--is one of you going to take the lead on writing the new alloc algorithm? or will u collaborate and somehow have convergent evolution? [01:17:02] either answer is fine :) [01:17:23] we can also just wait until the tests are available, then thwack at every edge case until they match :) [01:18:06] ejegg: I think I understand whatchu mean. yeah it's always "this campaign wants 50% of total allocations", not 50% of remaining [01:19:04] ejegg: I do have the tingling sensation that perhaps I should just slightly refactor BannerChooser, so it can do the job of BannerAllocationCalculator [01:19:22] We've found so many fucking bugs in the alloc code... [01:19:29] they are all guaranteed to be subtle... [01:19:44] Hmm. client alloc algorithm will choose a single banner, while server wants the percentages for each [01:20:11] but the client alloc algorithm has to construct the percentages, first [01:20:20] right, then just choose a float between 0-1 and see which one it hits [01:20:22] yeah [01:20:24] awight: ejegg is in the lead right now so for now I'm gonna review and nitpick, steal and rebrand [01:20:42] AndyRussG: don't steal it yet :D [01:21:01] OK, gonna need some severe recalibration to fix the priorities [01:21:27] ejegg: I donno if this helps, https://www.mediawiki.org/wiki/Extension:CentralNotice/Allocation_system [01:21:54] ignore "moderation by priority" [01:22:06] awight: thanks, that does help! [01:23:02] ejegg: you really could just port over BannerChooser... [01:23:20] no, we gotta kill those slots! [01:23:31] slots are the very last thing that happens. [01:23:38] Oh, let me see then [01:23:41] it takes a clean float matrix, then quantizes into another column [01:23:54] ah, might as well reuse then [01:24:43] yeah all the slots stuff is encapsulated in quantizeAllocationToSlots [01:25:14] there could just be a boolean attribute that tells it to not generate slots [01:25:33] pls note that the quantization backfeeds the rounding, and adjusts all the float allocations [01:26:17] ah, and that's how we get everything rounded to the nearest 30th [01:26:29] yup [01:26:31] yeah [01:28:51] whew, just created a filter for puppetrun static [01:31:58] (CR) Awight: WIP: start using BannerChoiceDataProvider for allocations (2 comments) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172914 (owner: Ejegg) [01:34:04] hey waitaminute. you Easterners haven't had dinner yet... [01:34:11] get outta here! [01:34:32] heh, i've snacked plenty [01:34:48] but thanks for the concern! [01:36:13] hmmm I'm multitasking on that point but counting the minutes until I can re-focus on this (soon) [01:37:12] yeah I also snack all day! [01:39:39] family excuse just arrived! [01:39:43] See you in tha morning [01:39:51] g'night! [01:40:02] afaik, any patches I have not marked WIP are fair game for CR [01:58:57] whew, back, multitasktime is over... ejegg is https://gerrit.wikimedia.org/r/#/c/172914/ still where I should continue? [01:59:08] (on the latest patchset)? [01:59:36] I'm still redoing the allocation algorithm [01:59:51] will be quite different once the priority thing is right [02:05:38] K I should just continue w/ the JS version I guess? pls let me know NEtime you think I should look at something, thx :) [02:06:55] OK. Were you just translating the bannerchooser logic into JS? [02:08:16] I was sort of doing that, but the flow is a little different due to the data structure [02:08:37] derp, i mean reusing it in php, not translating to js [02:11:20] more or less, kinda more less than more [02:13:02] hmm, guess I could flatten the ds into a banner list first, then just wholesale rip off the allocate function. [02:20:35] (PS1) Ssmith: Push working changes to github [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/172937 [02:20:37] (PS1) Ssmith: Reset form when modal is reopened [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/172938 [02:20:41] (CR) jenkins-bot: [V: -1] Push working changes to github [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/172937 (owner: Ssmith) [02:20:47] (CR) jenkins-bot: [V: -1] Reset form when modal is reopened [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/172938 (owner: Ssmith) [02:21:17] (Abandoned) Ssmith: Push working changes to github [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/172937 (owner: Ssmith) [02:28:14] ejegg: nice that you added the country logic onto the provider [02:39:51] (PS6) Ejegg: WIP: start using BannerChoiceDataProvider for allocations [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172914 [02:41:18] AndyRussG: You think that's the right place for it? I wasn't so sure [02:41:41] OK, that latest patch set just copies the BannerChooser logic [02:41:53] Ah cool :) [02:42:28] Well, it's a start. the logic should just live in one place eventaully [02:42:34] *tually [02:42:47] re: where to put stuff, really the original patch could have much more elegant OO layout [02:43:14] Though we will kill bannerchooser once the new stuff is activated, right? [02:43:44] I think for now it's acceptable to be pretty bare-bones on the OO design [02:43:55] Maaaaaybe [02:44:02] hrmmm [02:45:37] It's also used in an API [03:12:32] (PS7) Ejegg: WIP: start using BannerChoiceDataProvider for allocations [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172914 [03:12:59] OK, got BannerChooser calling the allocation calculator. [03:14:14] But there's a wonky little filter/transform function in the allocation calculator now. Maybe i'll add another class for that and the country filter [03:15:53] ehh, that would be a job for tomorrow. Have a good night! [07:42:26] (PS1) Awight: satisfy ruby lint [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172947 [07:55:33] (CR) Awight: "Looks solid." (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172914 (owner: Ejegg) [07:55:45] (PS8) Awight: WIP: start using BannerChoiceDataProvider for allocations [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172914 (owner: Ejegg) [09:12:36] (PS1) Awight: minor fixups to WIP [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172957 [09:12:38] (PS1) Awight: Tests for BannerAllocationCalculator [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172958 [09:13:13] (CR) jenkins-bot: [V: -1] Tests for BannerAllocationCalculator [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172958 (owner: Awight) [09:14:23] (CR) Awight: "I noticed some typos, but fixed them in order to debug my tests :)" (3 comments) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172914 (owner: Ejegg) [09:19:39] (PS2) Awight: Tests for BannerAllocationCalculator [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172958 [09:44:35] (CR) Hashar: [C: 1] Basic QUnit tests [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172665 (owner: Awight) [15:26:37] (PS1) Cmcmahon: QA target beta labs for Jenkins builds [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173008 [15:27:52] (CR) Zfilipin: [C: 2] QA target beta labs for Jenkins builds [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173008 (owner: Cmcmahon) [15:28:30] (Merged) jenkins-bot: QA target beta labs for Jenkins builds [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173008 (owner: Cmcmahon) [15:44:00] (PS9) Ejegg: Use BannerChoiceDataProvider in allocation display [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172914 [15:44:02] (CR) jenkins-bot: [V: -1] Use BannerChoiceDataProvider in allocation display [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172914 (owner: Ejegg) [15:57:16] morning ejegg :) [15:57:26] I felt I had to start writing stuff down: https://www.mediawiki.org/wiki/Extension:CentralNotice/Allocation_system/Notes [16:01:23] Hi AndyRussG [16:01:30] :) [16:02:21] Good to have that documented! [16:04:14] Ah thanks!! Not finished yet, sorry if I'm repeating something u already did 8p [16:04:46] Yeah I find I get lost easily in this code, and writing stuff down helps [16:05:16] Just sending you and awight an e-mail w/ some thoughts... [16:08:54] going to semi-here mode while I get breakfast... [16:57:08] Hi AndyRussG [16:57:22] CN banner cookies expire after two weeks, correct? [17:03:06] Hi Glaisher [17:03:22] Mmm which cookies exactly? [17:03:26] hidebanner [17:03:29] (there are a few) [17:03:50] Hmm lemme check... I think it depends on the reason for the hide [17:05:53] So, we are going to re-use a banner every year for an annual event instead of recreating one every year. And if a user hides a banner on 2014, will it appear next year? [17:06:41] If they click on the hide button... I think so. [17:07:10] hideBanner() specifically [17:11:23] Glaisher: yes I think two weeks. Look at $wgNoticeCookieDurations in wmf-config/CommonSettings.php, in the wikimedia-config repository [17:11:35] That's what it sayz anyway :) [17:12:06] yep [17:12:08] two weeks [17:12:09] $wgNoticeCookieDurations = array( [17:12:10] 'close' => 1209600, // 2 weeks [17:12:10] 'donate' => 21600000, // 250 days [17:12:24] it's mediawiki-config repo, not wikimedia-config. :) [17:12:37] Thanks a lot [17:16:03] ah right [17:16:06] np :) [17:16:32] Glaisher: BTW there's a chrome extension for editing cookies that you can use to test this stuff... [17:17:11] Hm. Do you know its name? [17:17:46] Glaisher: EditThisCookie https://chrome.google.com/webstore/detail/editthiscookie/fngmhnnpilhplaeedifhccceomclgfbg?hl=en [17:18:08] ah cool [17:18:11] thanks again :) [17:19:03] np! [17:36:08] Jeff_Green: lmk if/when you want to do the triggers thing, cos I want to schedule a CentralNotice deployment to take advantage of the banner downtime. [17:36:33] AndyRussG: If you had a chance to read me email... what did u think of that idea, deploying the CN noops? [17:36:53] awight: I dunno... isn't it extra work? [17:37:15] not much work, I just have to make sure we didn't break obvious things [17:37:23] Ah hmm [17:37:29] Right I see [17:37:38] the benefits it gives us, is to consolidate the risk of the actual feature deployment [17:38:15] I guess if we have to go back and change stuff once all the pieces are in place all the changes can be deployed at once later [17:38:21] I mean [17:38:27] yes [17:38:36] If when we're smoke testing the whole system and we find we have to change the earlier bits [17:38:43] We can still go back and do that [17:38:56] it could eat two hours of my time, but I was going to lose one of those hours anyway :) [17:39:12] Hummm [17:39:32] If u think it's worth it... [17:39:50] Right now I'm stuck on L190-199 of BannerChooser [17:40:04] looking... [17:40:13] trying to figure out this $scaling variable [17:40:14] AndyRussG: you are porting to js? [17:40:23] I should be [17:40:28] Or something of the sort [17:40:52] But I decided to read the code and write down my understanding of it first [17:40:55] I was head-scratching over this $scaling as well [17:41:11] Yeah WTF [17:41:16] sorry [17:41:35] okay, it's to fairly divide the allocations as we descend in priority [17:41:45] so, if an emergency banner is taking 50% of allocations, [17:41:51] Ummm looks like it has no effect actually [17:42:01] if ( $priorityTotalAllocations[$z_index] > $remainingAllocation ) { [17:42:03] two normal-prio banners that wanted to have 50% allocations will be given 25% each, instead [17:42:20] what's wrong with that? [17:42:28] Nothing, just figuring [17:42:40] that would be, $prioTotal[NORMAL] > .5 [17:42:50] and priototal[normal] would have been 1.0, in my example [17:42:52] So the first term will never be less than 1, except for low-prioiryt [17:42:54] priority [17:43:00] Ah no [17:43:02] no, it could be < 1 [17:43:04] I'm misunderstanding... [17:43:21] K sorry about that....... [17:43:23] I think this only kicks in when we use throttling [17:45:04] Somehow I was thinking we were adding the const values, bah [17:45:27] So rather, the first term wil never be greater than 1 [17:46:16] it's weird. if there are two campaigns, that number will be 2.0 [17:46:20] K I see, $scaling is just to fully use up whatever allocation is left over [17:46:35] yes, to contract or expand [17:47:22] I'm definitely in fear mode, fwiw, and adhering as closely as possible to this structure will have a soothing effect on my nerves :) [17:47:59] yea.. K I'll try not to startle you :) [17:48:27] Yea that's why I decided to take it slow and careful, as well as I am able [17:49:08] lol thanks [17:49:43] likewise! Even if we don't get this out in time, it'll be time well spent [17:51:30] awight: ok. i didn't get to run the db dump because I spent half the night and part of this AM unbreaking puppet, so let me run that now [17:51:44] Can you describe the desired behaviour of the allocations function, first without throttling, then with? [17:51:46] want to schedule the outage for like 2H from now? [17:52:13] Jeff_Green: sure. sooner the better, from my perspective. [17:52:28] awight is pestered by Greens [17:52:33] :p [17:52:59] (sorry Jeff_Green didn't mean to say you were pestering ;p ) [17:53:00] AndyRussG: I'll plan to deploy CN noops like we were discussing, but you can restrain me from it at any point. [17:53:25] ha [17:53:29] AndyRussG: don't worry, Jeff_Green's got skin like an armadillo :) [17:53:41] awight: maybe it makes sense to do in a first deploy all the noops that create new globals [17:53:55] ok [17:54:02] maybe [17:54:14] I definitely want to get that RL module... [17:54:54] AndyRussG: we'll set up the cross-db config var. [17:55:20] right [17:55:34] Have to fix that bug too [17:56:35] awight: database is dumping.... [17:59:52] awight: OK I think sending up the patch w/ the RL module makes sense... Like u said, we can be sure nothing is breaking with $wgCentralNoticeChooseBannerOnClient set to false [18:00:07] Lemme un WIP the commit message--or is there anything else there? [18:00:21] to fix in that commit, I mean [18:01:23] Jeff_Green: ok, we have a window 11:00-13:00 PST today [18:01:49] Jeff_Green: I'm starting early cos my plan is to push and test some CentralNotice things while the banners are down. [18:03:05] AndyRussG: explaining allocations... hrm. Have you seen https://www.mediawiki.org/wiki/Extension:CentralNotice/Allocation_system#Campaign_maximum_allocation [18:03:15] That's the only real trick. [18:03:49] Yeah... I keep thinking some of this calculation can be done on the server, but it cannot. Let me bury that thought. [18:04:07] awight: right... Yes I had seen it but not remembered it at the right time...thanks [18:04:49] awight: also is this section correct? https://www.mediawiki.org/wiki/Extension:CentralNotice/Allocation_system#Moderation_by_priority [18:06:32] AndyRussG: no, that was never implemented (status=rfc) [18:06:49] awight: ah right thanks! [18:07:00] awight: interwiki Db call smoak tested! [18:07:22] works following fix on that param error [18:10:53] (CR) AndyRussG: WIP bannerChoiceData and bannerController.lib modules (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172299 (owner: AndyRussG) [18:11:06] (PS10) Ejegg: Use BannerChoiceDataProvider in allocation display [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172914 [18:11:08] (CR) jenkins-bot: [V: -1] Use BannerChoiceDataProvider in allocation display [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172914 (owner: Ejegg) [18:13:26] hey awight AndyRussG - megan and jessica have been seeing CN slowness particularly around cloning/saving banners recently. Just wanted to check and see if there was some change that went out in the last few days (started this week)? [18:13:40] Hi awight [18:13:47] not yet, no! [18:14:01] sorry I meant hi atgo [18:14:08] hi :) [18:14:09] and also hi again awight [18:14:32] (I press "a" and hit tab, it autocompletes nicknames but doesn't read my mind... yet...) [18:14:52] atgo: not yet, no deploys I know of [18:15:16] Maybe we should ask ops about any strains currently on the system? [18:17:33] atgo: awight: ejegg: is 5 min a reasonable default for the memcache expiry for banner data? I think that would give us 5 minutes or 10 minutes lag following updating camapigns, depending on whether or not our RL module gets Varnish-cached [18:18:07] AndyRussG: hell yeah. That is much tighter than the current banner caching, and we can tune as needed. [18:18:19] K sounds good [18:18:27] RL will/must be :) cached [18:18:39] (PS10) AndyRussG: bannerChoiceData and bannerController.lib modules [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172299 [18:20:25] pizzzacat: hi! and thanks. https://gerrit.wikimedia.org/r/172947 [18:20:42] pizzzacat: also... if you want, https://gerrit.wikimedia.org/r/#/c/172665/ [18:22:37] (CR) Ssmith: [C: 2] satisfy ruby lint [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172947 (owner: Awight) [18:22:44] (PS1) AndyRussG: Fix interwiki DB call in BannerChoiceDataProvider [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173061 [18:22:51] ejegg: whatchu think about my UI porcelain thought for Special:BannerAlloocation? [18:23:13] I can implement that, if you agree, and yr hands are full of other things. [18:23:29] awight ok [18:23:41] i'm going to grab chow, will be back in about ~20 [18:23:51] Jeff_Green: aright [18:24:52] awight: the css would be fine, if there's no concern about doing the allocation calculations twice [18:24:59] I can do that [18:25:26] just trying to figure out why gerrit says the thing is unmergeable [18:25:30] ejegg: nah, it's a minimal resource drain [18:25:56] ejegg: I was thinking, we show the new numbers, but there's a checkbox which unhides old rows, with some background color. [18:26:31] ejegg: clicking "rebase" doesn't work? [18:27:15] no rebase button - it's based on the latest PS of AndyRussG's commit [18:27:34] it's not the latest PS... [18:27:43] isn't the Depends On row red? [18:27:58] ejegg: you can rebase manually on your machine and submit the rebased version as new patchset [18:28:07] ejegg: oh hehe he uploaded that PS 10 minutes ago, that's why [18:28:15] (PS11) Awight: Use BannerChoiceDataProvider in allocation display [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172914 (owner: Ejegg) [18:28:16] oh, gotcha [18:28:17] (CR) jenkins-bot: [V: -1] Use BannerChoiceDataProvider in allocation display [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172914 (owner: Ejegg) [18:28:30] ejegg: sorry, I clicked Rebase out of curiosity [18:28:39] same result... [18:28:43] yah... [18:29:02] ah well, I'll worry about that again when the parent is merged [18:29:14] ejegg: I'm removing Jenkins so it tries again [18:30:29] pizzzacat: u have a chance to look at the QUnit patch? [18:30:54] Oh, if I'm just using a checkbox to switch the display, I don't need to depend on that change anyway. Was only using the new global from there [18:30:58] do you have a link awight? [18:31:07] pizzzacat: https://gerrit.wikimedia.org/r/#/c/172665/ [18:31:17] fun! I can show u how to run those if you're interested. [18:33:15] (CR) Awight: [C: 2] bannerChoiceData and bannerController.lib modules (2 comments) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172299 (owner: AndyRussG) [18:33:24] weee [18:33:35] awight not sure if I'm the best/fastest for reviewing that but will get deeper in it when I've pushed this thing I'm trying to finish [18:33:48] (Merged) jenkins-bot: bannerChoiceData and bannerController.lib modules [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172299 (owner: AndyRussG) [18:33:56] ejegg: I had a thought--you could invert the display logic based on AndyRussG's global. Was that what you were just saying? [18:34:02] pizzzacat: no worries! [18:34:23] (CR) Awight: [C: 2] Fix interwiki DB call in BannerChoiceDataProvider [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173061 (owner: AndyRussG) [18:34:28] awight: Could use that for the initial state of the checkbox [18:34:34] (PS2) Awight: Fix interwiki DB call in BannerChoiceDataProvider [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173061 (owner: AndyRussG) [18:35:06] That global can vary between the consumer projects though [18:35:12] ejegg: well... I don't want to show the new allocs by default until we're actually using them [18:35:27] ejegg: wat. wait, which global now? [18:35:39] the chooseBannerOnClient global [18:35:46] I'm thinking of... yeah. [18:36:09] * awight is boggled by your correctness [18:36:28] So, just a checkbox, no reference to the global [18:36:30] * awight looks at mediawiki-config repo [18:36:58] It could vary by projects but do we ever want it to? We could just decide to have it not... [18:37:15] RL modules... switched by project... wow. So we can actually enable this thing for testwiki [18:37:16] Though maybe we will want it to... ? [18:43:58] AndyRussG: want to take a peek at origin/master and confirm whether these patches can be deployed? [18:44:17] awight: K [18:45:15] AndyRussG: just merged one more [18:46:03] ejegg: you saw my note about https://gerrit.wikimedia.org/r/#/c/172957/ ? [18:46:04] (PS1) Ssmith: Fix range values [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/173064 [18:46:15] (CR) jenkins-bot: [V: -1] Fix range values [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/173064 (owner: Ssmith) [18:46:16] awight: the last one in my log is Fix interwiki DB call in BannerChoiceDataProvider [18:46:22] on master [18:46:24] AndyRussG: yes, that sounds right [18:46:30] K [18:47:10] Testing w/ the defaults on the new globals (inc. false for choosing on the client) [18:47:29] awight: yep, saw it. Those fixes are in the last patch set [18:47:45] will submit another as soon as I get the css / checkbox in [18:48:59] ejegg: no rush! [18:49:43] ejegg: this first deploy is mostly for smoke-testing major breakage, and the Special page is less critical [18:50:34] awight: ejegg: on the lastest CN master, smoke testing I see no issuz. Global variables are default so choosing on client is false. [18:50:41] awesome. [18:50:46] OK. That last PS should be fine if you just want to deploy. It uses the global but only displays that one algorithm [18:51:00] AndyRussG: I'm thinking I'll try to set test.wikipedia.org to use the client-choice and shared db [18:51:29] The new RL module is sent in but is a no-op with it set to false, as expected [18:51:34] ejegg: ok, sure. If you can hide by css, with no checkbox, then we could reveal via browser debugger [18:51:42] eithe rway! [18:51:46] awight: won't work yet as we're still missing the actual choosing code in js [18:52:07] AndyRussG: delivering the RL will be exciting enough :) [18:52:11] OK [18:52:32] You can set it to true and actually get the banner choices too, you can see 'em in the browser debugga [18:53:03] AndyRussG: I'll do this for just test.wp [18:53:22] awight: sounds rad! [18:53:33] hehe, you Cali kids [18:54:00] rad is an old foggie word, no? [18:54:08] awight: back [18:54:16] * awight has been dated forever [18:54:29] Jeff_Green: ok, I'm ready to disable campaigns any time... [18:54:36] ok. go for it [18:55:30] !log disabling CentralNotice campaigns [18:55:36] Logged the message, Master [18:57:36] awight: we need to put payments maintenance mode too right? [18:57:56] stopping replication on db1008 [18:59:43] Jeff_Green: yep [18:59:56] Jeff_Green: ok, disabled. now I'm waiting for payments to settle down [19:00:03] awight: have you tested the schema change sql on dev_drupal? [19:00:50] Jeff_Green: no, only locally [19:00:54] the deploy slot is calling... [19:00:57] Jeff_Green: yeah, let's do that. [19:01:07] let "'s" do that :) [19:01:11] ok [19:02:04] alter table running [19:02:12] Jeff_Green: we have to abort the deploy... I just got email from ccogdill that they sent an email a second ago. [19:02:16] tage: 1 of 2 'copy to tmp table' 0.005% of stage done [19:02:37] sorry awight I didn’t realize this was happening today [19:02:38] it's been reading exactly that ^^ for almost a minute :-P [19:02:56] Jeff_Green: yeah... it's never a good time to screw with contribution_tracking :( [19:03:06]