[09:34:47] Reedy: Could you enable Special:JavaScriptTest on test2wiki ? [09:34:52] http://test2.wikipedia.org/wiki/Special:JavaScriptTest/qunit [09:35:04] It used to be possible to use it, but in 1.20 its moved into a special page disabled by default [09:35:51] in the future there may be unit tests that "do" stuff with the API, so its right to be disabled by default but for now it'd be useful to have. [09:43:26] Krinkle: what variable is it hidden behind? [09:43:53] $wgEnableJavaScriptTest [09:43:57] (boolean) [09:44:18] Ta [09:45:54] Krinkle: done [09:45:56] thx [09:46:59] Oh nice, I didn't know there were deployed extensions that make use of the new js testing framework hooks [09:47:14] http://test2.wikipedia.org/wiki/Special:JavaScriptTest/qunit also runs MobileFrontend tests and beta_opensearch [09:48:35] GET http://test2.wikipedia.org/w/tests/qunit/data/callMwLoaderTestCallback.js?133456967240253914 404 (Not Found) [09:48:39] aha [09:49:00] Nice [09:49:15] I suppose that has no uncontroversial quick fix? [09:49:38] only 2 tests currenty fail, the test of mw.loader.load on a file from ./tests/data [09:49:42] ./tests/qunit/data * [09:49:51] good to know everything else is passing [09:49:59] Lol, more tests fail if you do ?debug=true [09:50:29] hm.. not for me? [09:50:32] which one [09:51:06] 3 core, 5 MF [09:51:16] ah, indeed [09:51:22] mediawiki: mw.loader (2, 0, 2) [09:51:28] mediawiki: mw.loader.bug30825 (1, 1, 2) [09:51:31] Looks like the MF test is executing code outside the test runner scope, in the global scope [09:51:34] mediawiki.util: addCSS (1, 2, 3) [09:51:49] that's not gonna work, I doubt it ever did run correctly in normal mode. [09:52:00] http://test2.wikipedia.org/wiki/Special:JavaScriptTest/qunit?debug=true&filter=mediawiki [09:52:09] ^ only runs mediawiki.* tests, not jquery or extensions [09:53:03] MF application.js is loaded twice [09:53:13] and MF fixtures.js as well [09:53:16] hm. [09:53:33] Log a bug then throw stuff at preilly [09:53:46] yeah [09:54:31] btw, I merged "mwdumper" product in BugZilla into a new component "mwdumper" under "Tools". it only had 30 bugs and 1 "general" component. [10:28:28] Reedy: btw, there is one other thing that imho should block deployment to commons unconditionally. I couldn't find Roan but it's quite important [10:28:28] https://bugzilla.wikimedia.org/buglist.cgi?priority=Highest&priority=High&priority=Normal&list_id=107848&bug_severity=blocker&bug_severity=critical&query_format=advanced&target_milestone=1.20&product=MediaWiki [10:28:33] https://bugzilla.wikimedia.org/show_bug.cgi?id=34669 [10:29:22] that one must be fixed before wider deployment, no way around it. that'll break lots of @imported gadgets css or @imported user css (which is very common, especially on commons) [10:30:22] WTF just happened to mediawiki.org? [10:30:25] So far Roan and I haven't been able to find a work-around, we may have to figure out a way to back it out of master [10:30:38] working fine here Nikerabbit , what up? [10:30:45] all the chrome is missing [10:30:54] well, missing styles [10:31:00] layout css/js is loaded fine here [10:31:05] 404 error? [10:31:07] check console [10:31:18] 503 service unavailable [10:31:37] for bits? [10:31:41] yup [10:31:49] ah, cleared cache [10:31:50] getting it too now [10:31:55] https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=en&modules=ext.wikiLove.local&skin=vector&version=2012123 [10:32:03] I have the same for different url [10:32:03] Guru Meditation: [10:32:04] XID: 2067739114 [10:32:22] #wikimedia-tech [10:32:50] hmm, right, this is not wikimedia-tech ;) [10:38:37] Reedy: I've sent this memoserv to Roan, sharing with you as well since you are probably around tonight during deployment prep (I gotta go soon) [10:38:41] -/ms send RoanKattouw We can *not* deploy to commons today unless https://bugzilla.wikimedia.org/34669 is given a magic solution, or the whole css-concat thing backed out of master. Lots of gadgets and users use @import to cross-wiki load css. [10:39:29] Krinkle: need to notify robla too [10:39:51] I'll send engineering@ in a minute [10:39:54] cheers [10:45:09] Reedy: done [13:48:49] New patchset: Hashar; "testswarm: set $wgServer to use relative protocol" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/5018 [13:49:53] New review: Hashar; "(no comment)" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/4752 [14:34:57] ^demon: hi :-D [14:35:03] -l10nuser = "L10n-bot" [14:35:03] +l10nuser = "L10n-bot (l10n-bot@translatewiki.net)" [14:35:04] \o/ [14:35:11] <^demon> Yeahhhh [14:35:12] <^demon> :) [14:35:56] ^demon: hmm right time to flood people [14:35:59] you could have used if options.uploader.startswith( hookconfig.l10nuser ) [14:36:06] congrats anyway :] [14:36:10] <^demon> I could've :) [14:36:27] going to commit extension l10n updates [14:38:00] <^demon> We haven't silenced bot output yet, so I'll silence gerrit-wm in #mediawiki for a bit [14:40:16] Submodule 'extensions/AllTimeZones' (ssh://l10n-bot@gerrit.wikimedia.org:29418/mediawiki/extensions/AllTimeZones.git) registered for path 'extensions/AllTimeZones' [14:40:19] No '.gitreview' file found in this repository. [14:40:27] can we make sure all extensions get .gitreview when created? [14:42:20] Most people do [14:42:23] moment [14:42:59] would also be nice if new extensions were announced :) [14:43:16] <^demon> Done for AllTimeZones, 5023. [14:43:53] <^demon> Reedy: Approve plz ^ [14:44:30] ya [14:45:37] doned [14:53:11] mm I need to make the export script faster [14:55:27] What part of it is slow@ [14:55:27] ? [14:57:09] <^demon> Probably MySQL. It's not webscale. [15:02:04] Should examples have a .gitreview? [15:02:28] Reedy: it's serialized [15:02:47] load data from database, process it, write file, repeat all over again thousands of times [15:02:53] Ahhh [15:03:09] plus I had to reclone my checkout to have consistent state [15:03:59] which is even slower I think [15:04:03] <^demon> Reedy: Yeah probably :) [15:04:13] * Reedy fixes [15:06:44] ahh [15:09:17] I guess all those queries should be indexed.. [15:09:34] Though, I'd probably be better reverting out those revisions for @import first.. [15:16:31] I see 7 revs to revert [15:19:55] Reedy: you can unmute gerrit bot for now, it will take many minutes before I'm ready to commit [15:20:34] we could make gerrit hook to not send any message on l10n bot commit [15:22:53] <^demon> Nikerabbit: Unmuted. Let me know when you're ready. [15:23:00] <^demon> hashar: That's the plan, I just didn't get to it Friday. [16:07:41] ^demon: okay I have export ready, just needing to iterate over and commit [16:07:56] already checked some diffs and they were correct [16:08:06] <^demon> Bot quieted. [16:08:50] ^demon: we're going to increase gerrit commit id pretty fast this way [16:09:20] <^demon> Numbers are irrelevant :) [16:10:05] ^demon: I presume they're not using tinyint? ;) [16:10:18] <^demon> I don't know what the field is, offhand. [16:10:31] <^demon> https://gerrit.wikimedia.org/r/Documentation/dev-design.html#_scalability is kind of interesting. [16:11:39] A 24 core server is able to handle ~25 concurrent git fetch operations per second. [16:13:26] <^demon> `change_id` int(11) NOT NULL DEFAULT '0', [16:13:31] <^demon> So I think we'll be fine for awhile :) [16:14:11] <^demon> All the tables are MyISAM. We should fix that. [16:14:21] 99,999,999,999 [16:18:12] and nice spam in my inbox [16:18:39] <^demon> Rules are a must if you watch projects in gerrit. [16:23:10] ^demon: I don't assume that there is someone always around to mute gerrit-bot [16:23:20] lol, no [16:23:29] As he said, we can add a hook so it doesn't make noise [16:26:17] https://gerrit.wikimedia.org/r/#q,status:merged,n,z [16:26:18] Lol. [16:27:48] <^demon> Nikerabbit: Yeah I know. I just didn't get to it Friday. [16:29:19] * Reedy runs many updates [16:29:46] uh [16:29:53] One cannot turn off mails from gerrit? [16:30:25] I don't want any mails to l10n-bot account [16:31:43] <^demon> There's a workaround here. [16:32:25] <^demon> Nikerabbit: The issue is http://code.google.com/p/gerrit/issues/detail?id=989 [16:32:32] <^demon> I'll set L10n's preferred e-mail to '' [16:33:56] ^demon: you can do that? [16:34:07] <^demon> Directly in the database. [16:34:10] <^demon> It's the workaround ;-) [16:34:41] <^demon> Oh wait, you have to push. [16:34:42] <^demon> Crap. [16:34:46] <^demon> I don't know if that will work. [16:34:55] <^demon> Hmm. [16:53:05] hoi rsterbin [16:53:41] I was discussing the stage 3 specs with Aaron and Oliver [16:54:56] and one more request came up for the 1% sampled init events: do you think we would be able to break down these events by protection status? [16:55:26] this data point would be particularly helpful for the analysis of the 4E group [16:55:58] I'll bring this up during the AFT call at 11 pt but I wanted to give you the heads up [17:09:59] DarTar: we should consider giving the learn-more version of option 4 a different name (like option 5) [17:13:04] Nikerabbit, ^demon|away, what would happen if you set two emails to the account? [17:13:12] then set the main one to '' and leave the alias [17:15:51] <^demon|away> That could possibly work too. I'll look when I get back. [17:17:31] Reedy: RoanKattouw is looking over your stuff now and is around to help out [17:17:40] * RoanKattouw cleans up Reedy's revert [17:18:38] Clean it up? It was a direct revert of all the revisions [17:18:44] The only thing that conflicted was release notes :p [17:20:30] Did you notice you changed .gitreview ? :P [17:20:43] I'm just gonna wrap the relevant code in if(false) [17:21:51] RoanKattouw, Reedy, robla: we have a mobile frontend deployment scheduled for this afternoon - will the main sites still be running 1.19 or will you guys be finishing up the 1.20 rollout today? [17:22:11] Many will be still on 1.19 [17:22:38] RoanKattouw: look at what I changed, it's its own fault for being sucky [17:22:40] is the plan to have everything on 1.20 next monday? [17:22:49] awjr: http://wikitech.wikimedia.org/view/Software_deployments#Week_of_April_16 [17:23:18] robla: thanks :) i had that open but somehow wasn't registering the 1.20 deployments... [17:24:01] I'm not sure what defaultremote=origin does and why/if it's bad [17:24:11] But you're welcome to fix that in a separate commit :) [17:24:20] It's when git-review mentions a numerous load of unrelated changes [17:24:21] RoanKattouw is implementing the "if(false)" feature flag [17:24:34] Oh that [17:24:49] shell bug 40345: "Implement 'false' feature on foowiki" [17:25:28] http://lists.wikimedia.org/pipermail/wikitech-l/2012-April/060093.html [17:25:41] $wgDisableThisFeature [17:27:03] rsterbin: yes, I thought of that [17:27:38] right now I am creating these extra long prefixes which I could probably avoid [17:28:25] the other question is, regardless of the event prefix, is it possible to count sampled inits based on protection status for all buckets? [17:28:52] i'm not sure what that means [17:29:52] so, right now we count a 1% sample of all init events by bucket [17:30:12] optionS3_*-init [17:30:37] it's not by-bucket in any way [17:30:40] the question is: can we count separately inits on regular pages vs protected pages [17:30:42] it's just 1% of everything [17:31:04] hmm wait a sec, it is by bucket, no? [17:31:20] you mean you want 1% of inits on regular pages and some other percentage of inits on protected pages? [17:31:26] optionS3_1E-init, optionS3_4E-init, optionS3_0X-init [17:31:27] it's always been 1% of all inits [17:31:33] yes [17:31:35] no, I mean: [17:32:01] 1% for all init events, but add a flag for init events triggered on protected pages [17:32:21] or to be more precise [17:32:34] we could leave the current events the same [17:32:35] so you just want to change the format, and percentage stays the same? [17:32:48] but then add three separate event types [17:33:19] optionS3_1E-protected-init, optionS3_4E-protected-init, optionS3_0X-protected-init [17:33:25] yeah, sure [17:33:30] well... [17:33:32] maybe [17:33:38] :) [17:33:43] i'd need to check with roan on how to do it [17:33:56] right now i've got a method that determines whether the user can access the page [17:34:09] but it doesn't check whether the page is "protected" [17:34:21] oh that would be enough [17:34:23] how are we defining protected? [17:34:43] we really want to know whether the page is editable or not by the user accessing it [17:34:47] so you want optionS3_1E-protected-init if the page is protected AND the user doesn't have access? [17:35:15] I'd keep it simple, [17:35:18] i'd recommend another tag, because that's not what it sounds like it means [17:35:26] agreed [17:35:50] optionS3_1E-noedit-init [17:35:51] ? [17:36:07] we probably don't want to have detailed data about protection, just write-access for the current user [17:36:12] yeah something like that [17:36:24] ok [17:36:47] where are you keeping the most up-to-date clicktracking specs? [17:37:07] http://meta.wikimedia.org/wiki/Research:Article_feedback/Clicktracking#Stage_3_.28Impact_on_engagement.29 [17:37:27] no mention of this change to init events yet as I wanted to discuss it with you first [17:37:42] RoanKattouw: you should've just abandoned mine [17:37:50] Reedy: OK can do that too [17:38:14] Your 2 line change seems much easier ;) [17:38:24] RoanKattouw_away: filed your SSN application? [17:38:28] Heh yeah that's why I was frowning so much [17:38:29] i think calling the learn-more version 5 instead of 4 is going to be much simpler [17:38:38] DarTar: Indeed I did. Should have the card in the mail in 7-10 days [17:38:39] since that's what we do for ctas -- it's a different id in the db [17:38:44] * RoanKattouw_away goes upstairs for brunch now [17:39:19] rsterbin: the problem is that right now prefixes refer to buckets, not designs [17:39:35] so if I want to have aggregate counts per bucket I can still grep on the prefix [17:39:44] ah [17:40:16] actually, since option 4 never results in feedback, we don't have to worry about the db. duh. [17:40:28] if we introduce an option 5E things are going to get messy, despite the shorter prefix [17:40:32] correct [17:40:38] alrighty [17:41:16] i'll go with what you've got on that page [17:41:27] shall I add the noedit events then? [17:42:28] sounds good [17:42:44] k let me do it [17:46:43] done [17:47:48] the svn server seems to be unreachable [17:50:09] mmmm [17:50:42] mutante ^ [17:50:49] wrong channel [17:50:49] fail [17:57:17] hey kaldari, can you look at this : https://bugzilla.wikimedia.org/show_bug.cgi [17:57:23] i think we can close this [17:57:50] bad url [17:58:12] https://bugzilla.wikimedia.org/show_bug.cgi?id=16752 [17:58:13] sorry [18:12:35] RoanKattouw_away: here's the commit to fix up: https://gerrit.wikimedia.org/r/#change,4707 [18:16:52] drecodeam: unfortunately, can't test it since svn is down :( [18:17:29] kaldari: i know that it has been executed [18:17:41] Upload Wizard already uses File API and multi select [18:17:58] er sorry, I guess UploadWizard in is Git now [18:18:18] ohh ya, it is on git now [18:19:21] I need to set up the git version locally [18:36:33] kaldari: should be fixed [18:41:06] Reedy: so i should close it right ? [18:41:33] Close what? [18:42:17] Reedy: you were mentioning this bug : https://bugzilla.wikimedia.org/show_bug.cgi?id=16752 [18:42:32] I wasn't [18:42:48] Reedy: sorry, i thought you were mentioning to that bug. [19:03:27] drecodaem: unfortunately, I have meetings most of today, but I might be able to take a look later [19:03:34] drecodeam [19:04:06] kaldari: thats fine. Its not an urgent issue either ways [20:01:30] New review: Demon; "(no comment)" [integration/jenkins] (master); V: 1 C: 2; - https://gerrit.wikimedia.org/r/4360 [20:02:41] New review: Demon; "(no comment)" [integration/jenkins] (master); V: 1 C: 2; - https://gerrit.wikimedia.org/r/5018 [20:02:44] Change merged: Demon; [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/5018 [20:08:23] anybody know why the resource loader would stop loading modules from an extension [20:08:24] ? [20:09:02] i've got two modules -- with debug=true, it loads one of them; with debug=false it loads none [20:09:15] my only outstanding changes are to the js files themselves [20:09:41] i would love to get an error message from somewhere so i can fix this [20:32:23] rsterbin: That's quite strange -- no error messages in the console? [20:33:52] nope [20:34:17] hmm [20:34:28] There's a couple things youcan do [20:34:38] i found the issue -- stupid syntax error [20:34:43] oh ok :) [20:34:50] but it really should have told me about it instead of just disappearing [20:35:23] there's got to be a better way than brute-forcing it by commenting out chunks to see if it reappears [20:39:50] I don't know why it would suppress your syntax errors ,that's strange [20:59:01] * robla logs out of IRC momentarily [22:21:40] sup Krinkle? [22:21:54] TrevorParscal: BTW can I get a review of https://gerrit.wikimedia.org/r/5135 ? [22:22:06] TrevorParscal: RoanKattouw ##mediawiki-ve [22:29:26] RoanKattouw: i'm about to do a MobileFrontend deployment but noticed there's no documentation about updating the extension for 1.20wmf sites [22:29:41] at least not in the how to deploy code article - is it possibly documented somewhere else? [22:32:59] <^demon|away> No, it isn't. [22:41:46] <^demon|away> awjr: I just saw 5136, you figured it out :) [22:44:32] robla: WikiEditor revert deployed, cache rebuild for the message change (preference messages came back but weren't in cache) is in progress [22:48:48] https://wikitech.wikimedia.org/view.php?title=Wikitech:URL_layout [22:48:56] Wow, I never knew it ws using view.php [22:49:07] I suppose its from before actionPaths were in core? [22:49:26] hm.. or not [22:52:17] view.php ?!? [22:53:00] yeah [22:53:15] I don't know why but it's implemented that way [22:53:38] Alias /edit /var/www/wikitech/edit.php [22:54:00] https://wikitech.wikimedia.org/history.php?title=Wikitech:URL_layout [22:55:45] <^demon|away> Krinkle: Because it was done years ago and nobody's going to touch it since it works :) [22:55:55] <^demon|away> As for why, ask brion :p [22:56:11] well, history.php onitself doesn't work apparently, mw goes back to action=view [22:56:23] but it does still include index.php [22:56:54] and MediaWiki doesn't look at $_REQUEST, so setting it doesn't do anything [22:57:02] the reason /history/ works is because of action paths [22:57:06] hehe, funny [22:57:13] it might as well symlink to index.php [22:57:41] <^demon|away> Back in the day we might've used $_REQUEST for that. [22:58:03] yeah, and back then action paths was only to generate the links, not to interpret the request [22:58:17] so the alias has to either set action=... or link to a php file that sets $_REQUEST [22:58:54] mediawiki no longer looks at $_REQUEST but it still works because in the mean time mediawiki has changed to also used action paths to interpret the incoming request url [23:00:45] Krinkle, it's actionpaths, but done with alias scripts instead of rewrite rules [23:00:55] it's kinda messy, but made some kiknd of sense at the time :D [23:01:12] yeah, I think right now the line in view.php and history.php that sets $_REQUEST is effectively a no-op [23:01:35] but yeah, at the time.. [23:01:49] <^demon|away> We could give brion shell access to fix it :p [23:01:55] https://wikitech.wikimedia.org/view/User:Brion