[00:13:30] Im having a small issue, I'm getting -1 for active users on my my wiki, it can be seen here: http://wiki0x10c.com/wiki/Special:Statistics [00:34:30] tfinc: https://bugzilla.wikimedia.org/35777 -- Just checking, but I assume you are gonna get this fixed ASAP? [00:42:04] hexmode: i was the one who changed the priority on it ;) [00:42:35] tfinc: yes, but I just want to make sure "HIGHEST" means it :) [00:42:40] it does [00:43:01] its our #1 priority and mostly fixed [00:43:08] were just tidying up the pre master merge [00:43:11] excellent [00:43:13] s/the// [00:43:19] +1000 [04:04:10] New review: Krinkle; "What about https://gerrit.wikimedia.org/r/#change,4366 ?" [integration/jenkins] (master) C: 0; - https://gerrit.wikimedia.org/r/4366 [04:04:45] New review: Krinkle; "What about https://gerrit.wikimedia.org/r/#change,4364 * is that needed ?" [integration/jenkins] (master) C: 0; - https://gerrit.wikimedia.org/r/4366 [07:37:22] morning [08:23:00] New review: Hashar; "> This is going to conflict with https://gerrit.wikimedia.org/r/#change,4366, since both are ADDing ..." [integration/jenkins] (master); V: 0 C: 0; - https://gerrit.wikimedia.org/r/4360 [08:31:30] how can I contribute to mediawiki apart from developing extensionsa [09:02:19] shakth: come to #mediawiki, thats the right channel for this [11:27:15] any QA/unit testing people around? [11:27:38] No hashar.. [11:27:55] I need a temp directory for writing temporary files [12:37:41] hi hashar [12:37:47] hello [12:38:04] hashar: for PHPUnit, I need temp directory where tests can write temporary files [12:38:16] there is no easy way to do that for now :-/ [12:38:30] some other people have used wfTmpDir() or something like that [12:38:33] let me find an example [12:38:41] hashar: yes I know nothing is easy with phpunit [12:38:50] with automatical cleanup would be awesome [12:39:28] Have a look at includes/media/ExifRotationTest.php [12:39:38] you will have to keep track of any file created in an array [12:39:44] then have a destructor to delete them [12:40:45] hashar: or just leave them there as reminder that PHPUnit is insufficient :) [12:43:07] hashar: doesn't matter much since there are no tests run for extensions yet [12:43:34] ideally we would want MEdiaWikiTestCase to offer a framework to create a file repository that self cleanup [12:43:50] basically, copy the relevant part from ExifRotationTest into MediaWikiTestCase :-] [12:43:58] talk to you late,r I am busy with qchris right now. [12:52:33] Hi, I noticed that out of the 11 core API modules that support sorting, the values for the dir parameter are ascending/descending for 8 of them, newer/older for 2 of them and asc/desc only for categorymebers [12:53:22] There's more than that [12:53:27] since many extensions seems to use newer/older too, i think it makes sense to keep it, but the asc/desc case should be dealt with [12:54:00] There's 8 that use newer/older in core [12:54:20] like which one? [12:54:33] Nikerabbit: looks like qchris implemented what you want :-] [12:54:52] so we could probably abstract his work and rewrite ExifRotationTest to use that new system [12:55:22] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=tests/phpunit/maintenance/DumpTestCase.php;h=d54b37a4cb4c6735d017fe690132d8a52ecf454e;hb=da58f7f55cf588aaffd55b3f601f521514d0166f#l80 [12:55:27] revision, blocks, deletedrevs, logevents, recentchanges, usercontribs, watchlist, protectedtitles, [12:55:36] Those make sense to be newer/older, as they're time related [12:55:46] hashar, NikeRabbit: That's the relevant part [12:55:53] I do agree asc/desc is inconsistent [12:55:56] So i'll fix/add to those [12:56:10] qchris, Nikerabbit that looks a lot like the ExifRotationTest file [12:56:22] * qchris takes a look [12:56:24] ok, newer/older is fine, but asc/desc should be fixed [12:56:26] I think we need that to be added in MediaWikiTestCase [12:56:32] Yeah, am just going to do that [12:56:43] qchris: look at the destructor :-] [12:56:51] @Reedy: ok, thanks [12:57:18] yes... looks similar. [12:57:34] But I am not sure... does ExifRotation also remove plain files? [12:57:44] IIRC, one has to do this by hand [12:58:00] (i.e.:wfRecursiveRemoveDir does not do it) [12:58:17] Svick: amusingly, in the code for category members... if dir equals asc then use newer, else use older :p [12:58:56] hashar: So should we abstract this into the basic test case? [13:00:01] qchris: I know we had several tests leaking files [13:00:17] qchris: I had hack a few tests so they can properly delete them. [13:00:32] the exif test should be removing plain files too [13:00:34] I just checked wfRecursiveRemoveDir and it has a guard 'if ( is_dir( $dir ) )' [13:01:40] hashar: Exif test does not use tempnam :( [13:01:56] hashar: So that'd break once in a while as well :D [13:02:13] (although time and rand are used) [13:04:14] my lame commit was f5b45904 [13:04:58] I can't remember off hand how the files are deleted though [13:05:28] wfRecursiveRemoveDir() should remove the dir and any content in it [13:05:32] maybe, all the files reside within the tmpdir. Then i'd work [13:05:49] Yes. but if the dir is no dir, but a file, it does nothing [13:06:04] and typically, you'd just want a temporary file, not a dir. [13:07:30] well we have several files created in a file repository [13:07:51] the file repository being itself hold in some dir. So deleting the did does remove everything from the test [13:07:56] which looks fine to me [13:07:56] But all those files live underneath the $tempDir... [13:08:17] yes. For ExifRotationTest itself, this works. [13:08:40] BUt in the general setting of wanting to create temporary files from within a test, [13:08:57] this might lead to problems, as you might really want a temporary /file/ [13:09:32] (as opposed to a file within a directory that you have to create yourself before) [13:12:18] so we need to rethink the system [13:12:37] My tests use both. [13:12:52] And it works. I did not come across any relicts [13:15:13] Either way. It would be great to have temporary file management in MediaWikiTestCase :D [13:15:44] <^demon> Maybe have a subclass of MWTestCase for tests that need the functionality? [13:18:01] I would prefer traits [13:18:07] *grin* [13:18:08] <^demon> Yeah that's not happening soon :) [13:18:19] or multiple inheritance [13:18:35] class MyTest extends MediaWikiTestCase, MediaWikiTempFiles {} [13:18:42] <^demon> Well, traits is their way of working around multiple inheritance :p [13:19:04] <^demon> You could do class MyTest extends MediaWikiTestCase implements MediaWikiTempFiles {} [13:19:12] <^demon> Maybe, probably not useful. [13:20:52] * hashar coworking place is too crowed and noisy. Switching to loouuuuud music [13:27:47] ^demon: any updates on automerges? [13:28:03] <^demon> Still digging. [13:28:20] <^demon> Spent a good part of yesterday digging through logs. [13:28:48] let me know if there is anything I can do (disclamer: I am not very good at baking cakes) [13:29:01] <^demon> Cookies, perhaps? [13:29:02] <^demon> :) [13:29:09] <^demon> Thanks though, I'll let you know. [13:54:55] ^demon: gitreview help if you can ;:-) [13:55:00] I have several topic branches [13:55:11] how can I easily submit them all to gerrit ? [13:55:35] <^demon> Checkout each, `git review`. There's no "push all these branches for review" option I know of. [13:55:56] <^demon> Maybe something to suggest upstream, that'd be kind of cool :) [13:55:59] do you know what is the "branch" argument for? [13:56:03] aka: git-review branch [13:56:12] <^demon> Offhand, no. [13:56:36] I have updated their man page [13:56:39] need to check it again :) [13:58:40] git review -R [13:58:41] To ssh://nikerabbit@gerrit.wikimedia.org:29418/mediawiki/extensions/Translate.git ! [remote rejected] HEAD -> refs/for/master/bug/31300 (no new changes) [13:59:00] wtf does it pull bug/31300 from? [13:59:11] <^demon> From your commit summary :) [13:59:23] <^demon> If you aren't using a local branch name other than master. [13:59:33] well [13:59:37] I forgot to do git commit [14:01:25] :-] [14:01:45] ahh I finally finished splitting the changes [14:01:48] took me like 2 hours [14:01:56] BUT [14:02:00] I have documented it: https://www.mediawiki.org/wiki/Gerrit/split_a_submitted_change [14:02:03] well somehow [14:46:42] Nikerabbit: you know that file info is already retrieved from commons via the api for local projects [14:47:12] so it's not such a huge stretch to apply that to a notification system [14:48:47] apergos: that's wrong way :o [14:49:20] if you don't like the api approach, why mention it in your email? [14:50:06] <^demon> It's not done via the api for wmf projects. [14:50:33] apergos: we want to *push* stuff, not *pull* [14:50:34] ok well we have the dbrepo thingie [14:51:03] <^demon> Yeah, api calls via Http::get() would not scale for us :) [14:51:15] ya think? :-P [14:51:21] but the point is it's there and works fine [14:51:23] <^demon> We could try ;-) [14:51:35] I can turn my phone to vibrate, no problem :-P [14:51:42] that's what I get for going to college!! [14:51:43] anyways... [14:51:58] how important is it to have the post go right away? [14:52:16] the problem with the job queue is that our job runners are often really screwed up [14:56:10] what happens with approach one if wiki A is running one version of mw and wiki B is runnng another? [14:56:59] all you need is a variation in the schema (eg sha1 for revs and not sha1 for revs) ... some nice little het deploy time [15:47:46] apergos: yeah I want all that in the mailing list [15:48:33] uh huh [15:52:08] apergos: the pros and cons on wikitech I mean [15:52:45] right, I figured that's what you meant [16:32:16] hmm crap [16:32:21] Reedy: did you branch already? [16:35:27] Nikerabbit: I did a test one, but will need to redo it [16:39:10] Reedy: https://gerrit.wikimedia.org/r/4648 needs to be included [16:43:05] Nikerabbit: we can still merge into the branch though ;) [16:43:49] Reedy: sure, as long as it is included before it is deployed to sr. [16:46:00] Nikerabbit: have you reverted out the rest of the new NS additions? [16:46:16] Reedy: all that have been opposed [16:46:27] Reedy: which is only mk and sr as far as I know [16:46:30] lol [16:47:03] Right... I'd made a patch to revert all the ones not in 1.19wmf1 (which was based on what wasn't in 1.18wmf1).. based on they need namespaceDupes.php etc running for them [16:47:30] ? [16:48:15] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/112266 [16:48:22] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/107309 [16:48:46] We do need to get them deployed soon though! [16:48:54] Just again, it's going to be a deploy AND namespace changes [16:49:56] something to schedule near term [16:52:13] could be done later this week, if we give people a heads up [16:57:11] Reedy: yeah those were resubmitted to gerrit and remerged after affected wikipedias were notified [16:57:24] Oh, they were? [16:57:31] I guess we can deploy them then [16:58:05] will confirm with robla [17:17:40] hi Tuesday 20% people [17:17:52] hi from wednesday people [17:18:02] Rob Moen, Roan, Brion... [17:18:23] I want to talk to Roan too :) [17:18:26] Trevor? TrevorParscal, hi, how are you? [17:18:35] how was the move? [17:18:46] hi, ok so far [17:18:57] exhausting [17:19:04] we slept in our new house last night [17:19:33] for the first time [17:20:01] no poltergeists yet? [17:20:03] but the bathroom is half-finished (being remodeled) and there are no baseboards or interior doors atm [17:20:07] no, none yet [17:20:08] how are the kids handling it? [17:20:29] whoa! [17:20:32] and the old woman who lived here before did not die here (they have to tell you if she did or not legally) [17:20:37] right [17:20:45] they are doing well, but it's stressful for them [17:20:51] we are trying to make it easy on them [17:20:54] my sympathies [17:20:54] yeah [17:21:11] will they get to visit the old place every once in a while? [17:21:18] or did you tell them that the old house went to live on a farm? [17:21:58] more seriously: 20% idea. Did you mayhap see Tim suggesting that people might find it more pleasant & efficient to be more project-based and less one-off-y in their 20% time? [17:22:13] I hereby ask you what you'd prefer [17:22:27] because if you want something more focused, where you'd be working on the same thing for a few weeks, I can provide that [17:22:41] but ifyou want suggestions of 1-off patches for you (and for your team, come to think of it, since Tuesday is your team [17:22:48] team's day) then I can give you those too. [17:23:28] TrevorParscal: (sorry for the onslaught of questions) [17:23:48] i would rather it be project based for me personally [17:24:15] but if 1-off patches are what is needed of me, that's fine [17:24:45] TrevorParscal: I have a small question for you then [17:25:04] TrevorParscal: how about some review of extension(s)? [17:25:29] <^demon> Review of *anything* that we want deployed. We're looking to branch master today. [17:26:14] ^demon: the only item in the extensions review queue that's in some gray area state is ShortURL [17:26:30] sumanah: which extensions? [17:26:44] TrevorParscal: let's look at https://www.mediawiki.org/wiki/Review_queue together [17:26:46] <^demon> Is ShortURL deployed anywhere yet? I'm not talking about rewrite rules. [17:26:53] i find gerrit incredibly difficult to use when trying to find things to review that are javascript, css, html patches [17:27:04] ^demon, no [17:27:04] the watched changes with regex thing doesn't work [17:27:06] ^demon: No it's not deployed anywhere yet and someone needs to make a decision on the question open in the bug [17:27:24] TrevorParscal: then extension review will be a nice way for you to stay in SVN for a little longer :-) [17:27:35] <^demon> Well we're not going to be deploying it while we're moving the currently deployed tree to git. [17:27:42] sure [17:27:54] (I think I get it) [17:28:18] * TrevorParscal doesn't want to stay in SVN, he wants gerrit to be easier to use [17:28:38] TrevorParscal: OnlineStatusBar, skim https://bugzilla.wikimedia.org/show_bug.cgi?id=32128 , or https://bugzilla.wikimedia.org/show_bug.cgi?id=22911 for SubpageShortKey [17:28:46] TrevorParscal: I think Gerrit 2.3 might be a little easier [17:29:02] <^demon> Gerrit 2.3 is going to make some good improvements. 2.4 is also going to be awesome. [17:29:03] TrevorParscal: so, this is a way to have a little less time in Gerrit until that comes out & we test and install it. [17:29:14] ("this" being, reviewing some extensions) [17:29:44] which reminds me, nobody has replied to my git question on wikitech [17:29:47] <^demon> I pinged repo-discuss about a timeline for getting 2.3 out. I got a non-answer :\ [17:29:55] <^demon> Nikerabbit: Thread? I might've missed it sorry. [17:30:01] Open git issues [17:30:09] my mail to that 10 days ago [17:30:54] I asked whether we are going to wait until upstream implements change tagging in gerrit [17:30:54] TrevorParscal: do you know whether Roan, rmoen, and brion are in the office yet? [17:31:48] i'm working from home [17:31:58] Rob has food poisoning or something [17:32:06] I don't know about Brion at all [17:32:11] Roan should be there [17:32:25] but he was getting a cold yesterday, so it's possible he's passed out somewhere [17:32:29] sumanah: i'm here [17:32:30] TrevorParscal: oh right, Rob's distress :( and [17:32:32] maybe on the street or in some dark alley [17:32:36] oh rmoen! hi! [17:32:45] Hello :) [17:33:11] rmoen: read maybe the last 10 min of backscroll? espec regarding how you want to do 20% time [17:33:29] sumanah: ok [17:33:44] more one-off patch review, or more like 1 substantial thing you might work on for 2-3 20% days in a row [17:33:51] (I mean, a few Tuesdays in a row) [17:34:59] <^demon> Nikerabbit: Free-form tagging has been pitched to the openstack guys who work on gerrit. I wasn't at the meeting so I don't know the outcome. [17:43:07] rmoen: so, what do you think? [17:43:12] sumanah: I like extension review, but can you explain what you would consider a substantial thing ? I'm happy to do whatever is needed most [17:43:38] AaronSchulz: still your rev(s) outstanding [17:43:52] rmoen: by "substantial" I just mean that it would take more than a day to do. [17:44:46] sumanah: That's the part of it I understand. Not quite sure what project or task you mean. [17:44:47] Reedy: ? [17:44:56] Your thumb revs haven't been reviewed [17:44:59] /merged [17:45:11] rmoen: I wanted to find out your preference first -- then talk with you about OnlineStatusBar, skim https://bugzilla.wikimedia.org/show_bug.cgi?id=32128 , or https://bugzilla.wikimedia.org/show_bug.cgi?id=22911 for SubpageShortKey [17:45:39] rmoen: you and Trevor might be interested in doing review on one of those extensions today, and if it stretches into next week, that is ok [17:46:38] sumanah: I see what you mean [17:46:50] and brion - since today's also your 20% day -- do you have a preference on what you would like to concentrate on, today or in general? [17:47:17] i'm mostly doing misc review on core atm [17:47:21] like, one-off patches, unit test writing, doc-writing.... [17:47:32] if that's what you prefer, that's cool [17:47:39] So, heads up for all: Last call for any and all revisions that *need* to be in the wmf branch and any relevant extensions! [17:48:08] Your next deployment will be in something like 3 weeks. [17:50:12] TrevorParscal: so how's internet at the new place? :) [17:50:21] * robla attempts to catch up on 1.20wmf01 stuff [17:50:39] i'm on my cell phone tethering right now [17:50:56] I was supposed to get internet this morning but I didn't have my cable modem yet [17:51:00] thursday morning [17:51:23] robla: only outstanding issues (AFAIK) are aarons Revs, and whether we want to back out hte NS changes... Apparently communities have been informed... Doesns't mean they know, and per Platonides we still have the lack of old aliases [17:51:48] the lack of old aliases is kind of a showstopper [17:51:53] but... [17:52:07] we can back it out of the branch. shouldn't be an issue today [17:52:30] TrevorParscal: so, I ask you & rmoen whether one of you might like to pick up & review SubpageShortKey, and whether one of you might like to review OnlineStatusBar [17:52:58] robla: yeah, I've a patch prepared to do that [17:53:11] these are extension in the SVN and need review and will be migrated to git? [17:53:32] AaronSchulz: how are things going on "aarons Revs"? (quoting Reedy) [17:53:51] TrevorParscal: they are in SVN, they need review, and if they're ever going to be deployed on WMF sites then yes they'll eventually move to git [17:53:51] I'm not sure if Tim even looked at them [17:54:30] sumanah: I'm looking into the code bases to see which (if any) would be best for me to review [17:54:46] rmoen: cool. I'll be around [17:55:35] * robla prepares to throw something at AaronSchulz [17:55:58] rmoen, TrevorParscal: maybe you saw some discussion on wikitech-l recently about the extensions review process ... I appreciate you helping me improve it [17:56:11] I will take OnlineStatusBar today [17:56:13] there is one thing needing review (as Reedy mentioned), not sure what else to mention [17:56:16] maybe poke tim [17:56:36] TrevorParscal: ok! I shall do some assigning of Bugzilla and some editing of a wiki page commensurate to the occasion. [17:56:57] ok [17:57:15] we also have https://gerrit.wikimedia.org/r/#change,4601 [17:57:23] ^demon: do you have some time to help fundraising with a deployment strategy using git? [17:57:39] It's 4am for Tim ;) [17:57:41] Reedy: you can review that I guess [17:57:55] 143 deferred revs [17:57:56] nice [17:59:53] And TrevorParscal - as you work, maybe you'll have some UI questions/thoughts? It would be nice to also combine this with a user experience design review [18:00:00] TrevorParscal: if you feel up to it/interested [18:00:17] sumanah: good luck keeping me from doing so [18:00:25] TrevorParscal: but if you don't, that's ok, I can ask Howie, Brandon, et al....... ha! yeah, that's what I thought :D [18:03:57] <^demon> pgehres: Not for a couple of weeks, probably. I was under the impression that fundraising is in no particular hurry. [18:04:07] AaronSchulz: 4601 is the only one you were waiting on a Tim review for? [18:04:36] well Reedy tagged it as needing review by tim [18:04:46] I'd just merge it if roan is OK with it [18:04:56] oh, thats the thumb one [18:04:59] * RoanKattouw looks up [18:05:11] 4601 could be reviewed by anyone [18:05:16] I'm sure Tim won't be offended [18:05:18] since it's a port of something that's running in production now (right?), a cursory review will do [18:05:19] !g 4601 [18:05:19] https://gerrit.wikimedia.org/r/4601 [18:05:25] Pretty much [18:05:38] <^demon> pgehres: If it's just a matter of making repositories and copying data over, yes I can help with that. But any larger "how should we do it?" can't fit on my plate until school finishes in a couple of weeks. [18:05:40] Meh Reedy beat me to it [18:06:13] ^demon: we are just trying to figure out what the proper way to handle a deployment branch of our code is [18:06:24] DonationInterface is already migrated [18:06:26] ok, so down to https://gerrit.wikimedia.org/r/#change,4481 [18:06:31] <^demon> As is CentralNotice. [18:06:52] Hmm, Roan and Brion have both +1'd that one [18:06:56] yes, but that changes way less often and fraud filters aren't there [18:07:17] <^demon> *nod* Understood. [18:07:42] AaronSchulz: is that the change Ben is waiting on? [18:07:43] ^demon: is there anyone else who we could talk while you are busy? [18:07:46] RoanKattouw: am I right in presuming you have your plate full today and thus I should not ask you re 20% issues/items? [18:08:07] <^demon> pgehres: Perhaps we could hammer this out on-wiki somewhere? Deployment branch strategy really depends on how you deploy, and fundraising is a black box to me right now. [18:08:15] New class not added to AutoLoader! :p [18:08:52] sure, if you create a page on mediawiki where you feel it should go, K4-713, Jeff_Green and I will fill in the details [18:10:08] sumanah: I have my plate today *with* 20% time (the 1.20wmf01 deploy) [18:10:20] robla: ben? no [18:10:36] so, that's what shall consume you, Roan, so I shall not ask for any other or more [18:11:04] ^demon: you can merge https://gerrit.wikimedia.org/r/#change,4481 ;) [18:11:06] we're 10 min into the deploy window... Reedy: you about to cut the wmf/1.20wmf01 branch? [18:11:18] I'm waiting for us to decide what we're doing with these revs [18:11:27] It would seem we're ok to merge it, it's got 2 seperate +1s [18:11:27] fair enough [18:11:40] <^demon> pgehres: http://www.mediawiki.org/wiki/Git/Conversion/Fundraising, we'll work from there. [18:11:41] yeah, I'd say do it at this point [18:11:47] ah, 4481 [18:11:53] we can always back it out if we get cold feet [18:11:56] Oh yeah I'll +2 it [18:12:09] Well, backing it out will probably cause us more issues ;) [18:12:20] ok, and who wants to handle cherry-picking the hacks? [18:12:27] I'll do it [18:12:29] I've already made a patch for most of them [18:13:12] Righto [18:13:42] ^demon: pgehres had to run, but I got the link. Thanks. [18:14:02] Reedy: You have a patch? [18:14:05] Yes [18:14:08] In that case, be my guest and go ahead [18:14:17] While you lot were sleeping, some people were working :p [18:14:29] I wasn't sleeping [18:14:35] I was in pain [18:14:39] * RoanKattouw curses his sinuses [18:14:47] BTW, Features team remember to update http://etherpad.wikimedia.org/FeaturesTeam2012-W15 and msg me here or on the channel from now until noon. [18:14:52] http://etherpad.wikimedia.org/DeploymentChecklist for those following along at home [18:15:00] * Reedy presses enter [18:15:34] <^demon> RoanKattouw: Fine, while you were being a masochist other people were working ;-) [18:15:51] Ahh right, today is Tuesday. Carry on! [18:16:31] RoanKattouw: sorry to hear that, have same crap as well; wish you get better soon (or what's an English idiom for that) [18:16:40] Back in a few minutes. Waiting for git clones [18:17:07] <^demon> vvv: "Get well soon" [18:17:18] ^demon: thanks [18:18:16] AaronSchulz: "* Add symlink in 1.20 FlaggedRevs/maintenance to WikimediaMaintenace/wikimedia-periodic-update.sh" <- are you doing this, or waiting for someone else to do it? [18:18:51] <^demon> That's going to have to be a live-hack. I know of no way to commit that. [18:18:55] <^demon> Ouch... [18:19:15] you can add symlinks to svn/git...but it only needs to be a live hack [18:19:20] it's only for transition [18:19:45] <^demon> Yeah I know, I'm just saying that wmf branch pulls master submodules, so if you commit to it then it'll go to master. [18:20:01] <^demon> I'd just live-hack it on fenari, commit so it's not lost, then don't push back to gerrit. [18:20:16] ewww [18:20:36] doesn't git have some sort of branching feature? :) [18:20:45] <^demon> I heard that, but I hadn't tried it. [18:20:52] <^demon> Don't wanna use experimental features. [18:21:38] <^demon> robla: So you're saying branch FlaggedRevs for this one live-hack that'll only be needed for the duration of this deploy? [18:22:34] ^demon: don't we have to have a wmf/1.20wmf01 branch for all deployed extensions anyway? [18:22:50] <^demon> Nope, new branch pulls their submodules as of master. [18:23:21] ok....we're going to have to have a streamlined way of doing live hacks to extensions that's better than that [18:23:49] <^demon> Live hacks to core are easy. I hadn't considered extensions yet. [18:25:23] <^demon> Thoughts? Anyone? [18:25:28] there's really not much of a difference in git between a tag and a branch, right? [18:25:40] Back [18:26:19] I think for this deployment, we shouldn't make any radical changes, but for wmf/1.20wmf02, here's what I propose: [18:26:50] step 1. branch all extensions at the current tip of master [18:27:23] step 2. then do the submodule dance, pointing at the branch tip rather than the master tip [18:27:36] step 3. profit [18:31:07] Ok, so [18:31:13] We want to revert out all of the NS updates, yes? [18:32:12] Reedy: we don't need to rush a decision on that [18:32:20] Fine, I'll leave them for now [18:32:27] PUSH! [18:32:47] * Reedy waits [18:33:10] apparently it's done.. [18:33:26] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=log;h=refs/heads/wmf/1.20wmf1 [18:33:41] Looks good to me [18:35:36] <^demon> +1, looks good so far. [18:35:41] git clone -b wmf/1.20wmf1 ssh://@gerrit.wikimedia.org:29418/mediawiki/core.git php-1.20wmf1 [18:36:11] <^demon> robla: Actually, I'm inclined to move forward and just cross the extension-live-hack bridge when we come to it. [18:36:22] bah, -@ [18:36:41] ^demon: Rob and I were talking about how submodules work, we don't quite understand [18:36:49] Magic [18:37:02] <^demon> RoanKattouw: I'm not an expert, but ask :) [18:37:18] cloning to /tmp on fenari [18:37:33] Well, so, is there a way we can have the 1.20wmf1 branch behavior we want with submodules? [18:37:41] bummer.....1.20wmf1 instead of 1.20wmf01 [18:37:47] i.e. when you commit to the extension, it commits to 1.20wmf1 instead of master? [18:38:05] robla: do we want the extra 0? [18:38:14] not the end of the world, but the sort order gets messy once we get to 1.20wmf10 [18:38:31] <^demon> RoanKattouw: We'd have to branch all extensions with wmf branches. And in most cases, that's unnecessary. [18:38:43] we should be able to just create another branch from that one with the new name.. [18:39:06] ^demon: we should at least have a tag [18:39:24] not sure why we should be stingy with branches [18:39:31] checked out to /tmp [18:39:31] cp [18:39:32] ^demon: I agree it's unnecessary but it's easy to script :) [18:39:55] <^demon> I'm not saying to be stingy, I'm just saying it confuses things. [18:40:24] anyway, we can roll with only core branching for this branch, but... [18:40:26] <^demon> Tags aren't really useful here. [18:40:56] No, tags aren't useful [18:41:08] I think 1.20wmf1 branches for all extensions would be helpful re figuring out what's deployed [18:41:17] <^demon> You know what's deployed. [18:41:18] The submodules tell you that too, but submodules are dark magic [18:41:33] <^demon> It's all in .gitmodules and the extensions/Foo files that got committed. [18:41:39] I agree it's somewhat duplicative but I think it makes things easier all around [18:41:57] anyway, for FlaggedRevs, we absolutely should branch [18:42:32] <^demon> Ok, let me open up make-wmf-branch and write this in. [18:42:50] * ^demon also opens up git submodule add's manpage again [18:42:55] reedy@fenari:/usr/local/bin$ ./refreshWikiversionsCDB [18:42:55] PHP Warning: require_once(/usr/local/bin/defines.php): failed to open stream: No such file or directory in /usr/local/bin/refreshWikiversionsCDB on line 4 [18:42:55] PHP Fatal error: require_once(): Failed opening required '/usr/local/bin/defines.php' (include_path='.:/usr/share/php:/usr/share/pear') in /usr/local/bin/refreshWikiversionsCDB on line 4 [18:42:57] bleugh [18:43:42] sumanah: I'm looking at SubpageSortkey today [18:44:04] Reedy: Needs to be run from a specific path [18:44:04] odd [18:44:05] I guess [18:44:16] missing dirname( __FILE__ )? [18:44:39] require_once( dirname( __FILE__ ) . '/defines.php' ); [18:45:09] Yeah but refreshWikiVersionsCDB is in /usr/local [18:46:30] Reedy: No offense but WTF are you doing? [18:46:42] roan's "intelligent question" [18:46:53] Rebuilding wikiversions.cdb [18:47:02] * AaronSchulz would have never guessed [18:48:28] Works fine from /home/wikipedia/common/multiversion [18:48:42] so....the office conversation is going something like this: "did Reedy just deploy to test2 without telling us? is he running refreshWikiVersionsCDB manually rather than using scap? Roan, can you figure this out?" [18:48:43] Yeah that's what sync-wikiversions does [18:49:03] I guess I should fix the one in /usr/local/bin [18:53:38] <^demon> RoanKattouw, robla, Reedy: http://p.defau.lt/?IAZLD6aX1T9f3NPMYV8Jkg [18:54:32] Looks good [18:54:39] gerrit-wm New patchset: Catrope; "Fix /usr/local/refreshWikiVersionsCDB" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/4652 [18:55:09] sure, that works. presumably, we'll have to manually fix up 1.20wmf1 now, but that will help us for 1.20wmf2 [18:56:12] Reedy: ^ I guess I didn't respond above. no point in renaming to "1.20wmf01" now...minor pet peeve, not a major thing that needs cleanup. [18:58:41] TrevorParscal: ping [18:58:52] just so I know what the status of stuff is now. RoanKattouw, you're fixing up sync-wikiversions, and Reedy, you're waiting on Roan? [18:59:00] I fixed it but it's non-urgent [18:59:02] RoanKattouw: why do we have the one file in gerrit? [18:59:08] gwicke: hi [18:59:16] hi Trevor! [18:59:18] AaronSchulz: We shouldn't, that's why I made it a wrapper [18:59:28] ah, I see in the diff [18:59:29] For some reason /usr/local/bin contains a copy of that script [18:59:43] It shouldn't be there, so I just made it a shell wrapper for b/cc [18:59:46] TrevorParscal: looked a bit at the serializer code and wondered if you are working on it right now [19:00:22] i'm not [19:00:25] today is my 20% time [19:00:38] k [19:00:42] I'm working on the OnlineStatusBar extension [19:00:50] Bah [19:00:59] Bah? [19:01:01] checkoutMediaWiki is set to only accept letters [19:01:12] (it creates some useful symlinks etc) [19:01:20]