[02:23:20] noob question: what db do our continuous integration phpunit tests run against? The reason I ask is functions like RevisionStoreRecordTest::newRevision have id values like "17", "11", "7", etc. How does the test writer know to use those particular ids vs some other magic number? [02:23:44] Mysql (possibly mariadb) [02:26:07] bpirkle: it's a clean, duplicated database. Maybe that test inserts rows into the revision table in a specific order? [02:26:15] Right, sorry I wasn't clear. I meant what tables/data/ I see bits in MediaWikiTestCase like "setupDatabaseWithTestPrefix" and "useTemporaryTables", but I'm not sure I grok it all yet, and before I spent hours digging, thought I'd just ask :) [02:26:50] tables will the normal database tables [02:27:47] legoktm: thanks - so that particular test can manage its own ids because it gets a fresh copy to play with? [02:28:43] basically yep [02:28:51] I think #1 might be taken by the main page though [02:29:17] great, thank you [14:12:29] bpirkle: The runs on zuul/jenkins install a fresh wiki (i.e. running maintenance/install.php), which will have a mostly empty database based on maintenance/tables.sql. Then, local or zuul/jenkins, MediaWikiTestCase clones those tables' structure as temporary tables so the tests run with a mostly-empty database (absent a few basic entries like one revision for "UTPage" by user "UTSysop", I think). Then tests add insert whatever data they need, [14:12:29] hence the low ID values. But note the tables often aren't cleared between tests, and when they are cleared it's often just certain tables (e.g. page and revision but not recentchanges) mentioned in $this->tablesUsed. So occasionally you'll run into weird issues based on exactly which tests ran in which order (in which case the answer is generally to find which test needs additional tables listed in $this->tablesUsed). [14:36:29] anomie: thank you, that makes sense [16:28:32] <_joe_> uhm, who's supposed to be the maintainer of WikimediaEvents? [16:29:37] https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/graphs/contributors [16:29:43] Erik and Ori? :P [16:45:02] <_joe_> yeah extension.json says ori, matt flaschen and Benny Situ [16:47:42] Krinkle, Catrope and Addshore next [16:48:00] I deny everything. [16:48:02] huh? [16:48:06] i also deny everything [16:48:10] YOU SHOULD [16:48:29] _joe_: Are you asking who should merge your patch? :P [16:48:44] <_joe_> ahahahah [16:48:47] <_joe_> ok [16:48:55] Perf takes a special interest in that repo because it's very perf sensitive (all pages all users etc.) [16:48:58] <_joe_> yes something like that [16:49:01] tragedy of the commons ;) [16:49:11] I usually +1 and a peer from the team that wrote the patch tends to merge [16:49:11] <_joe_> Krinkle: you just said it's yours ;) [16:49:21] <_joe_> Krinkle: ack, ok, will do [16:49:22] :D [16:49:37] * addshore runs away singing [16:49:50] _joe_: Or just CR+2 it yourself and claim temporary insanity [16:50:50] <_joe_> Reedy: I am very careful with +2 since I have it everywhere, but I doubt someone from my team will be able to give a meaningful +2 to that patch [16:50:50] Reedy: just for you -- https://tools.wmflabs.org/bash/quip/AWkv3Va5fM03vZ1o8I75 [16:51:15] _joe_: CR+2 "I don't understand javascript" [16:51:45] <_joe_> so, yeah, if I shouldn't self-merge, I'm shopping for some +2 :P [16:52:37] CR+1 + CR+1 + CR+1 == CR+1 [16:56:11] Reedy: why do most of my quips include you? https://tools.wmflabs.org/bash/search?p=0&q=addshore [16:56:48] addshore: Reedy has a possie [17:10:16] I don't mind +2ing it ('twas ever thus) but I had a few comments [17:13:36] <_joe_> ori: re: cookie expiration [17:13:44] <_joe_> mass expiration is really not an issue [17:14:33] <_joe_> but yeah, simpler :) [17:15:44] honestly the version I liked best was your initial one, with 'expires: 7' [17:15:59] <_joe_> ori: the reason to have a function there is so it's not calculated on every page view but only on demand [17:16:24] <_joe_> I don't see how a cookie saying "I'll use php7" is deanonymizing [17:16:34] <_joe_> given we don't keep track of the session server-side [17:16:42] yes, exactly [17:16:54] just go with that, to be honest [17:17:04] <_joe_> and we have a large enough volume of requests not to really mean much [17:17:09] <_joe_> milimetric: ^^ what do you think? [17:17:35] WMF-Last-Access is explicitly there for tracking and data analysis [17:17:41] this cookie is a different story [17:18:19] _joe_: it's not the "I use php7" that matters here, it's the "this is the first time I accessed a wiki today" [17:18:37] but like I said it's a minor point, nobody will freak out if you do expire: 7 [17:18:52] <_joe_> right, it would be better if we added the seed cookie too [17:19:12] <_joe_> because with this version, your cookie will expire with your current browser session [17:19:13] What was the decision on maintainer for WikimediaEvents? I want to update https://www.mediawiki.org/wiki/Developers/Maintainers :) [17:19:26] greg-g: FYI: I get 'TypeError: Cannot read property 'UniversalLanguageSelector' of undefined' on https://en.wikipedia.org/wiki/Nancy_Pelosi [17:19:39] <_joe_> greg-g: apparently you [17:20:36] <_joe_> milimetric: in fact, expiry doesn't mean much at all at this point, it will just tell people at what hour you started your browsing session, and on what day [17:20:45] <_joe_> yeah lemme remove that for now [17:20:54] <_joe_> we can revisit once I've added the other cookie [17:21:06] _joe_: I think it will be precise down to the second [17:21:19] I'll be back in ~30 minutes and can +2 then, but there isn't really a need to wait on me [17:21:38] <_joe_> milimetric: yeah with "hour" i meant "second" [17:21:46] yeah, I can +2 without the expiry as well, if you want [17:21:51] <_joe_> which makes you part of a group of several thousand people [17:22:14] <_joe_> I'm resubmitting that patch [17:22:54] <_joe_> greg-g: if you notice, no one answered to me "I'm the maintainer" ;) [17:23:49] <_joe_> milimetric: that would be great, thanks :) [17:23:58] <_joe_> I need to go afk now, will be back later [17:45:26] milimetric: Hm.. I thought leaving the time precision was an issue? [17:46:03] Krinkle: it's a minor issue, and it sounded like they wanted to go ahead without it for now and add fuzzing later [17:46:09] when they add the other cookie? [17:46:35] I don't think we need fuzzing here. It only affects logged-out secondary page views and the code re-computes and re-adds as needed. [17:47:01] The expiry is just to make sure it doesn't hang around too long. It's still spread out given it's not a fixed date. [17:47:26] What problem are we trying to solve with fuzzing? [17:47:41] it would snap all sessions from one day to expire at the same time, fuzzing would take care of that, randomly expiring them throughout the same day [17:48:56] It would mean that for the subset of people in the sample, the subset of that who's cookie actually stayed as long as the TTL, the subset of that who after that expiry visit the site in a given minute, will use HHVM for 1 page view. [17:49:41] Is there a problem? [17:52:32] I don't see a big problem either way [17:52:52] it would be nice if the cookie wasn't precise to the second [17:52:58] so the question is how to do that [17:53:33] expireAtEndOfDay means it would snap all people in the sample to expire at the same time, potentially messing with the results a bit (I don't know, ori and _joe_ seemed to think this was a problem) [17:54:22] so ori's suggestion to do something like expireFuzzy made sense, it would expire people in the sample at 6 days + some fuzzy number of hours [17:55:24] it seemed like everyone was in agreement but that _joe_ wanted to get this +2-ed soon, and I didn't feel strong enough about this to block that [17:55:25] <_joe_> with the current patch, i don't expect the cookie to survive a weeek [17:55:58] ^ why not? How's this cookie getting expired otherwise? Server-side? [17:55:58] <_joe_> the sampling will happen again every time mw.user.getSessionId() changes [17:56:07] ah, ok [17:56:29] I see, then the fuzzy thing is not an issue [17:56:50] so the expireAtEndOfDay logic would be fine to fix the expire precision concern [17:56:57] <_joe_> now, for here there are two ways to go: 1 - we check if the cookie is present, and if present we skip the re-doing the extraction [17:57:04] <_joe_> 2 - add a second cookie [17:57:41] <_joe_> for which I already have a patch, but I'm thinking we should just go if hasCookie { return;} [17:58:34] <_joe_> so extraction will only happen if the cookie is unset, hence once a week for every user [17:58:38] _joe_: I thought you didn't want to leave existing cookies alone because of being able to raise/increase sampling factor [17:58:58] But I suppose if we only go in one direction, and absence isn't stored, it could work. [17:59:26] <_joe_> Krinkle: yes, rolling back the percentage is a problem with 1) [17:59:34] <_joe_> so no, let's not do it :) [17:59:45] it will mean though that in theory sampling factor 0.1 would increase slowly to be more and more over time, except of course, it won't because browsers quite regularly clean up cookies before 7 days, and also 7 days still expires. [17:59:54] what is 1) [18:00:14] (1 - we check if the cookie is present, and if present we skip the re-doing the extraction) [18:00:19] <_joe_> not doing the extraction if the cookie is present [18:00:21] Right [18:00:25] OK. Got it. [18:00:27] <_joe_> so yes, it's a bad idea [18:00:44] <_joe_> say we get to 10% of users and realize there is a catasptrophic bug [18:00:46] storing both in a cookie like your draft patch does seems fine. [18:00:56] Then we'd just update the routing logic to ignore the cookie. [18:00:56] <_joe_> we want to be able to go back fast [18:01:10] including for beta users and everyone. [18:01:20] Noting that they depend on a successfull pageview to get the JS. [18:01:23] i mean you can just ignore the cookie server-side, no? [18:01:39] index.php, load.php a lot of code :) [18:02:10] I thought I checked that in one of my comments - otherwise yeah, it's a problem, because you may not get a successful pageview [18:02:55] <_joe_> Krinkle: how is mw.config populated in js? [18:03:41] <_joe_> I guess it gets refreshed in the cache every time we sync CommonSettings.php ? [18:03:43] _joe_: it has two layers, the layer being used for this code in WME/php7 is from load.php?modules=startup [18:04:18] No, it's cached for 5 minutes in Varnish and then IMN request asks MW if it changed via E-Tag [18:04:38] <_joe_> sweet, it works [18:04:39] A lot of it isn't actually related to wmf-config. [18:05:01] it's more mw.randomKeyValuePairsFromPhp [19:55:57] * MaxSem just discovered that E:Configure had been archived on wiki. Shall we archive the repo too, or that was premature? [20:21:58] MaxSem: https://phabricator.wikimedia.org/T185227 "Sunset/archive Configure extension?" :) [20:26:38] legoktm: did it feature in your plans? ^ [21:44:03] the SoS notes say "Product plan for new HTTP API" for CPT, is that public? [21:45:29] same for splitting RESTBase, is that a conversation that exists on Phab? [21:55:32] https://xkcd.com/927/ [22:50:45] ori: sorry for the delayed reply, I don't see that in my console output for that page (I have some deprecation warnings, and had some other errors with a badly formed personal common.js ;) ) [23:17:46] MaxSem: I would be shocked if Configure still loads