[01:38:31] TimStarling: have a look at mw1230 when you have a chance. Consistently high system CPU%. strace -c shows futex waits as being the culprit and a backtrace of HHVM threads suggests it has to do with the PCRE cache [01:38:54] I created https://phabricator.wikimedia.org/T75706 to track that [01:46:00] which PCRE cache? [01:46:55] the thread-local one? you wouldn't think that would have much contention [15:24:06] Anyone know if there's a way to add "MediaWiki-Core-Team" to a task and put it in the "Needs Review" column in one step, instead of having to edit it first and then go the board and drag-and-drop? [15:27:08] <^d> anomie: On a task already existing? [15:27:36] <^d> (I know you can file a new task directly into a column from the workboard) [15:29:40] ^d: Yeah [15:30:02] <^d> Yeah I don't know how you could do that :\ [15:32:34] Maybe legoktm will write a tool like phab-bz. Or else I might hack something together, but I'll probably forget to publish it anywhere. [15:53:09] bd808: for later: when I make submodule updates of deployment branches for core the vendor repo always fails to properly checkout. (reference is not a tree: 532f8230d0422204b010ea65a9e90037143dac48) is that normal? [15:53:44] manybubbles: No, that doesn't sound like a good thing [15:54:05] I've always just ignored it and kept going. [15:54:06] manybubbles: is this in your local clone or on tin? [15:54:11] local [15:54:25] I don't submodule update vendor on tin. Or I haven't yet. [15:54:35] hmmm... [15:54:46] That hash is certainly not in gerrit [15:55:44] manybubbles: My advice would be to file a bug about it and maybe Reedy can figure out what's wrong [15:56:00] * bd808 is trying not to lick all the cookies [15:58:58] manybubbles: Try removing the vendor directory and .git/modules/vendor/, and then redo git submodule update --init --recursive ? [16:03:13] anomie: didn't do it sadly. might go the bug route :) [16:05:13] manybubbles, bd808: Huh. I'm seeing 532f8230d0422204b010ea65a9e90037143dac48 as a valid hash in git. https://git.wikimedia.org/tree/mediawiki%2Fvendor.git/532f8230d0422204b010ea65a9e90037143dac48 [16:05:52] anomie: double weird -- https://gerrit.wikimedia.org/r/#/q/532f8230d0422204b010ea65a9e90037143dac48,n,z [16:07:39] bd808: It looks like the branch creations don't show up in Gerrit [17:02:13] <^d> manybubbles|away: I added you to CirrusSearch project and gave us a picture :) [17:17:45] anomie: last I checked messing with workboards wasn't possible via phab's API (only found https://secure.phabricator.com/T5214 upstream, and that's about reading though) [17:17:58] legoktm: :( [17:27:53] <^d> I'm thinking of adding a phabricator role to vagrant. [17:28:15] There is a pahb vagrant project somewhere... [17:28:21] <^d> Orly?!? [17:28:52] ^d: Search wikitech-l I think. There was a post by someone a month or so ago [17:29:26] <^d> Ah, fork of https://github.com/bloomberg/phabricator-tools [17:29:32] <^d> Google had taken me there. [17:31:00] https://lists.wikimedia.org/pipermail/wikitech-l/2014-November/079399.html [17:31:39] <^d> I guess I'll need to add elasticsearch support to it :p [17:33:04] manybubbles|away: When you get some cycles, +2 on https://gerrit.wikimedia.org/r/#/c/173429/ would be cool if you approve. [17:34:27] <^d> Oh yeah I meant to look at that [17:41:54] <^d> bd808: +2d [17:42:52] <^d> manybubbles: Yeah I just finished testing :) [17:53:39] bd808: https://gerrit.wikimedia.org/r/#/c/175170/ would be nice to get merged before wmf use [17:53:46] bd808: https://getcomposer.org/doc/04-schema.md#archive says "A set of options for creating package archives." is that something different from adding the package or...? [17:55:03] legoktm: I *think* that controls what files are brought in when you install, but I'm not sure. It needs some experimentation. [17:55:47] AaronSchulz: I'll take a deeper look at your patch. I read through it on Saturday and it looks good but I haven't tested yet. [17:56:07] * bd808 is in the midst of too many meetings Monday :/ [18:02:37] bd808: I just talked with Trevor, and he was saying we should just make vendor the place where we have the CSS and the JS load from rather than copying it in core [18:03:13] legoktm: Meaning take both in via composer? [18:03:22] That works for me [18:03:26] yeah, so composer would bring in the js, css, and php [18:03:52] Would that need RL changes or just config? [18:04:26] only thing is the definition of oojs-ui in Resources.php, but I was thinking we could move https://github.com/wikimedia/mediawiki/blob/master/resources/Resources.php#L1601-1632 into a file in oojs/ui called "oojsui.resources.php" and say it should be loaded if you're using it with mediawiki [18:07:00] That makes some sense. Maybe the file name could be somewhat more generic to establish a pattern for doing similar things in the future? *shrug* [18:07:21] like resource-loader.php or somehting? [18:08:01] If you can come up with something that Trevor, Timo and Ori all like you are probably golden. :) [18:08:37] That won't work. [18:08:44] keep them separate. [18:09:02] js code in git is incomplete, and when we separate the repos won't be in the composer package anyway [18:09:59] making an exception for one will be messy. And indeed we need resource declaration, which isn't a standard yet and would essentially be a wmf hack in a composer package. [18:15:10] Krinkle: Are the php and js/css bits going to be separated then? [18:18:41] <^d> We need to get the phab bot in here for our project. [18:19:40] ^d: I bet legoktm can help with that [18:19:49] <^d> yup ;-) [18:20:01] * legoktm will do in a few minutes [18:23:34] bd808: They're essentially ports, separately maintained packages and implementations. php being downstream from the current design. There could be other implemetnations as well in theory. [18:23:51] js files need to be compiled/built before they can be used. [18:24:06] which is done in the npm package publish build step [18:24:41] bd808: Whether we'll split the repos is not yet known, but I would recommend to (lowest priority) eventually do that as the repo structure is getting a bit messy at the moment. [18:24:58] *nod* [18:25:17] Don't make a new core. :) [18:29:03] Krinkle: Except the non-code components, the versioning and the documentation back-end are shared between the "ports". [18:38:19] 3MediaWiki-Core-Team, Project-Management: Install PHPExcel so I can export reports - https://phabricator.wikimedia.org/T152#781583 (10Aklapper) [18:41:50] 3MediaWiki-Vendor, MediaWiki-Core-Team: Security review of Plancake e-mail parser library - https://phabricator.wikimedia.org/T74956#781629 (10bd808) [18:42:14] James_F: versionining is arguable. I'm sure we'll often update js and php in separate commits. Release versions, yes. But that's the same for any closely-following port. Documentation, not so much. The demos and style guide are shared, which I think should remain in the js repo only. But the docs are separate (jsduck / doxygen). [18:42:24] and most non-code components belong either to the js or php variant. [18:42:26] (I think) [18:42:33] But again, I'm not pushing for a split at this point. [18:42:39] Just to maintain the conceptual split in publishing. [18:43:01] (and distributing js via composer is probably not very clean anyway, especially if we don't plan on doing that for anything else) [18:43:06] Krinkle: Err. No. [18:43:39] Krinkle: The styling of the PHP-generated and the JS-generated buttons is not meant to look similar. It's meant to look absolutely identical. Otherwise the entire enterprise is pointless. :-) [18:44:02] 3MediaWiki-Core-Team, MediaWiki-API: API: adrprefix gives invalid title error for valid titles - https://phabricator.wikimedia.org/T75711#781652 (10Anomie) [18:44:03] Right, the stylesheet is shared. [18:44:05] Not ported. [18:44:20] but css doesn't execute well in PHP :P [18:44:42] 3MediaWiki-Core-Team, MediaWiki-API: API: adrprefix gives invalid title error for valid titles - https://phabricator.wikimedia.org/T75711#777505 (10Anomie) [18:45:05] an applications' front-end would concern itself with getting the frontend module. [18:45:14] we'll see [18:45:25] * bd808 notes that sharing code between related repos is what submodules are for [18:45:46] Or svn:externals for the old skool among us :) [18:46:22] <^d> oh man svn:externals. [18:46:31] <^d> that's how we used to pull in geshi you know. [18:47:40] I (ab)used snv:external for a lot of things in the 10+ years I ran svn repos [18:48:02] <^d> And yes, submodules are how you're supposed to do it in git. [18:48:05] <^d> But submodules blow. [18:48:19] <^d> They totally don't scale beyond like 2-3 submodules per repo. [18:49:20] heh, lessphp is T1337 [18:49:32] 31337! [18:50:08] * bd808 owns http://1337monkeys.com/ for some unknown future venture [18:50:14] bd808: Hm.. do you know how to disable the revision e-mails from phabricator? [18:50:26] I just got an email saying you submitted a commit I authored (the one about php errors) [18:50:57] ah. I don't know. I heard qgil say that it should be possible [18:51:00] getting sending me 10 e-mails about that one event is enough already :) [18:51:07] gerrit * [18:51:52] I don't see diffusion listed at https://phabricator.wikimedia.org/settings/panel/emailpreferences/ [18:53:05] Indeed [18:53:18] Let's ditch phab and go with github instead. [18:53:27] We were gonna do that anyway, right? [18:53:29] Krinkle: :-P [18:53:54] * bd808 will not touch that question [18:54:28] one day, one day, I'm telling you. All roads lead to github. It's a sacred path and can't be fast-forwarded. [18:54:56] https://twitter.com/OpenSourceLaws/status/530511936522571776 [18:54:57] Krinkle: I bet the emails from diffusion are a global herald rule [18:55:18] Should we even be syncing them to phab right now [18:55:27] or is that some random experiment that shouldn't be enabled still? [18:58:10] <^d> Possibly stupid question. setCacheMaxAge() in the api. That's a "num of seconds to live" right? [18:59:29] <^d> Also, I guess I'll have to go back to doing evil corporate proprietary stuff if it's github or gtfo with floss. [19:02:52] <^d> bd808, manybubbles: hangout? [19:03:05] doh. yup [19:04:56] bd808: Hm.. Do we have an overview of which parts in MediaWiki will become a library? [19:05:33] Krinkle: Aaron has been working on a preliminary list [19:05:37] I just ran into https://phabricator.wikimedia.org/T62563 again in a fork of mine for a Tool Labs php project. Would be nice if our caching classes were a lib (or adopt some other lib) [19:06:25] Krinkle: https://phabricator.wikimedia.org/T1118 [19:06:28] probably not one big lib, but some kind of plugin interface maybe. Should probably seriously consider adopting an existing one (at least the abstract interface of something else) [19:06:31] Krinkle: BagOStuff is in progress, I have a patch open to make the logging not mw dependent [19:06:36] Cool [19:07:03] https://github.com/legoktm/fab [19:07:06] nope [19:07:06] https://gerrit.wikimedia.org/r/#/c/174452/ [19:07:15] silly clipboard [19:10:00] http://doctrine-common.readthedocs.org/en/latest/reference/caching.html [19:12:56] https://github.com/doctrine/cache/tree/master/lib/Doctrine/Common/Cache [19:24:29] <^d> Hi Chad, [19:24:30] <^d> [19:24:30] <^d> My friend has an issue with hackers infultrating her apple iphone6. She has come across your email and requested that I touch base with you. [19:24:31] <^d> [19:24:34] <^d> She has been hacked since December, 2013 and the numerous phone calls and visits to apple geninus bars have resulted in no action being taken or problems resolved. Her passwords are constantly being changed, and the whole ordeal is quite tiresome and has affected every aspect of her life. [19:24:35] <^d> [19:24:37] <^d> Can you please advise me of the information that you require to offer assistance to my friend and help resolve this problem or alternatively phone . [19:24:39] <^d> [19:24:41] <^d> Your help is greatly appreciated. [19:24:43] <^d> [19:24:45] <^d> Regards [19:24:47] <^d> [19:25:27] * ^d sighs [19:25:33] Dear , please send your friend's bank account routing numbers to and they will help. [19:25:33] <^d> Dear , [19:25:49] <^d> I don't own an iPhone. [19:25:53] <^d> xoxo, [19:25:54] <^d> Chad [19:26:14] 3Librarization, MediaWiki-Core-Team: Librarization wishlist - https://phabricator.wikimedia.org/T1118#781727 (10aaron) I suppose, we can always tweak it. [19:26:28] <^d> Heh, I should start signing by wikitech-l e-mails xoxo, [19:27:00] Does that violate the safe spaces policy? [19:27:13] Kisses make spaces even safer. [19:34:34] 3Librarization, MediaWiki-Core-Team: Bring in elastica library through composer - https://phabricator.wikimedia.org/T1281#781760 (10Legoktm) [19:34:41] 3Librarization, MediaWiki-Core-Team: Bring in elastica library through composer - https://phabricator.wikimedia.org/T1281#22350 (10Legoktm) [19:39:03] Bring in via composer. [19:39:05] Yay [19:39:31] Bring in Krinkle to #mediawiki-core via composer. [19:39:40] What will become of this channel? [19:39:57] #sofware-previously-known-as-mediawiki-core [19:44:45] <^d> #collection-of-things [20:02:00] <^d> anomie: setCacheMaxAge() is "seconds to live" right? [20:02:52] ^d: Basically. It sets the relevant cache-control headers. [20:03:10] <^d> Yeah, I saw that but wasn't sure how the headers were interpreted. [20:03:14] <^d> Thx [20:03:24] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.3 [20:05:48] <^d> manybubbles: I just realized we had $wgSearchSuggestCacheExpiry set to 5 minutes, not 5 hours. [20:05:58] <^d> (seconds != minutes, it seems) [20:06:21] ^d: huh. fun. well no one is complaining [20:06:36] <^d> Yeah, well I was looking at lowering it from 5 hours to like 2 or 3. [20:06:38] we should still break the prefix search out into its own pool ocunter just in case [20:06:39] <^d> But it's 5 minutes. [20:06:42] nice [20:06:43] <^d> So I'm closing the bug :) [20:11:05] Krinkle: re caching, see the PSR draft standard -- https://github.com/php-fig/fig-standards/blob/master/proposed/cache.md [20:13:18] Krinkle: I think that https://github.com/tedious/Stash is the reference implementation for that draft [20:14:00] <^d> manybubbles: Could you add neverett+bugzilla to your list of e-mails in Phab so your old comments will get assigned to you? :) [20:14:11] bd808: Cool stuff. Thanks! [20:14:55] ^d: done [20:15:07] <^d> ty :) [20:23:45] <^d> bd808: I'm not a fan of that standard, seems bulky. [20:24:36] ^d: Standards are ... bulky. There is no clean room dev going on here. Instead someone is looking at 5-10 implementations and trying to define a common core. [20:25:08] This I think is both a real and and intellectual challenge for the MW dev community [20:25:46] The intellectual challenge is letting go of "lean and mean" and YAGNI to some extent [20:26:12] The real challenge is that due to the way we load things today we can't afford to add a lot of very bulky implementations [20:26:58] I've been thinking about MW and dependency injection and containers quite a bit. There are some huge challenges for us down that road. [20:28:34] Rendering the wiki content using a normal DI container to create object is not going to work as far as I can tell. Even with lazy factories we would end up setting up too many object that would not really be used I fear. [20:29:26] We may need to look at more of a service locator pattern and find ways to automatically generate stubs for many things [20:30:18] The biggest hurdle to a container I see is hooks and the way they work. [20:31:38] My personal take for later PSR ones is that one shouldn't feel too pressured to go with PSR unless there's a good reason for it. [20:31:40] To fire the hooks you need to instantiate all the code that could install a hook today. And that really means you have to fully load all extensions [20:32:26] SMalyshev: *nod* We are using one today (PSR-3) and even that is basically brand new [20:34:19] PSR-3 is good, but the cache one may not fit all use cases [20:35:57] <^d> bd808: https://github.com/php-fig/fig-standards/blob/master/proposed/cache-meta.md, sections "Naked Value" and "Weak Item" [20:36:10] <^d> I would've preferred one of those approaches personally. [20:37:24] Yeah, that's more BagOStuff like [20:39:03] I'm a loose typing and native data structure proponent most of the time I think. I lived in the strongly type (hinted) world of java and later learned that I liked python and php better. [20:39:28] (calling java strongly typed is ... not technically correct IMO) [20:39:43] <^d> Should we join php-fig? [20:40:18] I think it might not be a bad idea for somebody from mw-core to do that. [20:40:26] * bd808 does not volunteer [20:40:55] Maybe we should nominate robla. He has standards body experience. :) [20:40:57] * ^d joins another mailing list to lurk for awhile. [20:43:22] 3MediaWiki-Core-Team: Improve TransactionProfiler - https://phabricator.wikimedia.org/T1341#781887 (10aaron) [20:43:49] MediaWiki has potentially interesting challenges to consider in a standardization process. We are our own unique snowflake of a platform. Sometimes we are unique by accident of history but other times we have found and fixed really nasty problems in the naive implementation of a pattern/service. [20:44:34] And then there is the problem of scale. What works well enough for 99% of web products might not work at our request volume. [20:46:26] <^d> Luckily being a member doesn't mean you have to adopt all the PSRs :) [20:46:33] I don't think we should end up trying to be the systemd of PHP but I do kind of hope we can publish some libraries that are useful to the wider PHP dev community. [20:48:06] I would be willing to overlook the bad thing they did with opening braces if we could adopt PSR-1 + 2 :) [20:49:12] I nominate bd808 to be our representative to join php-fig [20:50:40] legoktm: shush you [20:50:55] * AaronSchulz looks at https://gerrit.wikimedia.org/r/#/c/174200/1 [20:51:01] You'll get me stuck in the middle of every religious war [20:51:10] anomie: so what kind of custom agent headers will be used? [20:51:53] AaronSchulz: Presumably the same kind of thing people use for their bots where User-Agent isn't locked down by a browser. [20:52:29] bd808: I found https://github.com/doctrine/cache which is pretty similar to bagostuff [20:54:24] anomie: browser bots? Is AWB still based on IE? [20:55:15] I thought it was more aimed towards javascript libraries that run in the browser? [20:55:18] AaronSchulz: My idea there was more complicated gadgets that the developers might want to use ApiFeatureUsage with (https://gerrit.wikimedia.org/r/#/c/174787/) [20:55:36] legoktm: That was what got me looking at the cache PSR. The only benefit I can think of for replacing BagOStuff would be to converge with a larger group of developers and hopefully make bringing in or exporting things from our code base easier. [20:56:17] legoktm: On a completely different but sort of related note, check out this little git hook I've been playing with -- https://phabricator.wikimedia.org/P107 [20:56:26] <^d> bd808: In PSR-2, I hate 4 spaces / no tabs. [20:56:35] <^d> Plus the newlines for { in methods/classes [20:56:49] ^d: I hate tabs. With a burning passion I hate tabs. [20:57:09] But yeah the K&R braces are not my favorite [20:57:19] * bd808 thinks that;s K&R style [20:57:30] ooh [20:57:39] that looks like a pretty useful hook [20:58:10] legoktm: Try it out for a while and see if you can make it blow up [20:58:28] If it seems stable we can put it MW-V and docs for using composer with git [20:59:45] does post-merge run if you do a git checkout somebranch ? [21:00:02] legoktm: I'm not sure. Needs testing [21:00:38] I was going to make a toy repo somewhere to mess with various scenarios to figure things like that out [21:00:47] but I of course haven't gotten around to it yet [21:01:05] I lost my weekend to hacking on the xhprof extension [21:04:07] bd808: it doesn't appear to, I added echo "hi"; to the post-merge hook, and went backwards a commit from master, and then git checkout origin/master and nothing showed up [21:04:23] manybubbles, are you joining? [21:05:26] legoktm: I think that use case would require a post-checkout hook -- https://github.com/git/git/blob/master/Documentation/githooks.txt#L149 [21:06:49] hmm [21:07:09] do most people use git pull? I think I might have a non-standard setup [21:29:23] ^d: can you make a phab board for wikibase indexing [21:32:22] ? [21:45:35] <_joe_> manybubbles: whenever I'm done with my current almost-100%-hhvm schedule, I'd be happy to assist with the graphdb work... when do you think ops work will be needed? [21:46:20] _joe_: I don't think we're ready for *work*- mostly because we haven't settled on a technology yet- but we could always use opinions [21:46:36] <_joe_> manybubbles: ok, good [21:46:46] It might make more sense to start on making sure cassandra is ready for restbase [21:46:59] <_joe_> he [21:47:08] just in case our technology relies on cassandra [21:47:20] or, if it doesn't, than at least it won't be a total waste [21:47:25] <_joe_> well I just tried to raise a flag about cassandra in prod [21:47:35] <_joe_> gwicke is confident restbase will be low traffic [21:48:01] <_joe_> so well, we don't have a good working knowledge of cassandra in production TBH [21:54:38] ori: https://phabricator.wikimedia.org/T1194 only happens with the custom regex patch right? [21:59:25] AaronSchulz, ^d, bd808: mwcore [22:00:19] ori: {{done}} [22:05:15] 3MediaWiki-Vendor, MediaWiki-Core-Team: Security review of Plancake e-mail parser library - https://phabricator.wikimedia.org/T74956#782574 (10bd808) [22:07:14] 3Librarization, MediaWiki-Vendor, MediaWiki-Core-Team: Bring in elastica library through composer - https://phabricator.wikimedia.org/T1281#782576 (10bd808) [22:35:36] _joe_: pusher was a perfectly good word, I was just riffing on an old Steppenwolf song that says that a dealer is a nice guy and a pusher is a monster. [22:35:47] <_joe_> oh ok [22:36:00] <_joe_> I thought it was some out-of-fashion slang [22:36:19] bd808: fyi https://gerrit.wikimedia.org/r/#/c/175453/ [22:36:48] wtf? [22:37:07] that was ori's reaction :P [22:37:36] I'm ok with it for 1.24. 1.25 will not work well with that sort of change. :/ [22:37:58] We did not get around to using composer.json for anything valuable in 1.24 [22:38:37] I don't think it makes sense for 1.24. [22:38:49] it doesn't make sense, he should revert at once [22:39:12] If it should be moved to .sample, it should be done in git, with a proper discussion and through the proper review process [22:39:43] Plus, we're just making it harder for people to migrate to 1.25 [22:40:32] Tim proposed a revert previously and Tyler -2'd. I'm not sure what hexmode is doing here honestly. [22:42:21] bd808: Tim's revert was https://gerrit.wikimedia.org/r/#/c/138531/ which was about the libraries, not the file location [23:18:46] manybubbles: I'm liking the orientdb APIs so far from reading [23:19:09] * AaronSchulz also likes how it comes with a Grateful Dead song graph ;) [23:20:12] TimStarling: I'm a bit confused by your comment that you wouldn't have expected the change to use the procedural API to work because it still passes around Tidy objects. Even tidy_parse_string() returns a Tidy object, so it's not possible to use tidy and completely avoid Tidy objects AFAIK. Is the difference that the retval is not part of the function signature and hence the zend_parse_arguments() issue is elided? [23:21:35] I didn't expect you to actually try to use that internal tidy [23:21:56] I posted an update to the mailing list describing work in progress [23:22:27] yes, tidy_parse_string() returns a tidy object, that is what I was saying, obviously it doesn't work [23:23:17] I said on the mailing list that tidy_repair_string() appears to work [23:23:26] 3Mobile-Apps, Language-Engineering, Scrum-of-Scrums, Phabricator, Research-and-Data, Editing, MediaWiki-Core-Team, Multimedia, Zero, Mobile-Web, Services, Engineering-Community, Parsoid, Release-Engineering, Wikidata, WMF-Design, Core-Features: Create team projects for all teams participating in scrum of scrums -... [23:23:36] although that was a very preliminary test of a build that I had just completed [23:25:34] yeah, I didn't take that to mean that you were done; I just thought it'd be useful to provide some testing feedback [23:27:33] The reply and the one-word -2 ("Premature.") were a bit harsh, in my opinion. I put that review up to make it trivial for you to reproduce the test failure; I wasn't looking to merge it. If I had made it a draft, other people wouldn't have been able to view it. I guess I could have indicated it in the commit message or self--1'd or something. [23:28:44] but anyhow, I was (and continue to be) highly appreciative of the time and energy you are putting into this, and if there are things I can do to assist, just let me know. [23:29:59] <^demon|headache> Ugh, my head has been killing me *all freaking day* [23:30:37] ^demon|headache: boo. I have headache days [23:30:43] s/have/hate/ [23:32:16] I just got a donation banner o.O [23:32:40] on an arbcom case page no less [23:32:55] legoktm: Did you donate? WMF needs money to send me to more hackathons! [23:33:37] <^demon|headache> The real question is: what were you doing reading an arcbom case. [23:33:45] "Now is the time to ask. If everyone reading this right now gave $3, our fundraiser would be done within the hour. Yep, that's about the price of buying a programmer a coffee." [23:34:03] <^demon|headache> Oh man I got it too just now [23:34:21] ^demon|headache: it's election season! [23:34:36] <^demon|headache> lol, arb elections. [23:37:21] ^demon|headache: does CR help headaches? ;) [23:37:35] <^demon|headache> link? [23:57:06] <^demon|headache> greg-g: manybubbles added that e-mail earlier today, waiting on the cron :) [23:57:20] ^demon|headache: :) [23:57:28] ^demon|headache: ugh, didn't know you had a headache, sorry man [23:57:43] <^demon|headache> Just one of those days. [23:57:48] <^demon|headache> I'll live :) [23:58:58] 3Librarization, MediaWiki-Core-Team: Test monolog logging provider in beta - https://phabricator.wikimedia.org/T845#783068 (10bd808) https://gerrit.wikimedia.org/r/#/c/175604/