[00:23:24] <legoktm>	 I tried profling some tests:
[00:23:24] <legoktm>	 10742.02% 11670.879   7742 - DatabaseBase::query
[00:25:00] <bd808>	 ouch
[00:28:27] <ori>	 AaronSchulz: https://gerrit.wikimedia.org/r/#/c/181006/
[00:31:59] <ori>	 bd808: i'm a bit confused by _joe|off's comments -- xenon is not the hotprofiler, and not related to xhprof, and doesn't use getrusage() at all
[00:32:10] <ori>	 but xenon is what he disabled
[00:32:37] <bd808>	 they turned of xenon and ProfilerXhprof
[00:33:02] <bd808>	 I think it was grab bag attempt at stopping the lockups
[00:33:35] <ori>	 I19fae102655182d98c07b0160704e9787ed763ec
[00:33:37] <bd808>	 I haven't grepped the hhvm source yet, but it's probably xhprof that is to blame
[00:34:11] <bd808>	 There was a followup too
[00:34:54] <bd808>	 https://gerrit.wikimedia.org/r/#/c/180806/
[00:35:16] <bd808>	 And this big hammer -- https://gerrit.wikimedia.org/r/#/c/180790/
[00:35:20] <wikibugs>	 3MediaWiki-Core-Team, Librarization: Librarization wishlist cleanup - https://phabricator.wikimedia.org/T1118#934497 (10aaron)
[00:56:28] <legoktm>	 bd808: https://gerrit.wikimedia.org/r/#/c/181009/ didn't really speed up the tests, but it dropped memory usage by 3MB
[01:04:35] <wikibugs>	 3MediaWiki-Core-Team, Wikimedia-Logstash, operations: Improve logstash - https://phabricator.wikimedia.org/T84895#934609 (10Gage) I've created a separate task for {T84958}
[01:44:47] <^d>	 robla: SOA Auth is T84962.
[01:45:18] <robla>	 cool beans  :-)
[01:45:38] <robla>	 !b T84962
[01:45:44] <robla>	 heh...that didn't work
[01:46:08] <^d>	 !phab T84964
[01:46:14] <^d>	 no bot?
[01:46:21] <legoktm>	 wikibugs doesn't respond to humans.
[01:46:31] <^d>	 wm-bot3 is here.
[01:46:35] <legoktm>	 oh
[01:46:42] <wikibugs>	 3MediaWiki-Core-Team: Authn and authz as a service - https://phabricator.wikimedia.org/T84962#935456 (10Chad) 3NEW
[01:46:43] <wikibugs>	 3MediaWiki-Core-Team: Authn and authz as a service - https://phabricator.wikimedia.org/T84962#935456 (10Chad)
[01:46:47] <legoktm>	 !phab is https://phabricator.wikimedia.org/$1
[01:46:47] <wm-bot3>	 You are not authorized to perform this, sorry
[01:46:51] <wm-bot3>	 You are unknown to me :)
[01:46:51] <legoktm>	 @whoami
[01:46:55] <legoktm>	 lame
[01:47:57] <wm-bot3>	 I am running http://meta.wikimedia.org/wiki/WM-Bot version wikimedia bot v. 2.6.2.0 [libirc v. 1.0.2] my source code is licensed under GPL and located at https://github.com/benapetr/wikimedia-bot I will be very happy if you fix my bugs or implement new features
[01:47:57] <legoktm>	 @help
[01:48:14] <wm-bot3>	 I trust:  ori!.*@wikipedia/ori-livneh (2admin),
[01:48:14] <legoktm>	 @trusted
[01:49:44] <ori>	 I wouldn't.
[01:50:14] <wm-bot3>	 I am running http://meta.wikimedia.org/wiki/WM-Bot version wikimedia bot v. 2.6.2.0 [libirc v. 1.0.2] my source code is licensed under GPL and located at https://github.com/benapetr/wikimedia-bot I will be very happy if you fix my bugs or implement new features
[01:50:14] <ori>	 @help
[01:50:50] <wm-bot3>	 Successfuly added legoktm!.*@wikipedia/Legoktm
[01:50:50] <ori>	 @trustadd legoktm!.*@wikipedia/Legoktm admin
[01:51:27] <ori>	 @trustedadd .*@mediawiki/demon admin
[01:51:36] <wm-bot3>	 Successfuly added .*@mediawiki/demon
[01:51:36] <ori>	 @trustadd .*@mediawiki/demon admin
[01:51:54] <ori>	 !phab is https://phabricator.wikimedia.org/$1
[01:51:54] <wm-bot3>	 Key was added
[02:02:25] <ori>	 ^ ^d
[02:14:32] <wikibugs>	 3MediaWiki-Core-Team, operations: HHVM is segfaulting 1/hour/server in production - https://phabricator.wikimedia.org/T78771#935516 (10ori)
[02:14:49] <legoktm>	 thanks
[03:30:18] <jackmcbarn>	 TimStarling: any idea why my change you +2'd just now went V-1?
[03:30:58] <TimStarling>	 test failure
[03:32:11] <jackmcbarn>	 TimStarling: yeah, i got that much, but that change shouldn't have caused that
[03:32:11] <TimStarling>	 AutoLoaderTest::testAutoLoadConfig
[03:33:44] <TimStarling>	 well, maybe no scribunto changes have been merged since that test was introduced
[03:33:59] * jackmcbarn makes a dummy change to test t hat
[03:34:57] <TimStarling>	 try adding those classes to $wgAutoloadClasses in Scribunto.php
[03:35:18] <TimStarling>	 if that works, then we can merge that and then rebase the other change on top of it
[03:41:28] <jackmcbarn>	 TimStarling: https://gerrit.wikimedia.org/r/#/c/181029/
[04:12:04] <TimStarling>	 jackmcbarn: just en and qqq?
[04:12:32] <TimStarling>	 is that a documented way to remove a message?
[04:12:38] <TimStarling>	 it's easy enough to remove the rest of them with sed
[04:12:54] <jackmcbarn>	 TimStarling: according to https://www.mediawiki.org/wiki/Localisation#Removing_existing_messages that's all i should do
[04:13:05] <jackmcbarn>	 (and until recently, presumably when that test was added, it said not to even remove qqq)
[04:13:16] <TimStarling>	 ok
[04:35:44] <TimStarling>	 jackmcbarn: you've got a few changes that have had negative reviews and should probably be abandoned
[04:36:21] * jackmcbarn looks
[04:36:33] <TimStarling>	 normally the author would click the abandon button
[04:37:56] <TimStarling>	 for example your oldest open change, https://gerrit.wikimedia.org/r/#/c/107009/
[04:38:10] <jackmcbarn>	 that one i plan to fix
[04:38:13] <jackmcbarn>	 just haven't got around to it
[04:38:19] <TimStarling>	 right
[04:38:47] <TimStarling>	 another is https://gerrit.wikimedia.org/r/#/c/115696/
[04:40:22] <jackmcbarn>	 ok, i abandoned all the hopeless ones
[04:40:27] <TimStarling>	 thanks
[04:40:34] <jackmcbarn>	 np
[04:40:37] <jackmcbarn>	 thanks for the merges
[04:41:24] <TimStarling>	 no problem, sorry about the delays
[05:29:45] <TimStarling>	 jackmcbarn: your changes often seem to stall for want of a rationale
[05:30:11] <TimStarling>	 e.g. https://gerrit.wikimedia.org/r/#/c/178760/
[05:30:20] <jackmcbarn>	 most (all?) of them do have a rationale; i just forget to mention it
[05:30:43] <TimStarling>	 you can always link to an en.wp module which would benefit from it, or something like that
[05:31:19] <AaronS>	 ori: https://gerrit.wikimedia.org/r/#/c/180702/
[05:33:37] <jackmcbarn>	 TimStarling: actually, i just remembered a question i've been wanting to ask you. you know how <ref> does side-effecty stuff when it's parsed, and it causes all kinds of oddities? what do you think of making the side-effecty stuff happen when it's unstripped instead of when it's first seen?
[05:33:47] <jackmcbarn>	 (that would remove the need for the argKeys change you just reminded me of)
[05:34:30] <TimStarling>	 you mean order references by the order of their strip tags in the HTML, rather than by their parse order in the wikitext?
[05:34:53] <jackmcbarn>	 well, that would be an effect of it, but unrelated to the reason for doing it
[05:35:15] <TimStarling>	 what is the reason for doing it?
[05:35:57] <jackmcbarn>	 currently, if you pass references in arguments to Scribunto, and you then call pairs(frame.args), the references get evaluated in what may as well be a random order
[05:36:12] <jackmcbarn>	 (and in parsoid, they're in html order)
[05:36:52] <TimStarling>	 that still sounds like what I said
[05:37:12] <TimStarling>	 anyway, it sounds beneficial
[05:37:37] <TimStarling>	 I'm sure users expect references to be numbered in the order they appear in the output
[05:38:07] <TimStarling>	 in general, I'm sure there is always a rationale in your head somewhere ;)
[05:38:07] <jackmcbarn>	 are you okay with the strip list containing callables and not just strings?
[05:38:57] <TimStarling>	 commit messages are partly documentation of what you did, and partly a message to the reviewer to get them excited about your change
[05:39:51] <TimStarling>	 a lot of my pull request descriptions for HHVM are along the lines of "fix terrible breakage in X"
[05:40:44] <TimStarling>	 because you have to communicate why you are doing the change and why it is important, in a way the reviewer will understand, otherwise the change will stall
[05:42:28] <TimStarling>	 I guess it is fine to add callables
[05:42:54] <TimStarling>	 unstrip() used to be done with strtr(), so there was no way to do callables
[05:43:32] <TimStarling>	 but now that we do it with preg_replace_callback(), it is easy enough
[05:44:06] <TimStarling>	 of course it means we won't be able to go back to strtr() if we wanted to
[05:45:38] <TimStarling>	 well, you could expand callables in advance, preparing the array to go into strtr()
[05:45:51] <TimStarling>	 that could be done based on the order of strip markers in the HTML
[05:46:14] <TimStarling>	 ok, no downside I guess
[05:47:20] <jackmcbarn>	 ok, i'll try doing that, and if it works, i'll abandon the argKeys stuff
[05:48:09] <TimStarling>	 sounds good
[05:49:07] <TimStarling>	 it also means we will hide references items with no citation
[05:49:22] <TimStarling>	 e.g. {{#if:<ref>blah</ref>||}}
[05:53:07] <jackmcbarn>	 which is a good thing imo
[05:53:13] <jackmcbarn>	 (and parsoid already does that too)
[06:09:58] <ori>	 AaronS: are you still interested in having PHP back traces for SlowTimer log entries?
[06:10:42] <ori>	 it looks quite easy to do
[06:28:18] <_joe_>	 TimStarling: I was trying to apply https://github.com/hhvm/hhvm-third-party/pull/40 on 3.3.1 and ran in some issues, would you be around in ~ 30 minutes if I need an advice?
[07:01:08] <_joe_>	 TimStarling: I managed to fix it, nevermind. It was missing a couple of includes and a bracket
[07:55:34] <wikibugs>	 3MediaWiki-Core-Team: Retest geo indexes in Orient - https://phabricator.wikimedia.org/T84975#935736 (10aaron) 3NEW a:3aaron
[09:03:20] <wikibugs>	 3MediaWiki-Core-Team: Convert old 1.23wmf* and 1.24wmf* deployment branches to tags - https://phabricator.wikimedia.org/T1288#935821 (10fgiunchedi) if there's no harm in keeping the tags around it sounds like a good idea to have them
[13:43:40] <wikibugs>	 3MediaWiki-Core-Team, operations, Services: Set warning thresholds for average cluster utilization - https://phabricator.wikimedia.org/T76306#936232 (10fgiunchedi) for capacity planning purposes I think we should also get an idea of how many requests a box can handle within a threshold latency, look at requests/...
[14:24:19] <wikibugs>	 3MediaWiki-Core-Team, operations: Review Graphite scaling options - https://phabricator.wikimedia.org/T1018#936310 (10fgiunchedi) a:3fgiunchedi assigning to myself, though not sure what this is about
[14:48:36] * anomie doesn't like that bug 1 is now T2001, rather than T1.
[15:17:55] <wikibugs>	 3MediaWiki-API, MediaWiki-Core-Team: allpages filterlanglinks DBQueryError - https://phabricator.wikimedia.org/T78276#936384 (10Anomie) 5Open>3Resolved The fix should be deployed to WMF wikis with 1.25wmf14, see https://www.mediawiki.org/wiki/MediaWiki_1.25/Roadmap for the schedule.
[15:32:57] <^d>	 anomie: Compromises. I wanted them to match up 1:1 too, but that ship sailed too early :(
[15:33:18] <^d>	 +2000 and keeping them sequential was Good Enough for me :)
[15:34:14] <anomie>	 ^d: BTW, T85002
[15:35:09] <^d>	 bleh, gerrit.
[15:35:21] <^d>	 anomie: Have you heard that gerrit is terrible and I want to kill it?
[15:35:22] <^d>	 :)
[15:35:27] <anomie>	 Yeah, at least it's +2000 rather than having to search for that "Reference: bz1" field.
[15:36:11] <anomie>	 Yes, I have heard that. I also heard that they're taking whatever the real name for "pherrit" is slow.
[16:50:15] <wikibugs>	 3MediaWiki-Core-Team, Scrum-of-Scrums, LabsDB-Auditor: Manually verify whitelisted.yaml / graylisted.yaml to ensure completeness - https://phabricator.wikimedia.org/T78730#936485 (10mark)
[17:01:11] <^d>	 manybubbles: Did we have a task in RT/Phab for shutting down lsearchd? I know of the "see if anyone's using it" one
[17:01:26] <^d>	 I didn't know if we had something from RT that's in Phab now for "shut er down"
[17:26:38] <manybubbles>	 ^d: I believe I wanted to make whatever tasks should be left for shut er down after digging into see if anyone is using.  like if we have to notify people or implement something else or whatever.  basically make a bunch of stuff and then add them as blockers for shuterdown
[17:27:14] <^d>	 I already wrote some patches for dismantling 2, 4 and 5's lvs.
[17:28:01] <manybubbles>	 ^d: oh sweet!  i think we should wait until january for it though
[17:28:08] <manybubbles>	 I think we're officially in no deploy land
[17:28:34] <^d>	 Those pools are in ops' hands now, it's not a deploy thing.
[17:28:39] <^d>	 I already disabled them yesterday.
[17:52:25] <hoo>	 legoktm: ping
[17:53:11] <legoktm>	 hoo: hi
[17:53:38] <hoo>	 legoktm: Do you have any bug reports about SpecialMergeAccount bricking accounts?
[17:53:43] <hoo>	 Because that seems to be the case
[17:53:47] <hoo>	 we have two cases at dewiki
[17:54:01] <legoktm>	 hadn't heard anything about that...
[17:54:18] <legoktm>	 bricking in the sense that a different password is being set?
[17:55:09] <hoo>	 legoktm: Email being lost and password "no longer works"
[17:55:16] <hoo>	 but they have a password set
[17:55:41] <hoo>	 but if eg. the salt is being set wrong, that might just not work
[17:56:24] <legoktm>	 is it just picking a different home wiki than the user is expecting?
[17:56:45] <hoo>	 No, dewiki
[17:56:57] <hoo>	 and the password was copied 1:1 from dewiki to CA
[17:57:27] <legoktm>	 hm
[17:57:57] <legoktm>	 what usernames?
[17:58:12] <wikibugs>	 3Services, MediaWiki-Core-Team, operations: Set warning thresholds for average cluster utilization - https://phabricator.wikimedia.org/T76306#936595 (10GWicke) Lets not allow the perfect to get in the way of the good though. For some services it will make sense to do a deep investigation of latency vs. load, but...
[17:58:45] <legoktm>	 hoo: is this an initial merge or just attaching accounts merge?
[17:58:56] <legoktm>	 initial, sorry I'm tired :P
[17:59:11] <hoo>	 yeah
[18:00:23] <legoktm>	 	protected function storeGlobalData( $salt, $hash, $email, $emailAuth ) {
[18:00:48] <legoktm>	 		$ok = $this->storeGlobalData(
[18:00:48] <legoktm>	 				$home['id'],
[18:00:57] <legoktm>	 user_id is still the salt right?
[18:01:05] <hoo>	 yep
[18:01:14] <hoo>	 dewiki user id became the salt
[18:03:16] <legoktm>	 what's their username?
[18:03:30] <hoo>	 "Hob Gadling" is one
[18:03:46] <hoo>	 and "Fingalo"
[18:03:57] <hoo>	 Manually fixed the first one
[18:04:01] <hoo>	 second one is untouched
[18:04:06] <legoktm>	 ok, /me looks
[18:04:59] <hoo>	 Fingalo has an email set for the global account
[18:05:00] <hoo>	 mh
[18:05:55] <legoktm>	 I'm looking through the code, and I don't actually see where we use the salt.
[18:06:05] <legoktm>	 		$hash = $passwordFactory->newFromCiphertext( $encrypted );
[18:06:05] <legoktm>	 		if ( $hash->equals( $plaintext ) ) {
[18:06:36] <hoo>	 The salt is actually supposed to be in the password serialized hash 
[18:06:39] <hoo>	 nowadays
[18:06:50] <legoktm>	 right
[18:06:50] <hoo>	 but could be that some legacy stuff is acting up
[18:07:12] <legoktm>	 my gu_salt is ''
[18:07:13] <hoo>	 remember that bug I recently closed... that stuff is a little messy with legacy things
[18:07:21] <hoo>	 * fix
[18:07:23] <hoo>	 * fixed
[18:07:35] <legoktm>	 and CentralAuthUser::saltedPassword() returns '' for the salt
[18:09:38] <legoktm>	 				base64_decode( $this->args[0] ) is the salt
[18:11:15] <legoktm>	 hoo: can you file a bug for this?
[18:11:36] <hoo>	 legoktm: I start to think it might not actually be a bug
[18:11:47] <hoo>	 but not sure
[18:12:04] <hoo>	 It should probably have picked the enwiki email if dewiki didn't have one
[18:12:16] <hoo>	 and the other account is just old
[18:12:24] <hoo>	 Probably forgot their dawiki password
[18:12:32] <hoo>	 and am blaming that on CA now
[18:12:36] <legoktm>	 heh
[18:13:05] <legoktm>	 well, if you think we should look into it further, file a bug :P
[18:13:45] * legoktm will be afk for a bit
[18:14:08] <hoo>	 Maybe I can make DerHexer do that
[18:47:26] <_joe|off>	 AaronS: the 2 server orientdb cluster will be live on monday
[18:47:54] <AaronS>	 cool, the I thought it was 3
[18:48:02] <AaronS>	 s/the/though
[18:48:46] <_joe|off>	 AaronS: no we just have 2, that's the best I could obtain in this timespan
[18:49:13] <_joe|off>	 we had no other spares with ssds larger than 120 GB
[18:49:24] <_joe|off>	 also, we have 600 GB/server here
[18:49:51] <_joe|off>	 so you may as well use a replication factor of 2 (in this case that means mirroring, but whatever)
[18:50:07] <AaronS>	 well that plan was always factor=2
[18:51:12] <_joe|off>	 AaronS: if we decide to go on with orient experimentation, I'll see if we can obtain one more
[19:08:03] <bd808>	 heh. 39.5K of the last 42.5K log events from group0 are GlobalTitleFail
[19:37:37] <bd808>	 ^d: How do I use a db group in InitializeSettings? I want to make a patch that sets $wmgUseMonologLogger true by default and false for wikipedia.dblist. Do I just use 'wikipedia' as the key in the config array?
[19:49:36] <wikibugs>	 3MediaWiki-Core-Team: Fix onResponses in VirtualRESTServiceClient - https://phabricator.wikimedia.org/T85016#936796 (10aaron) 3NEW a:3aaron
[19:52:40] <^d>	 wikipedia is the weird one.
[19:52:42] <^d>	 the others, yes.
[19:52:45] <^d>	 I remember people tripping up on it so I've always avoided it.
[20:40:25] <bd808>	 ^d: Using 'wikipedia' trips folks up because we don't check for it in CommonSettings. :/
[20:40:38] <^d>	 Ah
[20:41:16] <bd808>	 https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/CommonSettings.php#L198-L205
[20:41:59] * bd808 wonders if small + medium + large is the same thing
[20:42:34] <bd808>	 nope
[20:43:55] <legoktm>	 small medium large is for how often we run the special page maint. script update stuff
[20:43:55] <legoktm>	 and Reedy updates it every so often
[20:57:41] <wikibugs>	 3MediaWiki-Core-Team, operations: Come up with key performance indicators (KPIs) - https://phabricator.wikimedia.org/T784#937037 (10Gage)
[21:04:10] <bd808>	 Reedy: When you are about, I'd love to know if this seems like a bad idea to you <https://gerrit.wikimedia.org/r/#/c/181129/1> (adding mediawiki.dblist check in CommonSettings)
[21:06:05] <Reedy>	 does 'wiki' work?
[21:06:57] <Reedy>	 https://noc.wikimedia.org/conf/highlight.php?file=wgConf.php
[21:07:01] <Reedy>	 	'wikipedia' => 'wiki',
[21:07:23] <bd808>	 I don't know actually. is dbsuffix checked in SiteConfiguration
[21:08:27] <bd808>	 yup, suffix is checked
[21:08:39] <bd808>	 so I don't need that hack
[21:08:42] <bd808>	 sweet
[21:30:56] <legoktm>	 if the xenon/xhprof profilers are loaded in StartProfiler.php, that means we aren't profiling multiversion right?
[21:46:27] <bd808>	 legoktm: we aren't profiling the bits that occur before the top os WebStart, no
[21:46:34] <bd808>	 *top of
[21:46:56] <legoktm>	 right
[21:47:11] <^d>	 We could do better in possibly actually.
[21:47:22] <legoktm>	 bd808: so, multiversion's composer autoloader is registered before MW's is, but I'm not sure how we can measure whether it's slow or not
[21:47:25] <^d>	 s/possibly/prod/
[21:47:52] <bd808>	 legoktm: hmm...
[21:48:26] <legoktm>	 I don't see it on the xenon graphs nor the xhprof output
[21:48:28] <bd808>	 we could profile using T.im's raw xhprof technique outside of most things
[21:48:45] <^d>	 Yeah
[21:49:50] <bd808>	 multiversion's autoloader *should* be fast because it has a very small set of classes to manage
[21:49:54] <bd808>	 very small
[21:50:00] <wikibugs>	 3MediaWiki-Core-Team: Support strategy #1 in PoolCounter classes - https://phabricator.wikimedia.org/T85026#937122 (10aaron) 3NEW a:3aaron
[21:52:56] <legoktm>	 http://fpaste.org/161470/41902593/raw/
[21:59:25] <bd808>	 I think I need to read their autoloader. Is it memozing all the misses?
[21:59:34] <bd808>	 and if so why?
[22:00:01] <bd808>	 oh, I bet because they are building a chained loader inside their public loader
[22:00:06] <bd808>	 hmm
[22:00:22] <wikibugs>	 3MediaWiki-Core-Team: Support strategy #1 in PoolCounter classes - https://phabricator.wikimedia.org/T85026#937162 (10aaron) Per https://gerrit.wikimedia.org/r/#/c/178903/
[22:01:34] <bd808>	 MessageCache::parse called by Sanitizer::encodeAttribute/Message::__toString/Message::toString/Message::parseText/MessageCache::parse with no title set.
[22:02:17] <bd808>	 That's a message being passed to encodeAttribute() without being unwrapped
[22:02:55] * bd808 wonders how these will ever all be squashed
[22:03:16] <legoktm>	 yeah, there are also instances of stuff passing Message objects to Html:: functions
[22:03:39] <legoktm>	 bd808: We killed the top 2-3 globaltitlefails already :D
[22:03:47] <legoktm>	 just need to keep working down the chain :P
[22:03:52] <bd808>	 I wonder if we should back up and look at Message::__toString being called?
[22:04:01] <bd808>	 legoktm: w00t
[22:24:14] <AaronS>	 manybubbles: actually, https://gerrit.wikimedia.org/r/#/c/178903/12/PoolCounterClient_body.php should go in core come to thing of it
[22:24:42] <manybubbles>	 AaronS: I suppose so.
[22:24:46] <AaronS>	 manybubbles: meh doesn't matter
[22:24:57] <AaronS>	 we don't use a delegation pattern anyway
[22:24:58] <manybubbles>	 not _too_ much
[22:25:13] <AaronS>	 so it has to be redone in each class...another refactoring project ;)
[22:26:16] <AaronS>	 manybubbles: this is why I love the pattern of a final base class method that delegates to a doX version that is subclasses
[22:26:40] <AaronS>	 you can always add in common logic like this without moving stuff around and breaking internal interfaces
[22:27:47] * AaronS will make some patches
[22:29:08] <wikibugs>	 3MediaWiki-Core-Team: Generalize nowait logic in PoolCounterClient_body - https://phabricator.wikimedia.org/T85031#937201 (10aaron) 3NEW a:3aaron
[22:32:27] <wikibugs>	 3MediaWiki-Core-Team: Generalize nowait logic in PoolCounterClient_body - https://phabricator.wikimedia.org/T85031#937216 (10aaron) Move some code to the base class
[22:33:21] <^d>	 bd808: Why does this look like it's doing things twice when I run puppet? https://phabricator.wikimedia.org/P175
[22:34:40] <bd808>	 ^d: It's the 2 phases (compile and apply) both loading ruby plugins. Not a big deal.
[22:35:16] <bd808>	 masterless puppet does basically the things the master would do (compile) and then the things the client would do (apploy)
[22:35:27] <^d>	 I figured it was something it just looked duplicate-y.
[22:35:28] <^d>	 :)
[22:35:31] <bd808>	 *apply
[22:36:01] <bd808>	 Puppet does some truly horrible things under it's hood. You don't want to know how the sausage is made.
[22:36:43] <^d>	 mmm, sausage.
[22:54:54] <wikibugs>	 3LabsDB-Auditor, MediaWiki-Core-Team, Scrum-of-Scrums: Manually verify whitelisted.yaml / graylisted.yaml to ensure completeness - https://phabricator.wikimedia.org/T78730#937252 (10Legoktm) Where are whitelisted.yaml and greylisted.yaml?
[22:58:14] <wikibugs>	 3SUL-Finalization, MediaWiki-extensions-CentralAuth, MediaWiki-Core-Team: Re-enable $wgCentralAuthAutoMigrate = true - https://phabricator.wikimedia.org/T78727#937255 (10Legoktm) >>! In T78727#931822, @Nemo_bis wrote: > Do we know how many users were merged thanks to $wgCentralAuthAutoMigrate?  legoktm@fluorine:...
[23:08:42] <legoktm>	 greg-g: what's the policy on backporting stuff during the deployment freeze? there's a CA patch I'd like to get deployed so we can turn a feature back on: https://gerrit.wikimedia.org/r/181206
[23:09:09] <greg-g>	 you need a really really really good reason
[23:11:10] <legoktm>	 ok, I'll see if I can come up with one
[23:11:21] <legoktm>	 still figuring out whether it's worth it...
[23:39:04] <Krenair>	 hi AaronS
[23:39:15] <Krenair>	 I am updating MultiHttpClient...
[23:39:30] <Krenair>	 and I don't understand your inline comment
[23:40:43] <AaronS>	 looks like a space was removed
[23:40:56] <Krenair>	 it was
[23:41:18] <Krenair>	 gerrit displays it differently to my editor :/
[23:41:53] <Krenair>	 looks like those key doc lines are indented with a space and a tab
[23:42:57] <AaronS>	 manybubbles: https://github.com/orientechnologies/orientdb/issues/3244
[23:43:02] <AaronS>	 I'm not just crazy, right?
[23:45:05] <AaronS>	 699 rows now (I'm adding more edges atm)...so it's the full result set I guess
[23:45:24] <AaronS>	 I guess that earlier issue I had is the same bug in all probability