[01:21:56] Hey awight :) [01:22:05] Nice work with those test fixtures! [01:22:49] AndyRussG: hi! I was just gonna say, I'm taking a look at the qunit branch, hopefully I can get most of those lights green again. Or mark the non-passing ones "skipped". [01:23:08] Too bad the fixtures had to be loaded via ajax, huh... [01:23:35] Hmmm [01:24:06] "will fix later" :) [01:24:47] yeah for now a few corners may be rounded ;) [01:25:07] it's prettier that way :p [01:25:36] but ah please let me know if there's anything I should focus on improving first [01:25:46] I confess I haven't gotten to qunit much yet... was figuring out how to run the PHP tests locally (I wasn't used to running with the --group) option [01:25:53] yep [01:26:02] php tests/phpunit/phpunit.php --group CentralNotice [01:26:10] sounds like you got that far :) [01:26:17] yep! [01:26:22] they passed [01:26:23] ? [01:26:25] yep! [01:26:32] this one could use a kick: https://gerrit.wikimedia.org/r/#/c/172882/ [01:26:39] On that one right now! [01:26:44] WRT to the FIXME [01:26:47] ah [01:27:27] could you set wgNoticeProject temporarily? [01:29:25] looking [01:29:30] That's the only issue I see so far... [01:30:49] Line 61 reference to wgCentralNoticeInfrastructureId will need updating since I merged your patch correcting my mindless oversight [01:31:04] Thanks, I have no idea why I couldn't figure out the project thing! [01:31:50] AndyRussG: oh, not mindless at all. I had to ask ^d and other people about the wikiId thing, to confirm the obvious :) [01:32:30] There's sooo much stuff in mw-core that needs to be documented still... [01:32:36] np... Well after analysing carefully some of the logic in CNDatabase, I have now idea why I didn't even read, or remember, the other relevant lines [01:32:46] me too! [01:32:56] that's what pressure does... [01:33:52] On that note, I swear up and down the code freeze date is not a random application of pressure thing! [01:35:02] Yeah I understand that... [01:35:19] thanks 4 saying so tho [01:35:40] I really hate that crap and would ferret it out so fast. [01:36:30] * AndyRussG imagines a ferret chomping up code and deadlines [01:36:38] Also [01:36:42] yes [01:36:56] * AndyRussG doesn't like the underscode method _getChoices [01:37:18] just a nitpick/preference, I'd sooner go for getChoicesForTesting [01:37:54] ooh. Sorry, I was too lazy to apply this wacky access control thing: https://gerrit.wikimedia.org/r/#/c/171490/2/tests/engines/LuaCommon/TitleLibraryTest.php,unified [01:38:03] cos I'm already in trouble about that [01:38:11] ok sure, that rename WFM [01:40:03] Maybe also a comment explaining that it's to make the protected method accessible? figueroutable but easier w/ a comment, sorry also for such scouring for nits [01:40:03] (PS10) Awight: Test CNBannerChoicesResourceLoaderModule [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172882 [01:40:10] +1 [01:40:36] (CR) jenkins-bot: [V: -1] Test CNBannerChoicesResourceLoaderModule [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172882 (owner: Awight) [01:40:40] oops [01:41:07] wat [01:41:45] ah, that other thing you said [01:42:21] Ah yea [01:45:08] (PS11) Awight: Test CNBannerChoicesResourceLoaderModule [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172882 [01:47:23] Ah a couple other questions... [01:47:32] Looking at this https://www.mediawiki.org/wiki/Extension:CentralNotice#Overriding_selection [01:47:48] ok [01:48:31] Basically those are all params that the new version should be supporting, I guess? [01:48:43] other than random=, these are already implemented (and often used) functionality [01:49:26] so... yah. You can probably reuse most of the stuff, like weird regex that parses the GET params into mw.cn.getVars [01:49:44] Ah yeah I was planning on using that for random= actually [01:49:46] Where is the "force" param impelemented? [01:49:51] mmm [01:50:09] I think there's some of it in the bannerController, and some in the banner hide code? looking now [01:50:25] argh. nope, it's all in banners [01:50:44] Humm, just in every actual banner? [01:50:49] or most? [01:50:53] yeah. feel free to not fix that. [01:51:08] Hmm OK I much appreciate that luxury :) [01:51:24] And reset? [01:51:27] I think u get most of this functionality for free, if you only rewrite the loadRandomBanner function? [01:51:39] reset is also in banners... lemme link that fyi [01:51:58] for example: https://meta.wikimedia.org/wiki/MediaWiki:CentralNotice/Resources/BannerShowHideCountDate.js [01:52:59] sorry if I'm trying to pervert your excellent rewrite with street-fighting style, btw :) [01:53:38] heh sorry I'm derailing your fast reflexes with my excessive plodding 8p [01:54:17] Yeah I've seen stuff under MediaWiki:CentralNotice/Resources/ before... [01:54:21] hehe, maybe when Katie's back, my job can be something other than just reconciling major change with boring stability :p [01:55:29] they can be quantum states so it can be change and stability at the same time, until you look to see which one it really is [01:55:56] uh... Those are basically all scripts that banners include for kicks? I guess one has to look at the specific banners... [01:56:04] I think I know which state that will be... hehe I prefer not to open the box [01:56:32] good kitty [01:56:51] heheh houdini cat escaped [01:57:04] * AndyRussG looks at some banners [01:58:36] AndyRussG: yes here's an example banner, http://meta.wikimedia.org/wiki/MediaWiki:Centralnotice-template-Wpapp2014Androidmobile_1 [01:58:48] omg don't look there [01:58:59] that's a random copy pasta of the same code [01:59:13] oh god it's horrible out there [01:59:15] Was looking at this one https://meta.wikimedia.org/w/index.php?title=Special:CentralNoticeBanners/edit/B14_1112_13_frFR_mob_clng&template=B14_1112_13_frFR_mob_clng [01:59:45] For a good time, you can search metawiki with the MediaWiki namespace enabled: http://meta.wikimedia.org/w/index.php?title=Special%3ASearch&profile=advanced&search=BannerShowHide&fulltext=Search&ns0=1&ns8=1&ns12=1&ns200=1&ns202=1&ns866=1&profile=advanced [01:59:48] yikes [02:00:17] Yep. I would recommend even, not fixing this issue :) [02:00:59] k so I'll just ignore reset and force... [02:01:20] wait, no what if they rely on some aspect of bannerController that we're gonna change? [02:01:48] we probably are. But not in this rollout? [02:02:07] Is it possible to limit the action to just loadRandomBanner? [02:02:17] Maybe [02:02:20] I'll try to change the outward-facing API as little as possible [02:02:59] but that's the thing--we don't even know which internals are being abused, out there [02:03:17] Yeah... well, there should be some way to check. [02:03:29] Not easily, but some way or another... [02:03:34] :) seeing if we can pull the tablecloth out really fast [02:03:50] CGI [02:03:55] eh? [02:04:08] http://en.wikipedia.org/wiki/Computer-generated_imagery [02:04:16] ! [02:04:35] Mmm on the topic crazy JS [02:04:47] I was looking at Mixins again quickly... [02:05:00] yes [02:05:13] http://www.mediawiki.org/wiki/Extension:CentralNotice/Banner_mixins [02:05:15] they haven't been used yet, but I'm ready to do that any day [02:05:30] this was my solution to the proliferation of unreviewed JS [02:05:34] Yeah! [02:05:44] and pluggable arch for supporting PHP libs [02:06:05] heh banner diet composer [02:06:19] but it is not being used in practice, so no worries wrt this deployment [02:06:24] Hmm OK [02:06:52] The "preload rule" mentioned there--still something that comes in with the banner, right? I mean, it's not the same as JS that we've been talking about for sending in before the banner choice is made, right? [02:07:27] it's the future alternative to that junk [02:07:44] OK [02:07:45] We can verify it's not being used, btw, by searching the prod db [02:07:54] But I mean, as it's currently implemented [02:08:06] It's not something that goes to the client before the banner is requested... or is it? [02:08:09] however, lots of banners *are* using the insane alterImpressionData hooks, in two distinct ways AFAICT [02:08:24] no, it's inlined with the banner payload [02:08:42] it's actually js that runs as part of the JSONP response from BannerLoader [02:09:26] Ah OK interseting [02:09:27] got it [02:10:19] K maybe we should have QUnit tests on alterImpressionData then, though I don't think much around tht will be modified in this go [02:10:32] ahh sure [02:10:39] K :) [02:11:32] Thinking more about these tests, I guess the only other detail on my mind is to make sure that the fixtures cover all the wonky varieties of mix-and-matcheable criteria [02:11:36] Or at least a lot of them [02:11:46] fyi, I'm keeping test status tracked at https://wikimedia.mingle.thoughtworks.com/projects/online_fundraiser/cards/2136 [02:11:49] feel free to comment there [02:11:50] Looking over 'em quickly it looked like they were quite thorough [02:12:02] agreed that we need many more fixtures [02:12:19] I was... considering recruiting ejegg to expand that later this week, if he's interested [02:12:22] +1 nice mingle card! [02:12:45] K sounds fun [02:12:47] don't tell anyone I can actually do a good job, they'll start expecting it [02:15:29] ?? what if they force it out of me? or... just look at everything you do... [02:15:55] * awight mangles revision history [02:17:13] K besides https://gerrit.wikimedia.org/r/#/c/172882/, any others I should try to kick along this evening? [02:17:28] https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions/CentralNotice,n,z [02:17:29] Mmm, any QUnit kicking u want to do would be great [02:17:45] K [02:44:28] gotta do family + packing for a minute [02:55:04] blrgg, silly Eclipse sometimes just won't update my view after a git change [02:55:17] yikes! [02:55:20] nice inotify [02:57:28] I guess you can't blame a huge Java app for going bezerk after a week of uptime... eventually it probably just grows to hate life [02:57:49] It should have the right to end its own process [03:00:12] yeah well I assisted it since it was clearly in pain [03:02:20] man those tests do perform some heavy lifting! [03:04:30] (CR) AndyRussG: [C: 2] "Most excellent! :)" [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172882 (owner: Awight) [03:05:02] (Merged) jenkins-bot: Test CNBannerChoicesResourceLoaderModule [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172882 (owner: Awight) [03:05:20] sleight of hand. [03:33:47] (CR) Awight: "recheck" [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172665 (owner: Awight) [03:34:53] (CR) Awight: "recheck" [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173662 (owner: Awight) [03:37:33] awight: should we care about removing useless params in the query to load a testing banner (bannerController.js, loadTestingBanner()) ? [03:37:48] like what? [03:37:53] oh [03:38:01] bannerPageQuery = { [03:38:01] title: 'Special:BannerLoader', [03:38:01] banner: bannerName, [03:38:01] campaign: campaign, [03:38:01] uselang: mw.config.get( 'wgUserLanguage' ), [03:38:02] I don't think it matters [03:38:03] db: mw.config.get( 'wgDBname' ), [03:38:05] project: mw.config.get( 'wgNoticeProject' ), [03:38:07] country: mw.centralNotice.data.country, [03:38:09] device: mw.centralNotice.data.device, [03:38:11] debug: mw.centralNotice.data.getVars.debug [03:38:14] }; [03:38:20] they're included for analytics [03:38:24] I just thought it might put a dent in our imploding of the cache, but I guess not much [03:38:36] But... analytics wants to know about testing views? [03:38:39] ohh good point, yes we should remove them [03:38:49] ok reading your question now :) [03:38:54] for testing, it doesn't matter [03:39:07] but for the real thing, yeah we should only send the necessary params, cos: cache [03:39:17] Yeah that's clear [03:39:35] testing doesn't happen often enuf to affect the cache, afaict [03:40:25] K I'm gonna still remove 'em for testing too because pine-scented floor bleach [03:40:31] sure! [03:40:41] I'm just getting pummeled by qunit btw [03:40:43] argh [03:40:48] Hmmm :( [03:40:52] sorry to hear that [03:40:57] don't mind my occasional yelp [03:41:27] I think the GeoIP ajax call is still being issued, but only on the production CI server [03:41:34] cannot reproduce it locally [03:41:45] hmmmm [03:42:07] on real production it gets injected via http cookie setting [03:42:38] could synthesize the geoip cookie in the test setup, no? [03:44:32] oooh I see my typo, now. [03:44:52] (PS2) Awight: Implement banner= override test [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173662 [03:47:20] Why is wgDBname ever sent by bannerController to get the banner? [03:47:20] ka-ching! [03:47:26] mmm [03:47:51] because the request is from a dbname-branded bits.wmo URL, to meta, which doesn't know what project u were on [03:48:03] but there is some weird duplication between project and dbname. [03:48:15] please do clean that up... later :p [03:48:47] there's a reason we left it... escaping me right now, but I think there's some server-side code that is written for one, and some written for the other param. [03:49:29] (PS2) Awight: Implement random= override test [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173663 [03:50:03] (CR) jenkins-bot: [V: -1] Implement random= override test [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173663 (owner: Awight) [03:50:08] (PS3) Awight: Implement random= override test [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173663 [03:50:39] (CR) jenkins-bot: [V: -1] Implement random= override test [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173663 (owner: Awight) [03:50:45] (PS10) Awight: WIP QUnit tests for client banner allocations [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173249 [03:51:55] (CR) jenkins-bot: [V: -1] WIP QUnit tests for client banner allocations [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173249 (owner: Awight) [03:52:40] (PS11) Awight: WIP QUnit tests for client banner allocations [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173249 [03:53:11] well has to be cleaned to do away with the cache explosion [03:53:13] AndyRussG: ok this new head is the best we have for qunit testing the new code ^^ [03:53:30] 173249? K got it! [03:53:41] AndyRussG: it's harmless for now, afaik, cos dbname and project/language are 1-1 [03:53:51] (CR) jenkins-bot: [V: -1] WIP QUnit tests for client banner allocations [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173249 (owner: Awight) [03:53:53] yep, 7372a3abfdf39ed4 [03:54:03] It _does_ know what project ur on 'cause it gets project in there too [03:54:12] I know... [03:54:17] but it won't get project now, just the banner name, no? [03:54:50] We need to pass country and language because the banner actually will render differently on those [03:55:05] I think everything else can be omitted [03:55:40] M... we should check with Ellery maybe, before eliminating the extra params [03:56:06] currently, that's the only data we'll have to verify that our new allocations match the expectations [03:56:09] :( [03:56:33] No. [03:56:36] sorry [03:56:43] Only RecordImpression needs those params [03:57:10] And, we should really be telling Varnish to serve '' without hitting PHP. later [03:57:19] >_< [03:57:34] Hmm? telling varnish to serve '' ? [03:57:52] I'll document removed/added params in the commit message [03:57:54] Currently, we hit the PHP implementation of Special:RecordImpression, which returns zero bytes [03:58:03] sort of a despicable waste [03:58:04] Yeah I was thinking about banner rendering differences... [03:58:17] Aaaah right got it [03:59:51] Speaking of low-hanging fruit, anytime we get bored there's also the lack of indexes on the cn_assignments table... [04:00:51] oof [04:00:51] yeah [04:01:21] Which affects actual code paths. [04:01:31] I'll make a card for that [04:01:49] (also made one for the Varnish RecordImpression thing, just now) [04:02:28] How does that affect code paths? [04:03:10] Don't we query cn_assignments for every banner request? [04:03:26] Yes [04:03:33] yeah getCampaignBanners [04:03:36] eughh [04:03:38] But the code shouldn't change when we add indexes [04:03:40] Just get faster [04:04:12] yep! I meant, it's not just used in the admin UI [04:04:17] Ah yes [04:04:30] It's all, MySQL doing a bunch of internal greps right now, on the assumption that there would never be more than 10 campaigns [04:04:41] yes. row scan hell [04:05:13] We probably scan the historical stuff which is already filtered out. I don't have the heart to look :) [04:08:10] What about all these params and the unreviewed morass of banner JS code? So you're saying country and language have to remain on the request to banner loader? [04:08:47] Do banners ever look at device, and if so, where exactly do they git it from? [04:08:57] oooh I hope not [04:09:48] ya know... only language is necessary [04:10:14] I just realized, if banner code is peeking at any other environment, it's doing so from javascript which does not vary on anything before it is served. [04:10:48] oof. campaign name is also needed [04:11:02] I'm reading special/SpecialBannerLoader.php as it calls BannerRenderer [04:11:36] banners have this stupid legacy thing where they substitute {{{campaign}}} as part of a top-level CSS class. [04:11:49] <_< [04:11:49] Aaaah OK [04:11:50] >_> [04:11:55] I'm sure there's a reason for it ;) [04:12:12] Happily, that won't explode cache [04:12:20] yeah [04:12:27] Really just by getting rid of slots we're doing a lot [04:12:44] slots & country [04:12:46] Eventually should be testing the on-wiki JS uf course [04:12:59] * awight sharpens axe [04:13:18] I am pretty sure I heard of some community banner varying by country [04:13:42] I think fundraising banners do that--but only *after* they're loaded [04:13:50] But I don't know exactly where they're pulling the info from. If it's from some JS variable that's already in there due to RL or some other standard always-on mechanism, that's OK [04:13:58] I hadn't figured that out until... a few seconds ago when u made me talk it out [04:14:16] there's no such variable in the response... [04:14:31] The doozies would be.... something that is added server-side when the banner is rendered [04:14:46] we don't have that [04:14:58] and if somehow the banner JS were to have access to the params that were used on the request to fetch it, which I think it doesn't [04:15:04] it can't [04:15:17] K yeah I think that's the case for the latter [04:15:28] sorry, what [04:15:53] I mean, I think you're right, the banner JS can't get to the params of the request used to fetch it [04:16:04] luckily! [04:16:14] But regarding the former doozie, i.e. something added server-side, where is {{{campaign}}} getting there from? [04:17:08] AndyRussG: peek at BannerRenderer::ctor [04:17:50] whew, that's a rabbithole [04:17:53] K [04:18:10] but I'm still feeling unreasonably confident that we only need (language, campaign) [04:18:16] newly confident :) [04:21:19] Hmmm sounds good [04:21:34] (still let's aim for the middle ground betwix fear and confidence) [04:33:33] (CR) Ejegg: [C: 2] Basic QUnit tests [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/172665 (owner: Awight) [04:33:44] ! [04:33:58] whoa.... [04:34:30] you bats. [04:34:36] philae lander back from hibernation! [04:34:44] reboot twice! [04:35:08] hehe I totally read that article thinking I would learn something interesting about robust software design. [04:35:16] "reboot again" was a pretty good LOL [04:36:20] * AndyRussG scratches head about inadvertent use of obscure references [04:37:09] Or did you mean reboot twice? [04:37:51] it was just a great punchline, if your software is crappy and it really has to work... make it so you can reboot [04:39:41] ah cool [04:59:58] AndyRussG: I'm getting some "allocation": NaN, fyi [05:00:21] probably bad fixture data, ignore me 4 a minute :) [05:00:53] Ah hmm! Could be a bug, lemee know if you find it relevant and have data :) [05:03:04] bad fixtures! [05:03:36] Hmmm OK--something that can't ever exist on the system then= [05:03:36] ? [05:03:52] yeah it would be garbage into setChoiceData [05:04:00] Ah hmmm [05:04:18] Mmm one thing is that it's assuming things are the correct data type [05:04:25] as sent in via json [05:05:15] If u want to take a quick look at how the provider is spitting it out you can play w/ the API, i.e. api.php?action=centralnoticebannerchoicedata&project=subscribing&language=fr&status=loggedin and the like [05:05:19] I was missing some of the campaign attributes. IMO it's not worthwhile to bake in distrust of the resource loader data module [05:05:26] awesome [05:05:42] K agreed [05:06:03] I mean, the main source of possible confusion is when we assume something's coming in as a number not a string [05:06:50] * awight emits squeaks [05:15:10] I wonder... if we could replicate meta's CN tables and Mediawiki: namespace on a test instance... [05:15:23] we could at least fiddle around with real banners and campaigns in a safe environ [05:15:24] we should. [05:16:14] I wonder... would that be hard? [05:16:44] I should have filed that request weeks ago for replicated CN tables on labs... [05:41:58] (CR) Ejegg: [C: 2] Implement banner= override test (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173662 (owner: Awight) [05:43:10] (CR) Awight: Implement banner= override test (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173662 (owner: Awight) [05:50:38] awight: should we continue to use $wgCentralBannerDispatcher and assume it'll point to Special:BannerRandom? [05:50:48] Or just hardcode Special:LoadBanner? [05:51:22] hrm [05:51:26] Hmmm I think I'll stick w/ BannerRandom and add in a TODO [05:51:43] less moving parts = more likelyhood of getting it right [05:51:45] that works [05:51:50] :) [05:51:58] a bit sleazy but I like it :) [05:52:37] We could change $wgCentralBannerDispatcher to point to Special:SleazePlease [05:53:58] ejegg's all code-reviewing on a 16-baud modem in a snowstorm that can't handle IRC and ssh at the same time--he's missing the party! [05:54:53] I almost emailed a poke about that, but it felt too hypocritical :D [05:55:15] I figure he's not long for this day, anyway [05:55:32] Mmm the healthy option [05:55:42] the only real rule around here is, no deploying w/o being in IRC [05:55:54] I did that once... [05:56:07] ahh hmmmm [05:57:59] Didja see this? [05:57:59] // If we have a logged in user; do not cache (default for special pages) [05:57:59] // lest we capture a set-cookie header. Otherwise cache so we don't have [05:57:59] // too big of a DDoS hole. [05:58:13] From SpecialBannerRandom L41 [05:58:34] Capture... set-cookie... processing [05:58:52] right [05:59:19] I wonder if we can just clear response cookies instead? [05:59:47] Don't we want to cache a bit, even for everyone? [05:59:51] I guess it's a card [06:00:33] Yeah we sure do [06:00:43] Don't know if there's some reason we can't control the set-cookie? [06:09:02] Blarg why can't I find where to add a new card not in the current sprint? I must be dumb, or spoiled by the slick CN admin UI... [06:11:51] baahaha [06:11:56] I think it's the default [06:12:05] there's this stupid button at the bottom [06:12:10] bottom left [06:12:12] it's well disguised [06:12:54] oh yeah, cryptic "Add card"! [06:13:30] ah they did fix the icon. It used to be this red and white rectangle... [06:13:50] universal language for "ugly css version of an index card with a colored post-it on one side" [06:14:20] Hmm sounds fitting, actually [06:15:23] I'm especially bitter, last night I tried to create four cards in four different tabs [06:15:34] There was session spillover like hell [06:15:45] ufff [06:15:48] and I deleted 2 (or 3?) while I was writing them, by simply hitting [06:15:52] unrecoverable [06:16:09] I'm a bit -happy due to vi [06:16:25] oh yeah that esc can really get you [06:17:29] I think I have useful qunit allocations tests now... [06:17:39] woo! \o/ [06:18:02] just debugging the first mismatch to see who's redhanding the monkey wrench [06:20:09] I guess it's a good thing we're adding tests... [06:20:20] ok it's test fail again :) [06:28:50] passing! [06:30:21] cool! [06:30:25] (PS12) Awight: QUnit tests for client banner allocations [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173249 [06:31:02] (PS13) Awight: QUnit tests for client banner allocations [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173249 [06:31:04] (PS4) Awight: Implement random= override test [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173663 [06:32:14] (CR) jenkins-bot: [V: -1] QUnit tests for client banner allocations [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173249 (owner: Awight) [06:32:15] the branch head is the random= test now, but you can just rebase on top of https://gerrit.wikimedia.org/r/173249 still [06:32:17] (CR) jenkins-bot: [V: -1] Implement random= override test [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/173663 (owner: Awight) [06:32:39] Hmmm [06:32:40] K [06:33:43] I did that cos the allocations tests pass, so you can stabilize that feature first, without worrying about random= [06:33:56] Ah OK [06:34:17] you could also rebase on top of the random= patch, if you want to live on the bloody edge [06:34:29] yeah that sounds good [06:34:43] so no bugs in the feature itself so far I guess? [06:34:53] nope! [06:35:00] weee! [06:35:07] K I'll work hard to get a few in there [06:37:04] It might make sense to merge your WIP bannercontroller.lib and the qunit tests, so we have a known good checkpoint... [06:37:12] up to you, of course! [06:37:50] Close to having it actually work but maybe also lemme know what's best on your end? [06:38:45] no preference. I've never worked like this before, with different people on tests + feature [06:39:10] I'm sort of baffled, and will ask QA gurus for advice tomorrow [06:39:27] hmmm [06:39:41] I was gonna say nothing's blown up yet, but that'd be slighly false [06:40:00] I want the lights to go meaningfully green for you as you work, but that means you have to stay rebased on my work branch. It's madness [06:40:17] Mmm I don't mind a rebase here and there [06:40:59] it seems intrusive... [06:41:08] OK i need to look like I'm taking my trip seriously :) [06:41:42]