[00:00:06] Anyhow, I just copied it over from the old repo because that one had the same acces setting alreadsy. [00:00:16] That should be set at a higher level then so it inherits properly, shouldn't need to do it everywhere :) [00:00:33] Anyway, I'm just bikeshedding, I don't really care all that much :) [00:01:08] https://gerrit.wikimedia.org/r/#/q/owner:Krinkle+branch:refs/meta/config [00:01:15] ostriches: Controversial. Legacy. [00:01:23] But yeah, you have my support :) [00:02:03] Now if only I had the spare time or actually cared enough to bother cleaning it up :p [00:02:34] (this query only shows the ones where I had the change go through code-review first) [00:02:53] because gerrit doesn't index the other commits etc. [00:39:22] I actually learned recently that you can craft a submission url that will automatically apply CR+2/V+2/Submit *when creating the revision* [00:39:43] So you don't have to create, then review (even if you do that in a loop, it's still two calls) [00:40:49] https://gerrit.wikimedia.org/r/Documentation/user-upload.html#auto_merge [00:41:20] Basically, provided you have Submit (not +2, actual Submit) on a repo, you can go ahead and submit bypassing the review rules [02:36:52] ori: has there been any progress on making the pingback data publicly available? Should we still be including it in 1.28 in its current state? [02:40:00] Legal needs to approve it before the data is made available, but it should absolutely be included in 1.28, at least in my opinion. It's not plausible that Legal would veto release of that data. At most a field would need to be redacted or the data slightly transformed in some way. [02:49:42] The inline documentation for $wgPingback states that "The Wikimedia Foundation shares this data with MediaWiki developers to help guide future development efforts", which is not true yet. It might make sense to change "shares" to "plans to share", at least for now. [02:51:38] EventLogging data access is already available to folks who have signed an NDA, so there is a path for interested parties [02:55:32] It's a bit crummy of me to have left this process incomplete (by not going through the legal review process) and I'm tempted to take it on now. But I also know myself and I know I have bad discipline and poor follow-through when it comes to protracted, e-mail-heavy processes -- and that's in the best of times -- and I have a lot going on right now. So I probably don't have what it takes to see it through, at least not right now. [02:58:24] legoktm: would you be up for it, perhaps? [03:00:15] legoktm: I was thinking about moving mw.org infobox data to wikidata, but I see you are doing that already [03:00:27] is that an experimental thing, or a full-swing project? [03:05:46] it would open up some cool possibilities for auto-generated documentation [03:22:01] ori: I also have a little too much on my plate right now. :/ maybe a follow up email to wikitech-l asking someone to take on that responsibility? [03:24:00] tgr: Well, I did it once, and based on the data in extension.json. It was mostly experimental because I didn't have time to follow through, I just uploaded the scripts (https://github.com/legoktm/pywikipedia-scripts/commit/4bf4f37e841a3586f8010ee19d5fb8a558448a46) if you want to continue on with it. My original idea was that once the data is structured in Wikidata, we could have ExtensionDistributor use WDQS to provide a searchable/sortable list [03:24:00] of extensions [03:25:04] I thought I had sent an email about that somewhere, but I can't find anything [03:26:09] is there already discussion about it on Wikidata? [03:27:00] https://www.wikidata.org/wiki/Wikidata:MediaWiki.org "TODO" oops [03:32:30] ori: oh also if you could fill out the TODO FIXMEs on https://www.mediawiki.org/wiki/Manual:$wgPingback that would be helpful [20:33:21] ( ! ) Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/wiki/mediawiki/core/includes/libs/objectcache/MemcachedBagOStuff.php on line 70 [20:33:23] WHYYYYYY [20:33:40] refresh and it's fine [20:34:16] FOUC on login, on my dev wiki on the local network [20:46:01] Reedy: does the Phabricator repo name have to be changed separately? [20:46:34] https://phabricator.wikimedia.org/r/revision/mediawiki/extensions/PageViewInfo.git is not found, https://phabricator.wikimedia.org/r/revision/mediawiki/extensions/WikimediaPageViewInfo.git is broken [20:47:58] Krinkle: could you lock down the WikimediaPageViewInfo repo? the files have been removed now [20:48:15] tgr: I think it just needs creating or something so it propogates [20:56:28] tgr: Looks like it's already set to "read only" [20:56:52] ah, cool, thanks [21:05:50] I wonder if I should just move sessions to redis... [21:07:45] is it related to memcached? it could be that something else is slow and memcache just happens to be the code that is running when the timeout limit is reached [21:08:12] ResourceLoader, maybe, if it causes FOUC [21:34:19] If i run mctest via watch... [21:34:19] 127.0.0.1:11211 set: 100 incr: 100 get: 100 time: 0.037830114364624 [21:35:22] the machine is mostly idle [21:36:31] tgr|away: I seme to be getting various cache related problems [21:38:25] It could be 16.10 related....