tag as a result of a redirect? [01:37:16] <RoanKattouw> hmmm [01:37:32] <RoanKattouw> You may be right [01:37:37] <RoanKattouw> I am not entirely sure it was always like that [01:38:25] <RoanKattouw> Nope, it works the same in my 1.18 wiki [02:14:20] <Emw> which interface of imagemagick is used by wikimedia's mediawiki deployments? there are roughly a dozen different interfaces for different languages listed at http://www.imagemagick.org/script/index.php. i guess i'd assume it'd be one of the two PHP interfaces (magickwand or imagick), but i don't know, and i've never done anything with imagemagick. [07:46:52] <ToAruShiroiNeko> hello [09:07:40] <petan|wk> ToAruShiroiNeko: hi [09:12:36] <ToAruShiroiNeko> hello petan [09:12:42] <ToAruShiroiNeko> petan, who would be the right person to contact for https://bugzilla.wikimedia.org/show_bug.cgi?id=22521 ? [14:38:47] <Svick> hi, i noticed that the API module stashimageinfo doesn't behave like other prop querymodules (doesn't take titles, it's not usable from generator). It seems to me that the only reason it's this way is that its class inherits from imageinfo, which is a prop module [14:39:16] <Svick> do you think stashimageinfo should be made into a regular module (not querymodule) [15:27:33] <Svick> hi, i noticed that the API module stashimageinfo doesn't behave like other prop querymodules (doesn't take titles, it's not usable from generator). It seems to me that the only reason it's this way is that its class inherits from imageinfo, which is a prop module [15:27:35] <Svick> do you think stashimageinfo should be made into a regular module (not querymodule)? [15:31:02] <BobTheWikipedian> got an issue: http://en.wikipedia.org/wiki/Special:Import doesn't support moves from outreach.wikimedia.org/ [15:45:00] <BobTheWikipedian> can anyone assist me with a special:import issue? [16:05:07] <Reedy> BobTheWikipedian: It's not supposed to let you import from anywhere [16:05:46] <BobTheWikipedian> hmmm. is there a way i can move a page from outreach to enwiki then aside from cut-paste? [16:07:04] <Reedy> Special:Export [16:07:15] <BobTheWikipedian> thanks, i'll have a look at that :) [16:34:15] <^demon> Ugh, where be Roan? [16:58:12] <vvv> ^demon: offline, I assume [16:58:28] <^demon> Thank you :) [17:17:26] <sumanah> Hi 20% checkin folks! [17:17:55] <sumanah> (Trevor, Brion) [17:17:57] * sumanah checks [17:18:27] <sumanah> and Roan. [17:18:30] <robla> Trevor is ooo today [17:18:36] <sumanah> Yes [17:18:39] <sumanah> And ill! [17:18:41] <sumanah> Poor guy [17:18:58] * sumanah awaits Brion & Roan [17:27:13] <sumanah> hi RoanKattouw [17:27:36] <sumanah> am I right in presuming that your 20% time priority today will be work on fixing issues discovered in the en.wp deployment? [17:28:00] <RoanKattouw> I mostly did my 20% time yesterday, due to happenstance [17:28:13] <sumanah> oho [17:28:13] <sumanah> ok [17:28:18] <sumanah> have a good day! [17:28:21] <RoanKattouw> And due to lack of VE team presence [17:28:23] <RoanKattouw> :) [17:28:24] <RoanKattouw> But [17:28:31] <RoanKattouw> I will still be finishing my presentation slides [17:29:18] <sumanah> YAY [17:30:38] <rmoen> sumanah: hi, what's on your list for me today ? [17:30:50] <sumanah> hi rmoen [17:31:01] <sumanah> are you all done with the extension review you did? [17:31:27] <rmoen> Yes [17:32:06] <sumanah> rmoen: https://bugzilla.wikimedia.org/buglist.cgi?keywords=patch-need-review%2C%20&query_format=advanced&keywords_type=allwords&list_id=110518&resolution=---&product=MediaWiki [17:33:06] <sumanah> rmoen: skim through and pick a few to look at in an area you feel adequate in? many of them you'll just reject because they are obsolete or bad [17:33:26] <rmoen> ok [17:37:09] <sumanah> rmoen: there's also https://bugzilla.wikimedia.org/show_bug.cgi?id=30101 and 43 other patches awaiting review re extensions we deploy -- do you feel confident reviewing Vector patches, as a first pass guy? [17:38:14] <rmoen> sumanah: Sure [17:38:21] <sumanah> Thanks rmoen [17:58:04] <Ryan_Lane1> robla: bug 36135 looks like a mediawiki configuration issue [17:58:23] <robla> !b 36135 [17:58:23] <mw-bot2> https://bugzilla.wikimedia.org/show_bug.cgi?id=36135 [18:00:11] <RoanKattouw> That is an MW issue yes [18:00:32] <RoanKattouw> Petr says they switched to "the same caching system as production" but he doesn't "have the script to rebuild the cache" [18:00:37] <RoanKattouw> I'll talk to him on the bug [18:00:56] <Ryan_Lane> ok [18:05:36] <^demon> RoanKattouw: Do yours and Brion's tests (https://gerrit.wikimedia.org/r/#q,status:open+project:mediawiki/core+branch:wmf/1.20wmf1,n,z) still need to exist or can I abandon them? [18:05:55] <RoanKattouw> You can kill them [18:05:59] <RoanKattouw> Sorry for not cleaning up after myself [18:06:07] * ^demon grabs the nuclear football [18:06:16] <RoanKattouw> That perms stuff is all sorted out now, only wmf-deployment can +2 in the wmf/* branches [18:07:22] <vvv> Oh [18:07:25] <vvv> Git experts! [18:07:31] <vvv> How do I share a branch? [18:07:53] <RoanKattouw> I've been wanting to set up permissions so you can just push to anything that's not master [18:07:56] <RoanKattouw> But I don't think that's done yet [18:08:36] <RoanKattouw> vvv: Tell me the name of your branch and the branch point (i.e. the SHA1 of the newest commit it has in common with master) and I'll set it up for you [18:08:43] <RoanKattouw> We need a better process though [18:09:28] <vvv> RoanKattouw: I do not need it right now, but I intended to make use of it in future [18:09:55] <vvv> By settings up do you mean the gerrit's admin interface feature? [18:10:08] <vvv> Like, the one in Admin -> Projects -> projectname -> Branches? [18:10:20] <RoanKattouw> Yes [18:10:26] <RoanKattouw> You may or may not be allowed to create branches there [18:10:48] <vvv> I see [18:10:57] <RoanKattouw> I need to change the perms so that you can create and push to arbitrary branches, github-style, and only select branches (master and wmf/*) are restricted [18:11:23] <vvv> And then, if branch is set up, I just check out it and do git-review to push it? [18:11:30] <vvv> *push to it [18:12:41] <RoanKattouw> For now yes [18:13:20] <^demon> RoanKattouw: If you allow direct pushes to refs/heads/* but deny for refs/heads/master it *should* work [18:13:50] <RoanKattouw> Yeah, I know the meaning of "should" [18:13:59] <^demon> :) [18:14:04] <RoanKattouw> So I'm gonna test that before I implement it [18:14:10] <vvv> RoanKattouw: so, the wmf branches are still used right now? I thought I read some plans about making updates directly from master [18:14:28] <^demon> We still need a wmf branch as a practical matter, that's not changing. [18:14:41] <RoanKattouw> Yes [18:14:41] <^demon> But with biweekly deploys, it should match master much more closely than we've done in the past. [18:14:49] <RoanKattouw> But we're cutting new wmf/* branches every two weeks [18:15:01] <RoanKattouw> And we cut them from master [18:15:17] <vvv> And how they are called now? 1.20.3wmf? [18:15:26] <^demon> 1.20wmfN [18:16:20] <vvv> And I guess it even fetches the $wgVersion from branch name automatically, or something like that? [18:16:52] <RoanKattouw> No, we still have to update that by hand [18:17:00] <^demon> $wgVersion is tweaked in DefaultSettings in the wmf branch. [18:17:01] <^demon> The branch maker script updates that. [18:17:31] <Eloquence> Why can't I pull up Change-ID Ifed2a3a0d9d7a957b52e165c4d8d29f428a18f5c in Gerrit? [18:17:45] <RoanKattouw> Looking [18:17:58] * vvv wonders what is the point of Change-IDs [18:18:07] <RoanKattouw> Eloquence: It doesn't find it, but what is it supposed to point to? [18:18:15] <Eloquence> 72969cf8c9a403430c8c93fc20ab3118328c4d9c [18:18:18] <Eloquence> in core [18:18:42] <RoanKattouw> Gerrit can't find that hash either [18:18:44] <RoanKattouw> But Ican [18:18:46] <Eloquence> yeah, me too [18:19:02] <Eloquence> I've noticed from time to time that Gerrit doesn't get matches where it should [18:19:11] <RoanKattouw> Probably because it's in the wmf/1.20wmf1 branch and it was pushed bypassing review [18:19:17] <^demon> I know gerrit won't match on merge commit hashes. [18:19:27] <RoanKattouw> It's not a merge [18:19:38] <RoanKattouw> But I think it's a direct push to the wmf branch [18:19:40] <^demon> Ah, if you bypassed review it won't show up in gerrit. [18:19:44] <^demon> It will show up in gitweb, however. [18:19:48] <RoanKattouw> Speaking of which, I think we should start disallowing that [18:19:52] <Eloquence> is it in the branch? when I do git show 72969cf8c9a4 --decorate it doesn't show it as being in any branch [18:20:13] <^demon> RoanKattouw: Agreed, if we've got +2 rights sorted then there's no reason to push skipping review. [18:20:22] <RoanKattouw> Eloquence: I see it as being in the wmf/1.20wmf1 branch [18:22:02] <Eloquence> hmz, any idea why it wouldn't locally show it to me as such? it doesn't come up for me on git log wmf/1.20wmf1 either [18:22:13] * vvv just noticed that Git uses developers' local time in logs [18:22:24] <RoanKattouw> Eloquence: It does for me [18:22:35] <RoanKattouw> catrope@roanLaptop:~/mediawiki/git/core (wmf/1.20wmf1)$ git log wmf/1.20wmf1 | grep 72969cf8c9a403430c8c93fc20ab3118328c4d9c [18:22:36] <RoanKattouw> commit 72969cf8c9a403430c8c93fc20ab3118328c4d9c [18:22:55] <RoanKattouw> Eloquence: Try git log origin/wmf/1.20wmf1 maybe? [18:23:35] <Eloquence> right [18:23:38] <^demon> vvv: That way everyone can pretend the world revolves around them :) [18:23:48] <Eloquence> ok, so direct pushes don't generate gerrit records [18:24:10] <^demon> No, that's known behavior. And why doing direct pushes is harmful. [18:24:35] <vvv> ^demon: I love it. Now it actually shows that most of my commits are done around 4 AM! [18:25:21] <^demon> Eloquence: It's why we disallow direct pushes for anything we deploy. We only did direct pushes for the wmf branch temporarily because we had a permissions problem with pushing-for-review. [18:25:41] <Eloquence> got it [18:26:12] <RoanKattouw> I will fix this today [18:26:21] <^demon> A couple of extensions opted for direct pushing, but that's their prerogative if we're not deploying it. I personally find it harmful. [18:27:48] <Eloquence> they may not be fully aware of the side effects [18:27:55] <vvv> True [18:27:59] <vvv> I did not know [18:28:07] <vvv> And it is not mentioned on the migration page [18:28:19] <vvv> At least it was not back then [18:28:19] <robla> given how badly it breaks gerrit, we should probably approximate the behavior with SloppyApproveEverything bot [18:28:43] <Eloquence> is there a fast way to search a change-ID locally? pickaxe is very slow [18:29:06] <^demon> robla: I tried to avoid opening that can of worms. But considering the alternative... [18:29:34] <^demon> Eloquence: No, it's just a part of the commit message. [18:29:44] <robla> direct pushing seems like it has more worms wriggling out of the can [18:29:53] <Eloquence> yeah, I figured. this makes me wonder how useful change-IDs are for referring to stuff [18:30:05] <Eloquence> right now we have a wild mix of change-IDs, commit SHA-1s, gerrit integers, all over the place [18:30:14] <Eloquence> e.g. see server admin log [18:30:22] <vvv> I also wonder about bugzilla [18:30:23] <Eloquence> commit SHA-1s are at least fast and native [18:30:31] <vvv> Like, before you closed the bug and said "FIXED" [18:30:32] <Eloquence> and can be searched in gerrit with commit:foo [18:30:47] <robla> vvv: which bug? [18:30:58] <vvv> robla: abstract [18:31:01] <^demon> vvv: I think we should wait on changing it to FIXED until it's merged to master. [18:31:07] <vvv> I am not sure how the bugs should be closed [18:31:21] <vvv> And I also believe there should be some nice way to associate a bug with merge request [18:31:30] <robla> yeah, that would be nice [18:31:44] <^demon> Actually, there's some cool syntax we can use in commit messages that make it searchable in gerrit. [18:31:57] <^demon> You can do a footer field like "bugzilla: 123" which will make gerrit index it. [18:32:20] <Eloquence> mh, is that a generic feature? Could it be used for tags/labels? [18:32:38] <^demon> No, it's for issue trackers. [18:32:41] <Eloquence> k [18:32:47] <^demon> I don't know if it's constrained to integers though. [18:32:51] <^demon> Worth checking. [18:32:54] <vvv> I hope it is not so cool you get a frostbite from it [18:33:38] <^demon> of course being a part of the commit summary it becomes immutable once it's merged. [18:35:39] <^demon> robla: Oh, another big reason why skipping gerrit is harmful: meta-repos filled with submodules (ie: extensions.git) won't update unless you push through gerrit. [18:35:48] <^demon> So extensions skipping review skip updating the meta repo :( [18:35:49] <RoanKattouw> Argh! [18:36:07] <RoanKattouw> OK yeah that's a good reason [18:36:15] <^demon> So yes, I think we need to totally fix this. Nobody should skip gerrit. [18:36:32] <vvv> Wait, are there submodules in extensions.git? [18:36:37] <^demon> But I guess we'll have to write up some more hook code for people who *really really* don't want code review. [18:36:38] <robla> here comes SloppyApproveEverything bot! :) [18:36:52] <DarTar> bsitu: sending a note to Fabrice, Howie and Giovanni, suggesting that Friday 4 could be a good day to work on this, ok? [18:37:09] <vvv> ^demon: what about development-time branches which are hidden from gerrit, then pushed together into review? [18:37:09] <^demon> vvv: When we upgrade to 2.3, there will be. 2.3 introduces "auto updating submodules" so the meta-repo will always keep track of the submodules' latest commits. [18:38:04] <bsitu> DarTar: yeah, that's fine [18:38:10] <DarTar> cool [18:38:21] <^demon> vvv: That wouldn't change? [18:38:38] <vvv> ^demon: well, what about direct-pushing them? [18:38:59] <^demon> Direct pushing to those branches is no big deal. The meta-repo is only tracking master. [18:39:46] <RoanKattouw> Gerrit still wouldn't be able to find some of those commits though I guess [18:40:35] <^demon> Why would you be searching the history of a development branch from within gerrit if it never pushed-for-review? [18:40:41] <^demon> I think we're on an edge case here :) [18:44:53] <^demon> robla: Although, if people have +2/Submit permissions on their own extensions, do we really need to muck things up with an auto-approve bot? Why not just +2 & Submit? [18:45:47] <robla> ^demon: maybe not a bot, but is it possible to streamline that with a hook to automatically do that? [18:46:04] <^demon> I mean yes, it can be done by a hook (it's what we do for L10n). [18:46:22] <^demon> But I don't *like* the practice. Code should at least pretend to be reviewed. [18:47:07] <robla> ^demon: if the choice is between that or direct push, I'll take the hook [18:47:47] <^demon> But why not push and then submit? What's wrong with the manual step? It requires someone to acknowledge that code is going in to the repo. [18:48:00] <^demon> Rather than commit-then-flee which we've encouraged for too long IMHO. [18:48:58] <robla> ^demon: if we're talking about code where we've got a lot of reviewers (like stuff being pushed to WMF), then I agree [18:49:05] <RoanKattouw> OK, direct push to wmf/* is now disallowed [18:49:19] * RoanKattouw updates docs [18:49:32] <robla> but if we're talking about single maintainer extensions, it's just busywork to make them poke buttons in the web ui [18:49:43] <robla> ...and it makes them resent the switch to gerrit more [18:49:51] <^demon> Not many extensions have opted in to it so far. [18:50:10] <^demon> So even with non-wmf stuff, extensions are still pushing for review. [18:52:09] <^demon> Anyway, it'll need to be a bot. I don't want to have to put in gerrit config changes every time someone opts in/out of this. [18:54:10] <Eloquence> RoanKattouw, the invisible-to-Gerrit change we looked at earlier, would I be able to view it through a gerrit URL with the legacy ID? or would it not come up there either? [18:54:33] <RoanKattouw> No, you'd have to use gitweb [18:54:47] <RoanKattouw> It won't even have been /assigned/ a four-digit ID [18:55:03] <Eloquence> right [18:55:55] <^demon> RoanKattouw: Now that we've got jenkins running regularly for core, do you think we can revoke V+1 permissions on mediawiki/core now? [18:56:24] <RoanKattouw> ^demon: I have mixed feelings about that. There need to be people with the ability to bypass Jenkins if it's broken [18:56:43] <robla> ^demon: maybe we can just call it "ClownyBot". I love the idea of seeing "ClownyBot: looks good to me, approved" in gerrit :) [18:57:01] <vvv> What are the plans for Jenkins integration for extensions? [18:57:19] <^demon> Ask hashar? [18:57:24] <RoanKattouw> ^demon: So at least some humans (admins and wmf-deployment at least) need to retain V+1 rights IMO [18:57:27] * vvv asks hashar [18:57:49] * hashar figures out an answer [18:57:57] <^demon> RoanKattouw: Yeah, breaking that down per-branch would be kind of annoying. We can leave it for now. [18:58:02] * RoanKattouw would like PHP linting for extensions too [18:58:14] <^demon> And just wait for our glorious continuously integrated future ;-) [18:58:39] <RoanKattouw> ^demon: It doesn't need to be broken down per-branch as far as I'm concerned, I'm just saying that we can't take V+1 away from all humans and only give it to bots [18:58:48] <hashar> vvv: there is no plan yet for extensions. Will surely do whenever the wmf branch is available in git [18:58:59] <^demon> Um, it is? [18:59:08] <RoanKattouw> hashar: "wmf branch is available in git" ---> what do you mean by that? [18:59:10] <hashar> I have no idea [18:59:23] <^demon> We've been deploying from the wmf branch for the last week :p [18:59:32] <hashar> ohh [18:59:34] <hashar> \o/ [18:59:55] <hashar> so been busy with discovering the beta labs and trying to get testswarm to works somehow :-] [19:00:01] <^demon> https://gerrit.wikimedia.org/r/#q,project:mediawiki/core+branch:wmf/1.20wmf1,n,z [19:00:02] <^demon> :) [19:00:34] <hashar> so I need to figure out how to inject mw configuration per branch [19:00:45] <hashar> then generate a job [19:01:01] <hashar> ahaha [19:01:10] <vvv> By the way, we had some automated JS test suite, right? [19:01:27] <RoanKattouw> For core, yes [19:01:32] <hashar> House M.D. is not broadcasted tonight :-] [19:02:51] <vvv> I wanted something to go over Wikimedia wikis and check if their JS is broken [19:03:05] <RoanKattouw> Oh that [19:03:39] <vvv> That would be helpful in sense that we could find broken JS in general and especially when it is broken after deployment [19:06:03] <RoanKattouw> Yes, very [19:10:18] <raindrift> Hey, RoanKattouw. Quick question. You may recall that we talked about making a custom RL module for backbone templates. I'm making that now, based roughly on stuff that's in ResourceLoaderFileModule. I'm wondering, though: should I instead just subclass ResourceLoaderFileModule so I can use all its internal file access methods, or would that break a bunch of stuff? [19:10:45] <raindrift> Like, I could just override getScript and getModifiedTime [19:11:10] <raindrift> … or I could subclass ResourceLoaderModule and reimplement the file-reading stuff. Either is fine. [19:13:13] <RoanKattouw> I figured you may not want to subclass RLFileModule because there's so much specific cruft in there [19:16:19] <raindrift> RoanKattouw: yeah… mostly I'm wondering if there are other methods besides getScript and getModifiedTime where I'll want the default implementation? [19:17:34] <RoanKattouw> raindrift: BTW your shell access just got approved :) [19:17:40] <RoanKattouw> Looking at the default implementations [19:18:09] <RoanKattouw> You would want a different constructor [19:18:15] <RoanKattouw> supportsURLLoading() would break [19:18:31] <raindrift> Hm. Okay. I think I'll just subclass ResourceLoaderModule then. [19:18:37] <RoanKattouw> getScriptURLsForDebug() too [19:18:40] <Amgine> Beta 2 is released! get your free beta version of the Wiktionary Mobile app here! hurry before they're all gone! http://lists.wikimedia.org/pipermail/wiktionary-l/2012-April/001121.html [19:18:47] <RoanKattouw> Yeah I'm 1/5th through and it's not looking pretty, so you should do that [19:18:57] <raindrift> Sounds like a plan. Thanks for your help! [19:31:30] <gerrit-wm> New patchset: Hashar; "testswarm sqlite db is now writable by others" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/5737 [19:31:49] <^demon> Oh man, this is cool. [19:31:51] <gerrit-wm> New review: Hashar; "I know it is lame but that is all I can afford right now :-(" [integration/jenkins] (master); V: 1 C: 2; - https://gerrit.wikimedia.org/r/5737 [19:31:52] <^demon> RoanKattouw: `ssh -p 29418 gerrit.wikimedia.org gerrit stream-events` [19:31:54] <gerrit-wm> Change merged: Hashar; [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/5737 [19:32:56] <RoanKattouw> ^demon: Yeah I'm aware of that, the Gerrit Trigger Plugin uses it [19:33:01] <RoanKattouw> I have never actually look at it though [19:33:26] <^demon> It's just a json stream of events happening in gerrit. [19:33:38] <^demon> Super useful if anyone wanted to consume that data for bots, etc. [19:38:07] <hashar> so somehow [19:38:16] <hashar> I though Linux / ant / Jenkins would be smart [19:38:29] <hashar> and honor the g+s sticky bit I have set on a directory [19:38:32] <hashar> I Was wrong :-((( [19:38:48] <hashar> ends up doing a ugly "anyone can write" hack :-( [19:48:59] <hashar> so I think I *might* have testswarm fixed up a bit [19:49:17] <hashar> finally found out what was causing all tests to timeout :-( [19:50:18] <hashar> ^demon: http://integration.mediawiki.org/testswarm/job/1974/ \O/ [20:20:09] <RoanKattouw> preilly: What does var_dump($wgSessionStarted); print? [20:21:06] <preilly> RoanKattouw: bool(false) [20:24:16] <Nikerabbit> hashar: wwhat was it? [20:51:56] <chrismcmahon> mdale in regards to TMH, what exactly is "real time stream switching"? [20:52:21] <mdale> it means switch stream and seek to the time you left off at [20:52:56] <chrismcmahon> mdale: do you have an example? [20:53:34] <mdale> like your watching the webm 480 video then you press fullscreen.. then you may want to switch it to 720P version [20:53:42] <mdale> but continue where you left off [20:55:06] <chrismcmahon> mdale: got it thanks [20:55:28] <mdale> np [21:27:29] <[Bergi]> hello! [21:27:36] <sumanah> hello [21:28:17] <sumanah> Reedy: so, re https://bugzilla.wikimedia.org/show_bug.cgi?id=22911 , would you move it to the Deployment Queue? I presume that I shouldn't do so and that the release manager should [21:28:27] <[Bergi]> I just got an ERR_TOO_BIG Wikimedia error for a 500-titles api request. That's OK. [21:28:27] <[Bergi]> The question is: How long are URIs allowed? [21:29:23] <RoanKattouw> Hmm, that would be a Squid config thing I guess [21:29:59] <RoanKattouw> [Bergi]: As a workaround, you can also use POST [21:30:36] <[Bergi]> Yes, it seems there is a special error file for the "ERR_TOO_BIG" squid error id. But where can I find that squid config file? [21:30:56] <RoanKattouw> I asked in the operations channel [21:31:06] <RoanKattouw> I'm also curious to know as to what the limit is [21:31:19] <RoanKattouw> OK that's not correct English but you know what I meant :) [21:31:54] <[Bergi]> RoanKattouw: Yeah, POST seems to be the better way. But i'm also curious about :-) [21:37:49] <Reedy> sumanah: This somewhat reminds me of http://lists.wikimedia.org/pipermail/wikitech-l/2011-December/thread.html#56982 (or more so, the original private discussion) [21:39:22] <sumanah> Reedy: yup. In this case, the extension has gone through code review [21:41:12] <sumanah> raindrift: re http://lists.wikimedia.org/pipermail/wikitech-l/2011-December/thread.html#56982 - the notes you wrote up re deployment process, are they somewhere onwiki, maybe in your userspace? [21:42:03] <sumanah> Reedy: so, it's ready to go into the deployment queue, right? [21:46:24] <RoanKattouw> [Bergi]: The answer I got was "I think it's 8k but might only be 4k" [21:48:48] <[Bergi]> RoanKattouw: OK, thanks. That's at least the order of magnitude. Isn't there also a PHP $params length limit? [22:09:16] <RoanKattouw> [Bergi]: That's only for the # of titles though [22:09:43] <RoanKattouw> I don't think PHP itself cares about the length of the param string, that would be very annoying for POST [22:17:36] <[Bergi]> RoanKattouw: Right, that was only for query strings in some environments (http://www.mediawiki.org/wiki/Manual:$wgResourceLoaderMaxQueryLength) [22:18:15] <RoanKattouw> Ah yes [22:32:26] <preilly> RoanKattouw: can you take a look at https://gerrit.wikimedia.org/r/#change,5771 again

[00:53:17] I added a new section to the Git Workflow documentation called "How to amend someone else's unmerged code" since this seems to be a common task that is not obvious how to do. Hope it's helpful. [00:54:03] kaldari: It's exactly the same as https://www.mediawiki.org/wiki/Git/Workflow#Amend_your_change isn't it? [00:54:15] Except that you'd punch in a change number that belongs to someone else [00:54:22] this is for amending other people's changes [00:55:05] I know that [00:55:12] I am just pointing out that these two processes are identical [00:55:22] So now the Workflow page documents precisely the same thing twice [00:55:25] then the title for the section should be changed [00:55:35] Right [00:55:45] "Amending a change" I guess [00:56:13] * RoanKattouw fixes [01:14:58] what if we need to amend *two* changes? should we have an "Amending two changes" section? [01:15:05] (joking) [01:17:40] The answer to all of your questions is git rebase --interactive [01:18:08] * robla tries to figure out what to do with https://bugzilla.wikimedia.org/show_bug.cgi?id=36174 [01:36:39] is it possible we actually changed what is displayed in the tag as a result of a redirect? [01:37:16] <RoanKattouw> hmmm [01:37:32] <RoanKattouw> You may be right [01:37:37] <RoanKattouw> I am not entirely sure it was always like that [01:38:25] <RoanKattouw> Nope, it works the same in my 1.18 wiki [02:14:20] <Emw> which interface of imagemagick is used by wikimedia's mediawiki deployments? there are roughly a dozen different interfaces for different languages listed at http://www.imagemagick.org/script/index.php. i guess i'd assume it'd be one of the two PHP interfaces (magickwand or imagick), but i don't know, and i've never done anything with imagemagick. [07:46:52] <ToAruShiroiNeko> hello [09:07:40] <petan|wk> ToAruShiroiNeko: hi [09:12:36] <ToAruShiroiNeko> hello petan [09:12:42] <ToAruShiroiNeko> petan, who would be the right person to contact for https://bugzilla.wikimedia.org/show_bug.cgi?id=22521 ? [14:38:47] <Svick> hi, i noticed that the API module stashimageinfo doesn't behave like other prop querymodules (doesn't take titles, it's not usable from generator). It seems to me that the only reason it's this way is that its class inherits from imageinfo, which is a prop module [14:39:16] <Svick> do you think stashimageinfo should be made into a regular module (not querymodule) [15:27:33] <Svick> hi, i noticed that the API module stashimageinfo doesn't behave like other prop querymodules (doesn't take titles, it's not usable from generator). It seems to me that the only reason it's this way is that its class inherits from imageinfo, which is a prop module [15:27:35] <Svick> do you think stashimageinfo should be made into a regular module (not querymodule)? [15:31:02] <BobTheWikipedian> got an issue: http://en.wikipedia.org/wiki/Special:Import doesn't support moves from outreach.wikimedia.org/ [15:45:00] <BobTheWikipedian> can anyone assist me with a special:import issue? [16:05:07] <Reedy> BobTheWikipedian: It's not supposed to let you import from anywhere [16:05:46] <BobTheWikipedian> hmmm. is there a way i can move a page from outreach to enwiki then aside from cut-paste? [16:07:04] <Reedy> Special:Export [16:07:15] <BobTheWikipedian> thanks, i'll have a look at that :) [16:34:15] <^demon> Ugh, where be Roan? [16:58:12] <vvv> ^demon: offline, I assume [16:58:28] <^demon> Thank you :) [17:17:26] <sumanah> Hi 20% checkin folks! [17:17:55] <sumanah> (Trevor, Brion) [17:17:57] * sumanah checks [17:18:27] <sumanah> and Roan. [17:18:30] <robla> Trevor is ooo today [17:18:36] <sumanah> Yes [17:18:39] <sumanah> And ill! [17:18:41] <sumanah> Poor guy [17:18:58] * sumanah awaits Brion & Roan [17:27:13] <sumanah> hi RoanKattouw [17:27:36] <sumanah> am I right in presuming that your 20% time priority today will be work on fixing issues discovered in the en.wp deployment? [17:28:00] <RoanKattouw> I mostly did my 20% time yesterday, due to happenstance [17:28:13] <sumanah> oho [17:28:13] <sumanah> ok [17:28:18] <sumanah> have a good day! [17:28:21] <RoanKattouw> And due to lack of VE team presence [17:28:23] <RoanKattouw> :) [17:28:24] <RoanKattouw> But [17:28:31] <RoanKattouw> I will still be finishing my presentation slides [17:29:18] <sumanah> YAY [17:30:38] <rmoen> sumanah: hi, what's on your list for me today ? [17:30:50] <sumanah> hi rmoen [17:31:01] <sumanah> are you all done with the extension review you did? [17:31:27] <rmoen> Yes [17:32:06] <sumanah> rmoen: https://bugzilla.wikimedia.org/buglist.cgi?keywords=patch-need-review%2C%20&query_format=advanced&keywords_type=allwords&list_id=110518&resolution=---&product=MediaWiki [17:33:06] <sumanah> rmoen: skim through and pick a few to look at in an area you feel adequate in? many of them you'll just reject because they are obsolete or bad [17:33:26] <rmoen> ok [17:37:09] <sumanah> rmoen: there's also https://bugzilla.wikimedia.org/show_bug.cgi?id=30101 and 43 other patches awaiting review re extensions we deploy -- do you feel confident reviewing Vector patches, as a first pass guy? [17:38:14] <rmoen> sumanah: Sure [17:38:21] <sumanah> Thanks rmoen [17:58:04] <Ryan_Lane1> robla: bug 36135 looks like a mediawiki configuration issue [17:58:23] <robla> !b 36135 [17:58:23] <mw-bot2> https://bugzilla.wikimedia.org/show_bug.cgi?id=36135 [18:00:11] <RoanKattouw> That is an MW issue yes [18:00:32] <RoanKattouw> Petr says they switched to "the same caching system as production" but he doesn't "have the script to rebuild the cache" [18:00:37] <RoanKattouw> I'll talk to him on the bug [18:00:56] <Ryan_Lane> ok [18:05:36] <^demon> RoanKattouw: Do yours and Brion's tests (https://gerrit.wikimedia.org/r/#q,status:open+project:mediawiki/core+branch:wmf/1.20wmf1,n,z) still need to exist or can I abandon them? [18:05:55] <RoanKattouw> You can kill them [18:05:59] <RoanKattouw> Sorry for not cleaning up after myself [18:06:07] * ^demon grabs the nuclear football [18:06:16] <RoanKattouw> That perms stuff is all sorted out now, only wmf-deployment can +2 in the wmf/* branches [18:07:22] <vvv> Oh [18:07:25] <vvv> Git experts! [18:07:31] <vvv> How do I share a branch? [18:07:53] <RoanKattouw> I've been wanting to set up permissions so you can just push to anything that's not master [18:07:56] <RoanKattouw> But I don't think that's done yet [18:08:36] <RoanKattouw> vvv: Tell me the name of your branch and the branch point (i.e. the SHA1 of the newest commit it has in common with master) and I'll set it up for you [18:08:43] <RoanKattouw> We need a better process though [18:09:28] <vvv> RoanKattouw: I do not need it right now, but I intended to make use of it in future [18:09:55] <vvv> By settings up do you mean the gerrit's admin interface feature? [18:10:08] <vvv> Like, the one in Admin -> Projects -> projectname -> Branches? [18:10:20] <RoanKattouw> Yes [18:10:26] <RoanKattouw> You may or may not be allowed to create branches there [18:10:48] <vvv> I see [18:10:57] <RoanKattouw> I need to change the perms so that you can create and push to arbitrary branches, github-style, and only select branches (master and wmf/*) are restricted [18:11:23] <vvv> And then, if branch is set up, I just check out it and do git-review to push it? [18:11:30] <vvv> *push to it [18:12:41] <RoanKattouw> For now yes [18:13:20] <^demon> RoanKattouw: If you allow direct pushes to refs/heads/* but deny for refs/heads/master it *should* work [18:13:50] <RoanKattouw> Yeah, I know the meaning of "should" [18:13:59] <^demon> :) [18:14:04] <RoanKattouw> So I'm gonna test that before I implement it [18:14:10] <vvv> RoanKattouw: so, the wmf branches are still used right now? I thought I read some plans about making updates directly from master [18:14:28] <^demon> We still need a wmf branch as a practical matter, that's not changing. [18:14:41] <RoanKattouw> Yes [18:14:41] <^demon> But with biweekly deploys, it should match master much more closely than we've done in the past. [18:14:49] <RoanKattouw> But we're cutting new wmf/* branches every two weeks [18:15:01] <RoanKattouw> And we cut them from master [18:15:17] <vvv> And how they are called now? 1.20.3wmf? [18:15:26] <^demon> 1.20wmfN [18:16:20] <vvv> And I guess it even fetches the $wgVersion from branch name automatically, or something like that? [18:16:52] <RoanKattouw> No, we still have to update that by hand [18:17:00] <^demon> $wgVersion is tweaked in DefaultSettings in the wmf branch. [18:17:01] <^demon> The branch maker script updates that. [18:17:31] <Eloquence> Why can't I pull up Change-ID Ifed2a3a0d9d7a957b52e165c4d8d29f428a18f5c in Gerrit? [18:17:45] <RoanKattouw> Looking [18:17:58] * vvv wonders what is the point of Change-IDs [18:18:07] <RoanKattouw> Eloquence: It doesn't find it, but what is it supposed to point to? [18:18:15] <Eloquence> 72969cf8c9a403430c8c93fc20ab3118328c4d9c [18:18:18] <Eloquence> in core [18:18:42] <RoanKattouw> Gerrit can't find that hash either [18:18:44] <RoanKattouw> But Ican [18:18:46] <Eloquence> yeah, me too [18:19:02] <Eloquence> I've noticed from time to time that Gerrit doesn't get matches where it should [18:19:11] <RoanKattouw> Probably because it's in the wmf/1.20wmf1 branch and it was pushed bypassing review [18:19:17] <^demon> I know gerrit won't match on merge commit hashes. [18:19:27] <RoanKattouw> It's not a merge [18:19:38] <RoanKattouw> But I think it's a direct push to the wmf branch [18:19:40] <^demon> Ah, if you bypassed review it won't show up in gerrit. [18:19:44] <^demon> It will show up in gitweb, however. [18:19:48] <RoanKattouw> Speaking of which, I think we should start disallowing that [18:19:52] <Eloquence> is it in the branch? when I do git show 72969cf8c9a4 --decorate it doesn't show it as being in any branch [18:20:13] <^demon> RoanKattouw: Agreed, if we've got +2 rights sorted then there's no reason to push skipping review. [18:20:22] <RoanKattouw> Eloquence: I see it as being in the wmf/1.20wmf1 branch [18:22:02] <Eloquence> hmz, any idea why it wouldn't locally show it to me as such? it doesn't come up for me on git log wmf/1.20wmf1 either [18:22:13] * vvv just noticed that Git uses developers' local time in logs [18:22:24] <RoanKattouw> Eloquence: It does for me [18:22:35] <RoanKattouw> catrope@roanLaptop:~/mediawiki/git/core (wmf/1.20wmf1)$ git log wmf/1.20wmf1 | grep 72969cf8c9a403430c8c93fc20ab3118328c4d9c [18:22:36] <RoanKattouw> commit 72969cf8c9a403430c8c93fc20ab3118328c4d9c [18:22:55] <RoanKattouw> Eloquence: Try git log origin/wmf/1.20wmf1 maybe? [18:23:35] <Eloquence> right [18:23:38] <^demon> vvv: That way everyone can pretend the world revolves around them :) [18:23:48] <Eloquence> ok, so direct pushes don't generate gerrit records [18:24:10] <^demon> No, that's known behavior. And why doing direct pushes is harmful. [18:24:35] <vvv> ^demon: I love it. Now it actually shows that most of my commits are done around 4 AM! [18:25:21] <^demon> Eloquence: It's why we disallow direct pushes for anything we deploy. We only did direct pushes for the wmf branch temporarily because we had a permissions problem with pushing-for-review. [18:25:41] <Eloquence> got it [18:26:12] <RoanKattouw> I will fix this today [18:26:21] <^demon> A couple of extensions opted for direct pushing, but that's their prerogative if we're not deploying it. I personally find it harmful. [18:27:48] <Eloquence> they may not be fully aware of the side effects [18:27:55] <vvv> True [18:27:59] <vvv> I did not know [18:28:07] <vvv> And it is not mentioned on the migration page [18:28:19] <vvv> At least it was not back then [18:28:19] <robla> given how badly it breaks gerrit, we should probably approximate the behavior with SloppyApproveEverything bot [18:28:43] <Eloquence> is there a fast way to search a change-ID locally? pickaxe is very slow [18:29:06] <^demon> robla: I tried to avoid opening that can of worms. But considering the alternative... [18:29:34] <^demon> Eloquence: No, it's just a part of the commit message. [18:29:44] <robla> direct pushing seems like it has more worms wriggling out of the can [18:29:53] <Eloquence> yeah, I figured. this makes me wonder how useful change-IDs are for referring to stuff [18:30:05] <Eloquence> right now we have a wild mix of change-IDs, commit SHA-1s, gerrit integers, all over the place [18:30:14] <Eloquence> e.g. see server admin log [18:30:22] <vvv> I also wonder about bugzilla [18:30:23] <Eloquence> commit SHA-1s are at least fast and native [18:30:31] <vvv> Like, before you closed the bug and said "FIXED" [18:30:32] <Eloquence> and can be searched in gerrit with commit:foo [18:30:47] <robla> vvv: which bug? [18:30:58] <vvv> robla: abstract [18:31:01] <^demon> vvv: I think we should wait on changing it to FIXED until it's merged to master. [18:31:07] <vvv> I am not sure how the bugs should be closed [18:31:21] <vvv> And I also believe there should be some nice way to associate a bug with merge request [18:31:30] <robla> yeah, that would be nice [18:31:44] <^demon> Actually, there's some cool syntax we can use in commit messages that make it searchable in gerrit. [18:31:57] <^demon> You can do a footer field like "bugzilla: 123" which will make gerrit index it. [18:32:20] <Eloquence> mh, is that a generic feature? Could it be used for tags/labels? [18:32:38] <^demon> No, it's for issue trackers. [18:32:41] <Eloquence> k [18:32:47] <^demon> I don't know if it's constrained to integers though. [18:32:51] <^demon> Worth checking. [18:32:54] <vvv> I hope it is not so cool you get a frostbite from it [18:33:38] <^demon> of course being a part of the commit summary it becomes immutable once it's merged. [18:35:39] <^demon> robla: Oh, another big reason why skipping gerrit is harmful: meta-repos filled with submodules (ie: extensions.git) won't update unless you push through gerrit. [18:35:48] <^demon> So extensions skipping review skip updating the meta repo :( [18:35:49] <RoanKattouw> Argh! [18:36:07] <RoanKattouw> OK yeah that's a good reason [18:36:15] <^demon> So yes, I think we need to totally fix this. Nobody should skip gerrit. [18:36:32] <vvv> Wait, are there submodules in extensions.git? [18:36:37] <^demon> But I guess we'll have to write up some more hook code for people who *really really* don't want code review. [18:36:38] <robla> here comes SloppyApproveEverything bot! :) [18:36:52] <DarTar> bsitu: sending a note to Fabrice, Howie and Giovanni, suggesting that Friday 4 could be a good day to work on this, ok? [18:37:09] <vvv> ^demon: what about development-time branches which are hidden from gerrit, then pushed together into review? [18:37:09] <^demon> vvv: When we upgrade to 2.3, there will be. 2.3 introduces "auto updating submodules" so the meta-repo will always keep track of the submodules' latest commits. [18:38:04] <bsitu> DarTar: yeah, that's fine [18:38:10] <DarTar> cool [18:38:21] <^demon> vvv: That wouldn't change? [18:38:38] <vvv> ^demon: well, what about direct-pushing them? [18:38:59] <^demon> Direct pushing to those branches is no big deal. The meta-repo is only tracking master. [18:39:46] <RoanKattouw> Gerrit still wouldn't be able to find some of those commits though I guess [18:40:35] <^demon> Why would you be searching the history of a development branch from within gerrit if it never pushed-for-review? [18:40:41] <^demon> I think we're on an edge case here :) [18:44:53] <^demon> robla: Although, if people have +2/Submit permissions on their own extensions, do we really need to muck things up with an auto-approve bot? Why not just +2 & Submit? [18:45:47] <robla> ^demon: maybe not a bot, but is it possible to streamline that with a hook to automatically do that? [18:46:04] <^demon> I mean yes, it can be done by a hook (it's what we do for L10n). [18:46:22] <^demon> But I don't *like* the practice. Code should at least pretend to be reviewed. [18:47:07] <robla> ^demon: if the choice is between that or direct push, I'll take the hook [18:47:47] <^demon> But why not push and then submit? What's wrong with the manual step? It requires someone to acknowledge that code is going in to the repo. [18:48:00] <^demon> Rather than commit-then-flee which we've encouraged for too long IMHO. [18:48:58] <robla> ^demon: if we're talking about code where we've got a lot of reviewers (like stuff being pushed to WMF), then I agree [18:49:05] <RoanKattouw> OK, direct push to wmf/* is now disallowed [18:49:19] * RoanKattouw updates docs [18:49:32] <robla> but if we're talking about single maintainer extensions, it's just busywork to make them poke buttons in the web ui [18:49:43] <robla> ...and it makes them resent the switch to gerrit more [18:49:51] <^demon> Not many extensions have opted in to it so far. [18:50:10] <^demon> So even with non-wmf stuff, extensions are still pushing for review. [18:52:09] <^demon> Anyway, it'll need to be a bot. I don't want to have to put in gerrit config changes every time someone opts in/out of this. [18:54:10] <Eloquence> RoanKattouw, the invisible-to-Gerrit change we looked at earlier, would I be able to view it through a gerrit URL with the legacy ID? or would it not come up there either? [18:54:33] <RoanKattouw> No, you'd have to use gitweb [18:54:47] <RoanKattouw> It won't even have been /assigned/ a four-digit ID [18:55:03] <Eloquence> right [18:55:55] <^demon> RoanKattouw: Now that we've got jenkins running regularly for core, do you think we can revoke V+1 permissions on mediawiki/core now? [18:56:24] <RoanKattouw> ^demon: I have mixed feelings about that. There need to be people with the ability to bypass Jenkins if it's broken [18:56:43] <robla> ^demon: maybe we can just call it "ClownyBot". I love the idea of seeing "ClownyBot: looks good to me, approved" in gerrit :) [18:57:01] <vvv> What are the plans for Jenkins integration for extensions? [18:57:19] <^demon> Ask hashar? [18:57:24] <RoanKattouw> ^demon: So at least some humans (admins and wmf-deployment at least) need to retain V+1 rights IMO [18:57:27] * vvv asks hashar [18:57:49] * hashar figures out an answer [18:57:57] <^demon> RoanKattouw: Yeah, breaking that down per-branch would be kind of annoying. We can leave it for now. [18:58:02] * RoanKattouw would like PHP linting for extensions too [18:58:14] <^demon> And just wait for our glorious continuously integrated future ;-) [18:58:39] <RoanKattouw> ^demon: It doesn't need to be broken down per-branch as far as I'm concerned, I'm just saying that we can't take V+1 away from all humans and only give it to bots [18:58:48] <hashar> vvv: there is no plan yet for extensions. Will surely do whenever the wmf branch is available in git [18:58:59] <^demon> Um, it is? [18:59:08] <RoanKattouw> hashar: "wmf branch is available in git" ---> what do you mean by that? [18:59:10] <hashar> I have no idea [18:59:23] <^demon> We've been deploying from the wmf branch for the last week :p [18:59:32] <hashar> ohh [18:59:34] <hashar> \o/ [18:59:55] <hashar> so been busy with discovering the beta labs and trying to get testswarm to works somehow :-] [19:00:01] <^demon> https://gerrit.wikimedia.org/r/#q,project:mediawiki/core+branch:wmf/1.20wmf1,n,z [19:00:02] <^demon> :) [19:00:34] <hashar> so I need to figure out how to inject mw configuration per branch [19:00:45] <hashar> then generate a job [19:01:01] <hashar> ahaha [19:01:10] <vvv> By the way, we had some automated JS test suite, right? [19:01:27] <RoanKattouw> For core, yes [19:01:32] <hashar> House M.D. is not broadcasted tonight :-] [19:02:51] <vvv> I wanted something to go over Wikimedia wikis and check if their JS is broken [19:03:05] <RoanKattouw> Oh that [19:03:39] <vvv> That would be helpful in sense that we could find broken JS in general and especially when it is broken after deployment [19:06:03] <RoanKattouw> Yes, very [19:10:18] <raindrift> Hey, RoanKattouw. Quick question. You may recall that we talked about making a custom RL module for backbone templates. I'm making that now, based roughly on stuff that's in ResourceLoaderFileModule. I'm wondering, though: should I instead just subclass ResourceLoaderFileModule so I can use all its internal file access methods, or would that break a bunch of stuff? [19:10:45] <raindrift> Like, I could just override getScript and getModifiedTime [19:11:10] <raindrift> … or I could subclass ResourceLoaderModule and reimplement the file-reading stuff. Either is fine. [19:13:13] <RoanKattouw> I figured you may not want to subclass RLFileModule because there's so much specific cruft in there [19:16:19] <raindrift> RoanKattouw: yeah… mostly I'm wondering if there are other methods besides getScript and getModifiedTime where I'll want the default implementation? [19:17:34] <RoanKattouw> raindrift: BTW your shell access just got approved :) [19:17:40] <RoanKattouw> Looking at the default implementations [19:18:09] <RoanKattouw> You would want a different constructor [19:18:15] <RoanKattouw> supportsURLLoading() would break [19:18:31] <raindrift> Hm. Okay. I think I'll just subclass ResourceLoaderModule then. [19:18:37] <RoanKattouw> getScriptURLsForDebug() too [19:18:40] <Amgine> Beta 2 is released! get your free beta version of the Wiktionary Mobile app here! hurry before they're all gone! http://lists.wikimedia.org/pipermail/wiktionary-l/2012-April/001121.html [19:18:47] <RoanKattouw> Yeah I'm 1/5th through and it's not looking pretty, so you should do that [19:18:57] <raindrift> Sounds like a plan. Thanks for your help! [19:31:30] <gerrit-wm> New patchset: Hashar; "testswarm sqlite db is now writable by others" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/5737 [19:31:49] <^demon> Oh man, this is cool. [19:31:51] <gerrit-wm> New review: Hashar; "I know it is lame but that is all I can afford right now :-(" [integration/jenkins] (master); V: 1 C: 2; - https://gerrit.wikimedia.org/r/5737 [19:31:52] <^demon> RoanKattouw: `ssh -p 29418 gerrit.wikimedia.org gerrit stream-events` [19:31:54] <gerrit-wm> Change merged: Hashar; [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/5737 [19:32:56] <RoanKattouw> ^demon: Yeah I'm aware of that, the Gerrit Trigger Plugin uses it [19:33:01] <RoanKattouw> I have never actually look at it though [19:33:26] <^demon> It's just a json stream of events happening in gerrit. [19:33:38] <^demon> Super useful if anyone wanted to consume that data for bots, etc. [19:38:07] <hashar> so somehow [19:38:16] <hashar> I though Linux / ant / Jenkins would be smart [19:38:29] <hashar> and honor the g+s sticky bit I have set on a directory [19:38:32] <hashar> I Was wrong :-((( [19:38:48] <hashar> ends up doing a ugly "anyone can write" hack :-( [19:48:59] <hashar> so I think I *might* have testswarm fixed up a bit [19:49:17] <hashar> finally found out what was causing all tests to timeout :-( [19:50:18] <hashar> ^demon: http://integration.mediawiki.org/testswarm/job/1974/ \O/ [20:20:09] <RoanKattouw> preilly: What does var_dump($wgSessionStarted); print? [20:21:06] <preilly> RoanKattouw: bool(false) [20:24:16] <Nikerabbit> hashar: wwhat was it? [20:51:56] <chrismcmahon> mdale in regards to TMH, what exactly is "real time stream switching"? [20:52:21] <mdale> it means switch stream and seek to the time you left off at [20:52:56] <chrismcmahon> mdale: do you have an example? [20:53:34] <mdale> like your watching the webm 480 video then you press fullscreen.. then you may want to switch it to 720P version [20:53:42] <mdale> but continue where you left off [20:55:06] <chrismcmahon> mdale: got it thanks [20:55:28] <mdale> np [21:27:29] <[Bergi]> hello! [21:27:36] <sumanah> hello [21:28:17] <sumanah> Reedy: so, re https://bugzilla.wikimedia.org/show_bug.cgi?id=22911 , would you move it to the Deployment Queue? I presume that I shouldn't do so and that the release manager should [21:28:27] <[Bergi]> I just got an ERR_TOO_BIG Wikimedia error for a 500-titles api request. That's OK. [21:28:27] <[Bergi]> The question is: How long are URIs allowed? [21:29:23] <RoanKattouw> Hmm, that would be a Squid config thing I guess [21:29:59] <RoanKattouw> [Bergi]: As a workaround, you can also use POST [21:30:36] <[Bergi]> Yes, it seems there is a special error file for the "ERR_TOO_BIG" squid error id. But where can I find that squid config file? [21:30:56] <RoanKattouw> I asked in the operations channel [21:31:06] <RoanKattouw> I'm also curious to know as to what the limit is [21:31:19] <RoanKattouw> OK that's not correct English but you know what I meant :) [21:31:54] <[Bergi]> RoanKattouw: Yeah, POST seems to be the better way. But i'm also curious about :-) [21:37:49] <Reedy> sumanah: This somewhat reminds me of http://lists.wikimedia.org/pipermail/wikitech-l/2011-December/thread.html#56982 (or more so, the original private discussion) [21:39:22] <sumanah> Reedy: yup. In this case, the extension has gone through code review [21:41:12] <sumanah> raindrift: re http://lists.wikimedia.org/pipermail/wikitech-l/2011-December/thread.html#56982 - the notes you wrote up re deployment process, are they somewhere onwiki, maybe in your userspace? [21:42:03] <sumanah> Reedy: so, it's ready to go into the deployment queue, right? [21:46:24] <RoanKattouw> [Bergi]: The answer I got was "I think it's 8k but might only be 4k" [21:48:48] <[Bergi]> RoanKattouw: OK, thanks. That's at least the order of magnitude. Isn't there also a PHP $params length limit? [22:09:16] <RoanKattouw> [Bergi]: That's only for the # of titles though [22:09:43] <RoanKattouw> I don't think PHP itself cares about the length of the param string, that would be very annoying for POST [22:17:36] <[Bergi]> RoanKattouw: Right, that was only for query strings in some environments (http://www.mediawiki.org/wiki/Manual:$wgResourceLoaderMaxQueryLength) [22:18:15] <RoanKattouw> Ah yes [22:32:26] <preilly> RoanKattouw: can you take a look at https://gerrit.wikimedia.org/r/#change,5771 again