[00:25:22] TimStarling: I'm looking to fix the debug profile handling to support tideways (currently all HHVM conditional) - per https://phabricator.wikimedia.org/T206152 [00:25:31] You already have patches for that in progress right? [00:25:46] or at least, changing it enough so that it probably makes sense to land that first [00:26:37] tideways support is in https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/478137/ [00:34:39] TimStarling: cool, I didn't spot the part where it ties Tideways to XHGui, perfect :) [00:34:50] TimStarling: When can we roll it out? :) [00:35:51] I will start working on it, I seem to remember I had it as a top priority before my vacation, but priorities got a bit scrambled after it [00:36:08] it should be possible to deploy before all hands [00:42:37] Krinkle: only +1 for https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/484347/ ? [00:44:35] TimStarling: I was gonna land but I wanted Aaron's look-over given he seems to have mostly maintained the library so far in terms of overall structure or some non-technical views. But I suppose we could do that in follow-up if you're okay with that, e.g. that there'll be a relatively quick turnaround on his post-merge review, not yet re-allocating the prority elsewhere :) [00:47:04] the library as in MimeAnalyzer? [00:48:24] TimStarling: yeah [00:49:49] I do realise that most probably it's existed much earlier and you or Brion created it. [00:50:51] well, Aaron moved it to libs/, I'm trying to load the annotation from before that but it's slow for some reason [00:51:03] Brion introduced the class [00:51:31] Anyhow, I think as part of filebackend maintainership, Aaron's been looking after it mainly and has intention to make it a library. Not currently a priority though. [00:51:53] I wouldn't mind transferring ownership to CPT formally, assuming Aaron would be okay with that. [00:52:00] move detection failed, so it looks like Aaron wrote the whole class as of 2016 [00:54:12] Special:Upload belongs to the multimedia team [00:54:50] apparently to kaldari [00:55:00] MimeAnalzyer is not really part of filerepo/filebackend [00:57:14] ah, you merged it, thanks [05:50:16] <_joe_> TimStarling: do you have any objections to opening a beta-feature opt-in to php7? [05:50:22] <_joe_> I mean to do it today [05:50:32] no [05:56:23] <_joe_> ok thanks :) [06:47:58] <_joe_> TIL the GettingStarted extension uses redis directly and not via the usual MediaWiki interfaces https://phabricator.wikimedia.org/T158239 [06:48:34] <_joe_> which makes me wonder if we shouldn't enforce, at least for production usage, extensions to interact with their datastores via interfaces offered by core [06:49:04] <_joe_> instead of just being able to choose their datastore and do raw querying [06:49:19] <_joe_> which results in issues like that one [06:50:37] <_joe_> one extension uses a datastore we want to ditch, and we can't ditch it until someone committed time and energy to it [06:52:53] _joe_: guess who you can blame for that one [06:53:01] <_joe_> I know! [06:53:23] <_joe_> it's one of my favourite ex-employees :P [06:54:38] :D [06:54:46] <_joe_> legoktm: but "blame" is the wrong term [06:55:00] <_joe_> although, given it's ori, probably no. Blame is the right term. [06:55:10] <_joe_> :P [06:55:33] blame is the technical term! git-blame(1) ;) [06:55:50] <_joe_> what I mean is that if we want to go multi-dc and avoid surprises, we need a tighter grip on how datastores are used [06:56:01] <_joe_> legoktm: wait until someone decides it's an oppressive term [06:56:03] <_joe_> ;) [08:42:50] _joe_: It seems a reasonable thing to do. And if they can't for whatever reason, it should be documented, and task(s) filed as appropriate to fix the issue in core/upstream library etc [11:44:45] <_joe_> Reedy: should we backport the beta feature today? [11:44:52] _joe_: I'm happy to [11:44:58] <_joe_> I think it's the right time to send the announcement [11:45:08] I can C+2 https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/WikimediaEvents/+/484798/ now [11:45:22] Still needs James_F's mw-config patch to enable it fully [11:45:28] <_joe_> I was thinking to wait for James? Else yes, we can obviously deploy [11:45:49] <_joe_> yeah let's wait for James, in the meantime I have the time to draft an email to wikitech-l [14:54:03] @Krinkle , regarding your comment on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/481954 about code coverage indicating doSetCallback not being called, that is indeed strange. Locally, I added some spammy logging to doSetCallback, reran unit tests, and confirmed it is being called. What generates that code coverage report? I'm curious how accurate it is and/or if I can set it up locally to explore its behavior. [15:55:31] Oh, hey. [15:56:27] Reedy: See t.gr's comment. PHP7_START is the start of the "all logged in users get PHP7" feature. We definitely don't want that to be now. [15:56:48] (Hey tgr too.) [15:57:47] We should bump PHP7_START to be in a decade, and then pull it back when we're sure we know we want to do it [16:37:22] <_joe_> uh, why all logged in users on php7? [16:37:31] <_joe_> why the distinction? [16:37:58] <_joe_> we're going to have X% of all users (logged in or not) use php7 [16:38:19] <_joe_> with X hopefully monotonically increasing over the next 3-4 months to 100 :) [16:58:09] bpirkle: The code coverage is generated by phpunit, by passing `--coverage-html outdir` or one of the other similar --coverage-* options. You need the PHP xdebug extension enabled or you need to use the phpdbg executable (like "phpdbg -qrr path/to/phpunit.php ..."). As for the lack of detected coverage, that might be due to missing @cover annotations on the unit test that's calling the method. [16:59:32] anomie: thank you! That gives me good info to fiddle locally and see if I can reproduce/correct. [17:01:58] anomie: Also, I see there's a new patchset (two actually) on the "Add temporary logging for T210739 " change. Do you need another "virtual +2"? [17:01:59] T210739: Target deletion during page move fails - https://phabricator.wikimedia.org/T210739 [17:02:08] bpirkle: Yes, please [17:02:19] k, looking [17:02:22] James_F: Reedy: (sorry, was in a meeting) the way I read the code users who registered before PHP7_START stay on the old engine, users who registered after that will be split 50-50 [17:02:40] which makes sense if you want to run a proper A/B test [17:02:59] Yeah, but not what we wanted to test with the Beta Feature. [17:03:09] ie. want to look at how the engine switch affects user productivity and such [17:03:51] if we don't plan a formal research like that and are only interested in whether there are bugs caused by PHP7, how the latency changes and so on, that seems pointless [17:04:14] and we should split the entire traffic, not just newly registered users [17:05:20] the entire logged-in traffic, rather [17:07:39] <_joe_> tgr: we'll be splitting users, all of them, in growing percentages, after a few weeks of beta opt-in [17:08:00] <_joe_> that means also users that are logged out [17:08:47] in that case, I imagine the beta feature should just be a straightforward on/off switch? no splitting, no cutoff date [17:08:47] <_joe_> same as we did with HHVM - only this time we might be a bit more aggressive as I don't expect php-fpm to sigsegv every N requests as hhvm did at first :P [17:10:20] well the issue is that the beta feature code was copied from HHVM and that one did something complicated where only half of the people who opted in to the beta feature actually got HHVM enabled [17:10:45] my point is that that seems unnecessary now, unless someone is actually planning to do a study [17:16:20] <_joe_> sure I agree [17:16:32] <_joe_> I'm not even sure we used that code in the end, probably yes [17:17:23] <_joe_> James_F, Reedy: I will be around later for techcom, at 21:00Z and afterwards; do you want me to take care of amending the patch?a [17:29:59] _joe_: I'll fiddle with the patch now. [17:31:04] <_joe_> thanks :) [17:35:16] _joe_: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/WikimediaEvents/+/486107 [17:36:48] <_joe_> James_F: I would've made isUserInPHP7Study return false, but it's ok ofc. [18:15:58] tgr, Reedy: Can I steal a C+2 from one of you on https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/486107 so I can deploy? [18:17:48] done [18:21:11] Thanks. [18:40:18] <_joe_> James_F: what's left to do to make the beta feature appear? A mediawiki-config change, right? [18:41:37] _joe_: Deploy the code to prod, and the config change, yes. [18:41:53] _joe_: It should be live on the Beta Cluster right now (which ignores the whitelist). [18:42:19] _joe_: And indeed it appears: https://en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences#mw-prefsection-betafeatures [18:42:44] Though, unsurprisingly, the Beta Cluster doesn't respect the config. [18:48:49] _joe_: Want to go ahead with the wmf.13 deployment and the config change? [18:48:53] <_joe_> uh? I thought it would [18:49:08] Oh. Let's validate that first, then. [18:49:50] <_joe_> oh right, it's probably labs varnish cleaning out the cookie [18:49:55] <_joe_> sigh [18:50:11] <_joe_> also I don't have a user on the beta cluster [18:50:31] <_joe_> but the apache configuration is the same we have in production, and it should work [18:50:46] Hmm. [18:50:59] <_joe_> James_F: do you find a PHP_ENGINE cookie set for enwiki in beta in your browser after activating the beta feature? [18:51:53] I have a cookie called "php7" with the value "true". [18:52:25] <_joe_> uhm, no [18:52:42] <_joe_> the cookie should be named PHP_ENGINE with a value of "php7" :D [18:52:49] <_joe_> ok lemme make a patch to amend that [18:52:54] If it's not present it's assumed to be HHVM? [18:52:58] <_joe_> yes [18:53:03] Right. I can whip that up. [18:53:06] <_joe_> hhvm is the default right now [18:53:30] <_joe_> ack [18:54:58] _joe_: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/WikimediaEvents/+/486130 [18:56:48] <_joe_> +1'ed [18:57:47] tgr: C+2? :-) [19:00:28] <_joe_> I can +2 as well, but I should only do it in an emergency [19:01:04] done [19:01:17] Thanks, tgr. [19:01:51] _joe_: And yeah, we're playing a little fast and loose with the deployment train concept already. ;-) [19:02:40] <_joe_> yeah :P [19:03:43] <_joe_> I'm going to dinner now, I'll be back in a couple hours, sorry [19:03:48] No worries. [19:54:25] bpirkle: https://www.mediawiki.org/wiki/Manual:PHP_unit_testing/Code_coverage [19:55:10] bpirkle: it's mostly just built-in phpunit coverage report, the one thing we modify in that Jenkins job is the phpunit.xml file so as to only create a report for what you used (by default, it'll index the whole repo as uncovered even if you only pass 1 *Test.php file on CLI). [20:12:54] _joe_: And yup, now that we're setting the right cookie, Beta Cluster behaves as expected with the Beta Feature, both for opting in and out. :-) [20:13:31] <_joe_> Great [20:31:33] Is there a ticket or page I can see a summary of the parser cache changes that happened due to mcr work? [20:35:29] https://wiki.waze.com/wiki/Special:Version [20:35:32] gj google team [21:00:58] Reedy: Ouch. But https://wazeopedia.waze.com/wiki/USA/Special:Version isn't much better (1.29.2) [21:02:14] Reedy: I have a contact at Waze, will ping them about it. [21:34:43] maybe if we made it easier to update MW installs.... :P [21:36:17] Maybe if we made it harder to customise MW so that upgrading always works. ;-) [22:00:13] <_joe_> we should simply write a malware that exploits old mediawiki installs in order to upgrade them [22:00:40] lol [22:00:56] <_joe_> what could possibly go wrong [22:01:24] you'll infect your self :P [22:19:11] _joe_: I think Ori actually did some prototype work towards that at some point ;) [22:31:01] Also, waze "We recently updated our password requirements. Please create a new password without any special character." [22:46:44] Reedy: NSA is still using Windows 98, they can't read your fancy emojis [23:00:28] heh :D [23:02:29] _joe_: Do you want to go ahead with the Beta Feature on wmf.13 today? If not, we might as well just do it on wmf.14 (where it already exists and is working, but is hidden in prod by the config whitelist). [23:12:53] <_joe_> James_F: when is .14 going to enwiki? [23:13:18] _joe_: Theoretically, tomorrow around noon SF. [23:13:36] _joe_: But given that right now I'm trying to un-derail it so it goes to Commons now… :-( [23:14:01] <_joe_> yeah, let's do it then? [23:14:23] Kk. Works for me. [23:14:27] <_joe_> I'm not going to be around much longer, but I guess you don't need me? [23:14:34] Nope. :-) See you tomrrow. [23:14:39] <_joe_> I can do the mwconfig patch tomorrow [23:14:47] <_joe_> if you prefer to wait [23:14:52] Yeah, that should be all you need. [23:15:07] Just go for it, should be totally fine.