[00:12:45] TrevorParscal: do you have time to take on some of Roan's queue? [00:12:58] i can look [00:13:28] we'll just assign some [00:14:35] yeah, there are some js/css revs that aren't mine I could pitch in on [00:15:10] i can do some core PHP too - I'm not familiar with all the extensions that chad is I think [00:15:15] Hmm [00:15:27] kaldari can review CSS i wrote [00:17:44] is kaldari around? [00:18:02] Isn't he on holiday? [00:18:09] Krinkle, what's your CSS like? [00:18:27] TrevorParscal: mmm you don't think we should promote a particular mode of html build out? .. Its only problematic because its adding convenience to a mode we should not promote ... [00:18:27] Good. [00:18:44] revieable, if you mean that [00:19:07] we should not promote...? [00:19:10] really? [00:19:31] Krinkle, fancy reviewing TrevorParscals CSS revs that are still outstanding? :) [00:19:32] I don't think large html strings are easy to deal with [00:19:32] we used a more sloppy version of this in the dialog code because the way you are propsing is incredibly slow [00:19:53] it is "slower" [00:20:08] the only thing more difficult than a large HTML string is hundreds of lines of javascript which eventually build an HTML structure [00:20:15] Reedy: Sure, got loads of virtual machines and browsers to test whatever needs testing. [00:20:23] :) [00:20:34] Reedy: Anything in particular (I guess status new prebranch) [00:20:57] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/roan [00:21:06] Theres at least one obvious one on there [00:21:49] TrevorParscal, can you point Krinkle at the right revs please? [00:22:02] sure [00:22:04] mmm well I think its more clear .. and performance should not be an issue if your building out on demand not pre-caching everything ... but whatevers clever / works for people I guess ;) [00:22:24] TrevorParscal: Reedy Put it somewhere on here http://eiximenis.wikimedia.org/1-17 I'm gonna close up for today [00:22:26] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/roan?author=tparscal [00:22:36] any CSS stuff in there [00:22:41] that's what they're needing help with [00:22:51] Krinkle, unless you're gonna get up at like 7am your time ;) [00:23:03] If you can't, don't worry about it :) [00:24:09] Hm... I know the upgrade starts at 8 AM but the code deployment is later right ? (databases go first which I imagine takes a long while with the traditional Musical chairs dance. [00:24:34] Tim has already done all that [00:25:22] Ah I see now @ http://wikitech.wikimedia.org/view/Server_admin_log - didn't know that (thought that was supposed to start at 8 AM) [00:25:37] heh, they were done in advance for purely the reason of unknown time to complete :) [00:25:50] Though, you might be able to get them done before roan has finished doing his prep work :) [00:25:52] in that case I wish you luck and I'll see it at 6 PM UTC when I get home [00:26:40] Gonna get some sleep now and get up early for college. Howdy. [00:27:07] Howdy? [00:27:08] Lol [00:31:55] TrevorParscal: funny I remember having this conversation a long time ago.. ( after converting everything to jQuery build out I favor it more ) but certainly html is nice for some reasons: http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg05336.html [00:33:39] Tim believes that all HTML must be built procedurally, I think there are different approaches for different situations, and that 100% procedural HTML generation is not a universal solution [00:34:04] rebalanced this: http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.17/Revision_report [00:34:06] there's no security risk in the $.fn.localize() method of templating [00:34:18] why not? [00:34:23] TrevorParscal: we just loaded you up with several [00:34:24] does it strip onclick attributes? [00:34:43] why would it? [00:34:49] TrevorParscal: mdale: is what you're talking about somehting that needs to change in the next 12 hours? [00:34:53] I mean its only a problem if you build your html string [00:34:53] it's not user provided text going into the dom [00:34:55] nope sorry [00:35:27] robla: yeah, I see em [00:35:59] centralauth, collection and RSS are probably not the best things to hand me [00:36:02] I will take a look [00:36:11] but I don't know those extensions very well [00:36:28] TrevorParscal: there were a couple that were yours, then you assigned to Roan. I left them with Roan for the time being because I didn't know the reason [00:37:11] is brion helping? he's at work too right? [00:37:27] poking a few bits here and there [00:37:31] how's it going? [00:37:45] we're cutting it close :) [00:37:54] ^demon: how's your queue going? [00:38:10] <^demon> Slowly but surely. Tackling a fixme right now. [00:38:19] take the one on Roan's list, brion -- it is CSS [00:38:21] there's a fixme? [00:38:43] ^demon: is it an installer issue? [00:38:49] hexmode, http://www.mediawiki.org/wiki/Special:Code/MediaWiki/69649 ? [00:39:07] brion: right [00:39:13] looking [00:39:28] thanks! [00:39:38] CSS is supposed to be simple, but that looked wonky [00:39:41] <^demon> robla: No, generic DB concerns introduced awhile back [00:39:46] <^demon> Was making sure they were resolved. [00:40:01] brion is a better person to look at some of those extensions we have on the cluster, he probably helped write them and deployed them himself at some point :) [00:40:13] <^demon> Ooooh, brion should review proofreadpage ;-) [00:40:20] heh [00:40:24] :) [00:40:29] ^demon, one of these days proofreadpage needs a major rewrite [00:40:36] <^demon> Yes, it does. [00:40:40] i might be talked into it in order to also give it a good ui ;) [00:40:45] <^demon> I keep going cross-eyed every time I try to review it. [00:40:51] stick out your head far enough and see what happens, brion? [00:40:58] for the meantime i think it's in "kinda horrid and breaks sometimes, but in acceptably limited ways fo rnow" [00:41:05] [proofreadpage] [00:41:20] <^demon> Btw, can someone confirm to me...were all wmf db clusters updated to 5.1, or are there some 4.0s lagging behind? [00:41:42] <^demon> He uses subqueries in a lot of his unreviewed revisions, and I'm hesitant to mark it ok. [00:42:39] enwiki slaves look to be 5.1 [00:44:41] what is the fastest README for loading a Wikipedia dump into MW? [00:45:41] readme? [00:45:48] TimStarling: I'm assuming you're still trying to back out category collation from the 1.17wmf1 branch. let us know if/when you get some capacity for reviews [00:45:51] ^demon, that's a question i was trying to ask as well. [00:46:04] all the relevant masters seem to be 5.1. i don't see any documentation stating that there are 4.0s around still [00:46:16] <^demon> That's what I thought.... [00:46:24] of course if it breaks, no biggie. it's a new special page that can be killed if we discover a need to [00:46:32] <^demon> But I wanted to hear it from Someone Who Knows. [00:46:33] Reedy: HOWTO [00:47:13] hexmode, importDump.php in maintenance? [00:47:20] I think I've got a patch ready to go [00:47:47] I didn't realise how broken category sorting in 1.16 was, it's confusing me [00:48:06] Reedy: ok, just thought there might be something more to know [00:48:35] esp for loading the whole dump [00:48:59] Can't 5.1 be a slave for 4, but not 4 as a slave for 5.1? [00:49:08] so hence, if all masters are 5.1, all slaves are too? [00:49:31] http://test.wikipedia.org/wiki/Category:A1 [00:49:57] did you know that if you use a lower-case letter for the sort key in a category, it makes a heading for the lower case letter? [00:50:12] TimStarling, are all our clusters on MySQL 5.1 now? [00:50:19] no, two are still 4.0 [00:50:27] 2 or 3 [00:50:55] brion, ^demon ^ [00:52:27] you can't have a 4.0 slave on a 5.1 master [00:52:40] I had to check all the server versions yesterday when I was doing master switches, to make sure that didn't happen [00:53:07] <^demon> In that case I'd feel better reverting ThomasV's work to ProofreadPage. [00:53:14] <^demon> He uses subqueries all over the place. [00:53:15] TimStarling, any wikisources among them? [00:53:53] collapsible table of contents seems to be gone on ie6/7 [00:54:28] the slide-down for the ajax watch/unwatch message seems to have some bad visual problems on ie7 [00:54:32] who wants http://www.mediawiki.org/wiki/Special:Code/MediaWiki/70137 - someone who knows more about the API, maybe Reedy - because I can't really weigh in on http://www.mediawiki.org/wiki/Special:Code/MediaWiki/70137#c9518 since I'm not very familiar with the API [00:54:55] Reedy: take back that FIXME!!! ;) [00:54:59] Nope [00:55:01] :P [00:55:02] it's probably fine for now, but should be paid attention to soon [00:55:26] it's s5 and s6, so dewiki, frwiki, jawiki, ruwiki [00:55:32] no wikisources [00:55:57] whee [00:55:57] Reedy: did you even READ my comment? [00:56:07] Which comment? [00:56:20] the one on that fixme [00:56:38] I have now [00:56:39] It is a fixme [00:56:44] When it goes outside {} [00:56:52] the variable goes out of scope [00:56:56] so it's not there on the next iteration [00:57:18] are you sure? PHP is magical that way [00:57:30] collation code is committed now, can we have it on prototype? [00:57:46] hexmode, seriously? [00:57:47] Hmm [00:57:48] Let's try [00:57:58] pdhanda: ^^ [00:58:04] see Tim's question [00:58:46] Ugh [00:58:49] That's beyond nasty [00:59:07] hexmode, you're right it works [00:59:09] *Reedy barfs [00:59:18] and run this SQL on prototype once the new code is live: alter table categorylinks drop cl_sortkey_prefix, drop cl_collation, drop cl_type; [00:59:19] :) [00:59:30] right, i'll tidy it up [00:59:55] but it is very ugly looking, you're right about that [01:00:11] Reedy: tidy in 1.18, right :) [01:00:19] TrevorParscal, tables of contents don't show hide/show links in ie6/ie7 for me on my local 1.18-svn, but they do display on prototype release-en [01:00:25] It's being backported [01:00:26] any changes recently? [01:00:34] Reedy: really? [01:01:14] brion: is that the only sign of js failing? any errors? [01:01:31] none that i can see [01:01:39] Reedy: if it only LOOKS broke, don't fix it [01:02:06] TrevorParscal, it looks like 1.18-svn has some fancy new code that slides down/up [01:02:12] perhaps that's not on prototype [01:02:27] it might be doing some check for compatibility and just disabling itself on ie6/7? [01:02:45] jquery should be on ie6 and 7 [01:03:11] and sliding isn't exactly something you need an HTML5 browser to pull off [01:05:39] i need to head home, I will be back online to try and finish my queue [01:05:46] cyall in about 30min or so [01:16:03] ugh sorry i missed that [01:16:41] updated prototype [01:17:46] running sql [01:19:17] actually let me dump the db first :P [01:19:34] TimStarling, for 70137, to me, it's either doing it optionally like it is now, or doing it unconditionally, and just giving a "wgAllowAsyncCopyUploads is not enabled" if people try and use it [01:19:49] i still find it ridiculous that i have to install "Apple Bonjour Print Services for Windows" to use .local addresses in IE :P [01:21:53] TimStarling: done on prototype en, de, pl and ar [01:22:01] thanks [01:24:01] Reedy: that is in Trevor's queue, you want me to look at it? [01:25:01] TimStarling, it's 2 minutes work to refactor it to do it unconditionally, and error if the async isn't enabled. It keeps the same behaviour, and seems sensible to do so [01:25:47] And fixes the only written "issues" [01:26:40] is prototype up to date with what'll be deployed for 1.17 on wmf? [01:26:42] or does it need updating? [01:27:00] I think pdhanda literally just did it [01:27:11] just updated [01:27:37] it is running branches/wmf/1.17wmf1 [01:28:35] whee [01:28:50] is that the primary branch we should be testing against? [01:29:51] yup [01:29:52] yeah [01:30:00] thanks pdhanda [01:30:31] ok I have to run to class. I'll be back in a couple of hours. [01:33:58] Reedy: personally, I'm fine with it how it is [01:34:17] you either get a "parameter does not exist" message, or a "copy uploads disabled" message [01:34:39] Hmm, yeah [01:34:49] Which will easily point the person to the issue [01:34:55] maybe "copy uploads disabled" is slightly more informative, but either way, the client can handle it [01:34:59] If it becomes a problem, we can always change it over [01:35:16] yes [01:36:00] Marked resolved then :) [01:39:00] 29 revisions [01:41:28] 27 [01:43:12] I think with that I'm gonna try and get some sleep as it's nearly 2am. Got some running about to do before I get to uni in the morning [01:43:28] So should be about from around the time stuff actually starts happening [01:45:07] ok, see you then [01:45:39] Reedy: night! [01:46:20] Night. Feel free to ping me via email/sms if i'm not about and I'm needed/urgent wanted [02:06:14] i have returned [02:07:04] and the crowd goes wild! [02:07:05] :) [02:07:47] how's it going? [02:08:05] \o/ [02:08:23] i fixed an ie7 bug in the watch tab icon spinner :D [02:08:44] the category collation code is backed out now, and prototype updated [02:09:01] someone needs to merge http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81679 [02:09:52] i didn't wanna merge it myself in case i break somebody's merge process :) [02:10:26] roan has been doing the merges in batches of about 20 [02:10:42] but he's asleep now so we have no merge process, so feel free to merge what you want [02:10:55] just untag it when you're done [02:11:25] or I can merge [02:11:34] so how many destination branches do we have? [02:11:44] 1.17wmf1, REL1_17, ? [02:11:51] 2: REL1_17 and wmf/1.17wmf1 [02:12:11] sounds manageable, i'll give it a whirl [02:12:33] should 1.17wmf1 merge things direct from trunk, or via REL1_17? [02:13:05] I think Roan has been merging to REL1_17, then from there to 1.17wmf1 [02:13:10] sounds good [02:13:18] *robla double checks that [02:13:32] that's what he did with r81656 [02:14:14] merging from REL1_17 is good if you got a conflict when you merged from trunk which you resolved [02:14:41] because then you won't get the same conflict again merging to 1.17wmf1 [02:15:37] yeah, he seems to have been doing that generally, and that's a good reason to do it [02:16:32] but I think it would be nice to have a reference to the trunk revision at least in the commit message, so that it will show up in the related revision list in CR [02:18:41] down to 23 revs: http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.17/Revision_report [02:21:20] my list keeps growing [02:21:51] ok i think i got it mergified [02:22:06] TimStarling: there was a few of Roan's old revs-to-review we put on you. We put most of them on Trevor, but the ones we gave to you were the ones that Trevor wrote [02:23:15] man, i'd forgotten how horribly painful merging in svn is [02:23:53] <^demon> Yeah :( [02:25:14] but branching is super easy! [02:25:18] :) [02:25:26] <^demon> Those WikiEditor revisions are huge. [02:26:06] i wish... branching sucks ass too, at least you only do it at the start of each branch :P [02:28:18] <^demon> robla: I picked up two more revisions for FR into 1.17 [02:28:43] ooh, mutable state on the skin class? [02:28:44] funky [02:31:31] ^demon, do you know what the purpose of r70900 was in the first place? [02:31:40] "getSkin() should get a Title as parameter." [02:32:45] <^demon> Presumably so the Skin can specify the title, which is better than relying on $wgOut. [02:32:50] <^demon> (as best I can wager) [02:33:10] well we should be moving away from constantly grabbing a skin object just to output links [02:33:13] it's just silly [02:33:22] <^demon> +1 on that [02:33:26] so stuffing mroe crap into it when we get it...... i don't get it [02:33:31] r70900 looks pretty useless to me [02:33:41] you should just revert it [02:34:33] <^demon> Actually, passing a Title to getSkin() is my fault. [02:34:33] the only thing worse than a global variable is having to do [02:34:36] global $wgTitle; [02:34:41] global $wgUser; [02:34:46] <^demon> Goes back to r49493. [02:34:48] $skin = $wgUser->getSkin( $wgTitle ); [02:34:51] 50,000 times [02:35:07] amen brotha [02:35:32] <^demon> Well getSkin() with no Title falls back to $wgOut->getTitle() [02:36:41] but if it's not breaking anything, we don't need a fix in 1.17 [02:36:47] right [02:37:10] Parser should probably have its own Linker object, initialised by Parser::clearState() [02:37:25] the Linker would contain a context title, specified in the constructor [02:37:33] so sounds like r70900 (adds a billion useless $this->mTitle or $title to getSkin() calls) might be wasting resources without further fixes or revert [02:37:51] we can mark it as fixme and tag it 1.18 so that it doesn't show up on the list [02:37:53] then instead of $this->mOptions->getSkin( $this->mTitle ) [02:38:05] you would have $this->linker->link(...) [02:38:44] <^demon> Wow, I really need to let my eyes rest for an hour or so. [02:38:59] <^demon> I'm getting getSkin()s confused. [02:39:31] heh [02:39:43] ParserOptions::getSkin doesn't check the title param if it's ever gotten a skin before [02:40:43] that said, i think i'm pretty happy with r81675 [02:41:13] sounds like it should make reasonable sense? [02:41:50] i'll go ahead and merge it and that should make us happy to ignore the other stuff until 1.18 [02:42:09] yes, looks ok [02:44:57] chad, I assigned r75041 to you - because you know central auth reasonably well - I'm for some reason thinking [02:45:27] <^demon> I know zero about centralauth, but ok :D [02:47:12] i think i've blocked most of centralauth from my memory [02:47:16] it was a very traumatic experience ;) [02:48:00] i don't know much about the RSS extension - this rev seems to do what it claims, and I don't see any errors when I use it http://www.mediawiki.org/wiki/Special:Code/MediaWiki/75831 [02:48:08] any extra eyes would be welcome [02:49:26] looking [02:49:27] same goes for r76841 and r75862 too [02:51:39] really, the rest of my queue aren't really my forte - I'm sorting through them but I don't know how the upload thumnailing ended up in my queue [02:52:09] r75831 seems to make it filter/highlight on more fields than it used to, which seems opposite to the description. i'm just a little confused by it i guess [02:53:41] hmm [02:53:45] looking at full diff [02:53:59] hexmode may still be around to talk about it [02:53:59] i take it we use this ext in production? [02:54:10] brion: yeah, we use it on wikimediafoundation.org [02:54:44] r75041 looks ok to me, I'll mark it [02:57:09] typing one-handed at the moment, baby in other hand [02:59:05] r75831 looks fine i think, and makes more sense in the later context [02:59:09] i'll mark it OK [02:59:55] + if ( $title->isValidCssJsSubpage() && $revision = Revision::newFromTitle( $title ) ) { [03:00:16] assignment expression :P [03:00:32] you know, assignment has a lower precedence than && [03:01:05] this is r72776 [03:02:06] TimStarling: http://www.flickr.com/photos/yoz/172282431/ <-how its done :) [03:07:16] TrevorParscal: http://p.defau.lt/?z6lVp2xclqKKoiI51553Pg [03:08:16] did you get the impression I didn't believe you? [03:09:11] like a few months ago sam was going through and removing assignment within expressions like that and we all decided it was for the best to get rid of them [03:10:23] so, i guess you found something we didn't catch [03:10:40] you might have updated it later [03:10:59] what rev was that from? [03:11:00] I just thought you might have found the example curious, I didn't mean to offend [03:11:30] i'm not offended, no worries [03:11:33] it is interesting [03:11:37] coming up with a good example was a bit trickier than I thought, since it does some weird right-to-left thing [03:11:55] yeah - I think that's the pitfall about assignment in expressions [03:12:13] it's not trivial to know exactly how it might behave in various conditions [03:12:24] it should be more obvious, so they are bad [03:12:42] and I accept all blame for the ones I've used [03:12:44] :) [03:16:22] TimStarling, a stray var_dump wandered into LinksUpdate: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81671#c13996 [03:16:31] oops [03:16:44] it happens :D [03:22:20] more often when you rush, which is what I was doing [03:25:19] ^demon: thanks for sifting through the 1.16wmf4 list. I misinterpreted what we should do there. unfortunately, that added a couple to our list :-/ [03:25:37] <^demon> I untagged 1.16wmf4 things that were pre-branch [03:25:42] <^demon> They'll be deployed by default. [03:25:57] but not reviewed by default [03:26:09] doh! [03:27:55] oh, but hey....looks like maybe a couple have already been in production for a little while [03:29:41] it looks like r69080,??r69081,??r69085 were all deployed by philip without review [03:30:58] <^demon> Philip can't deploy stuff. [03:31:08] <^demon> He just merged to the 1.16 release branch (not deployment) [03:31:38] i gotta eat dinner with my family [03:31:49] I will be online more in a bit [03:31:52] cyall for a while [03:35:37] <^demon> Down to 16 revs new, pre branch. [03:35:47] so....I guess that just means that philip's changes might have slipped into 1.16.1 [03:36:08] 15 revs by my count: http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.17/Revision_report [03:36:28] oh wait, 16, you're right [03:36:30] <^demon> https://secure.wikimedia.org/wikipedia/mediawiki/w/index.php?limit=16&title=Special:Code/MediaWiki/status/new&offset=77974 [03:36:44] my silly script [03:38:02] no wait, 15 is right, there's one rev that shows up twice because two people have it in their queue [03:38:57] <^demon> It's 16, per that link above. [03:39:03] <^demon> That wouldn't duplicate revs. [03:39:38] but it would probably include revs that are marked "1.18" because they were reverted in 1.17 already [03:40:08] ...and it doesn't include r81612 and r78179 [03:59:21] ok dudes, i'm gonna wander off for a bit and check in later [04:00:30] <^demon> I think I'll do the same, rest my eyes for awhile. [04:01:56] thanks brion! thanks ^demon|away [04:02:29] <^demon|away> Anytime. [04:05:18] down to 12: http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.17/Revision_report [04:05:50] I'm looking at r77451 [04:07:27] is this UploadStash stuff going to be used? [04:07:41] mmm version is "NaNNaNNaNTNaNNaNNaNZ" on http://prototype.wikimedia.org/rc-en/index.php?title=Test&action=edit [04:07:42] I haven't reviewed it before [04:10:07] TimStarling: looks like it may have been deployed already [04:10:28] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/77463 [04:10:31] header( 'Expires: Sun, 17-Jan-2038 19:14:07 GMT', true ); [04:10:39] lol [04:11:17] I don't think MediaWiki should have a date on which it stops working [04:11:41] mdale: where are you looking? [04:11:45] for example: http://prototype.wikimedia.org/rc-en/load.php?debug=false&lang=en&modules=ext.wikiEditor%7Cext.wikiEditor.dialogs%7Cext.wikiEditor.toolbar%7Cext.wikiEditor.toolbar.i18n%7Cjquery.wikiEditor%7Cjquery.wikiEditor.dialogs%7Cjquery.wikiEditor.toolbar&skin=vector&version=NaNNaNNaNTNaNNaNNaNZ [04:12:10] in the console [04:12:26] using firebug [04:17:28] hmmm....I'm getting a ton of errors in the console, but not that one [04:18:29] it's in the source too [04:18:41] [04:19:30] is it WikiEditor's fault? [04:19:51] its not a valid date being passed in afaict [04:23:13] need to go away for a bit. back in an hour-ish [04:26:57] sorry, it's in the generated source [04:27:05] not the real source [04:35:41] ["ext.vector.collapsibleNav", "20110208014639", [04:36:09] it should be a unix timestamp, not a MediaWiki timestamp [04:36:18] this is in the startup module [04:56:28] grr [05:06:55] what is debug mode meant to do again? [05:09:09] access the files in "raw" mode [05:09:29] or direct file rerfrence [05:09:37] reference mode [05:11:03] is there any debug mode that makes the files readable but doesn't disable the entire system I'm trying to debug? [05:12:08] I've found it now anyway [05:13:38] this bug has been there for months, hasn't it [05:18:47] since september, r73645 [05:32:35] mdale: it should be fixed now [05:32:41] cool [05:38:55] there was a bugzilla bug out for that [05:39:05] looking for it now [05:39:20] *robla updates prototype unless pdhanda stops him [05:40:21] *pdhanda does not stop him [05:41:08] you have to actually be pdhanda to update prototype [05:41:13] the files aren't group writable [05:41:22] root@prototype:/srv/org/wikimedia/prototype/wikis/rc-en/includes/resourceloader# su pdhanda [05:41:22] hmm - https://bugzilla.wikimedia.org/show_bug.cgi?id=26704 looks like it got fixed - or was thought to have been fixed [05:41:27] pdhanda@prototype:/srv/org/wikimedia/prototype/wikis/rc-en/includes/resourceloader$ svn up [05:41:28] UU ResourceLoader.php [05:41:28] Updated to revision 81690. [05:41:55] obviously it wasn't fixed, because I just fixed it [05:42:11] yes - as I said, thought to have been [05:42:43] I suppose there's various ways it could happen [05:42:55] it looks like anything that's not a proper unix timestamp will cause versions like that [05:43:12] so this might have been a different bug with the same symptom [05:43:17] right [05:47:40] robla: my wife is not digging me being on IRC right now - seriously call my cell if you need me - i gotta pay attention to her (she deserves it, she's been patient all evening) [06:25:55] the big list of wikis for us to check after we deploy: http://eiximenis.wikimedia.org/1-17-allwikis [06:27:24] nadeesha: are you and the other Calcey folks going to be around to help check the wikis after we deploy? [06:29:19] robla: yes we can help [06:29:33] robla: please update us once its done [06:29:40] great! that will be a big help [07:21:16] <^demon> Anyway. Extension renames. It's a breaking change for deployment and release. [07:21:34] All revs on robla's list have been reviewed now, at least for deployment purposes [07:21:43] <^demon> 65083, 65247, 65227, 65212-14, 65202, 65199, 65196, 65073 [07:21:58] <^demon> Most of these were deferred, which is absurd for such a breaking change. [07:22:08] *robla looks [07:22:40] I thought someone introduced alias files at some point? [07:24:37] OK so let's see which of these are used on WMF [07:24:50] I'll start at the front of ^demon 's list [07:25:28] <^demon> Alias files were never introduced afaik. There was discussion on 65073 about doing so. [07:25:38] r65196 is GNSM [07:25:48] Renameuser [07:25:55] in r65227 [07:26:24] r65214 is Nuke [07:26:53] and RenameUser in r65227 [07:26:55] that's it [07:27:18] OK so just Nuke and Renameuser [07:27:21] GNSM isn't live [07:27:38] ok [07:27:47] I will add wrapper files for those two extensions to the 1.17wmf1 branch [07:27:55] For the transition [07:28:00] <^demon> Right. [07:28:17] <^demon> Before release, we need to go back and add aliases for any of those that are still broken. [07:28:35] we need to fix all of them before release though [07:28:43] <^demon> Yes. [07:29:27] Oh look Renameuser already had an alias file [07:29:58] And I just added an alias file for Nuke to 1.17wmf1 [07:30:21] http://p.defau.lt/?ROxENpSe_B3NmX44mvO2zw [07:30:48] Thanks Tim [07:30:54] was nogomatch already removed from config? http://www.mediawiki.org/wiki/Special:Code/MediaWiki/80697 [07:31:01] I tihnk so [07:31:04] AjaxTest Makebot Makesysop Nogomatch Nuke Throttle UsabilityInitiative/* [07:31:18] Yes, Nogomatch is gone [07:31:24] And the UsabilityInitiative/* stuff is not in 1.17 [07:31:41] OK, so [07:31:56] Time to svn switch the wc on fenari? [07:32:28] as soon as we do that, we won't be able to deploy changes to 1.16wmf4 anymore [07:32:53] maybe do an svn switch on a copy [07:32:58] Right [07:33:01] then we can swap in the copy when we're ready [07:33:06] And push that copy to test somehow? [07:33:29] no, use prototype for testing [07:33:35]