[15:50:11] Hm.. anyone know what's wrong with translatewiki ? Keeps returning Main page: http://translatewiki.org/wiki/Special:Prefixindex/MediaWiki:centralauth [15:50:15] not a redirect thoguh (url stays) [15:51:35] Oh, right. It's *.net and .org is a site-wide iframe xD [16:49:44] <^demon> jorm: Thanks for clarifying :) [16:49:53] np. [16:50:09] i'm not done with this, btw. [16:50:25] <^demon> I do like the new help boxes. [16:50:29] <^demon> Way nicer looking [16:51:41] <^demon> I tried to Vector-ize it this morning. Didn't go so well. [16:53:33] trevor is going to help me with that. [18:02:24] jorm_: Meeting? [18:02:36] I just kicked robla and Tomasz out of "our" 2002 [18:02:45] lol [18:02:49] "GTFO MAI ROOM" [18:02:58] hi RoanKattouw [18:02:58] HEH! [18:03:05] It's MINE! [18:03:12] Get off my lawn, kids! [18:03:16] Or wait, that's for the old folks [18:03:17] :D [18:03:28] RoanKattouw, Most of them are older than us ;) [18:03:36] All of them [18:03:40] WAY OLDER. [18:03:41] Except Andrew [18:03:43] Ya [18:03:45] *Reedy contemplates joining 2002 to annoy RoanKattouw [18:03:49] And don't you forget it, you young whippersnappers. [18:03:52] does SIP work on my phone... [18:04:06] IIRC it did [18:05:41] *Reedy tries another wireless network [18:06:25] aha [18:06:59] hmm, i wonder if i actually joined [18:07:03] it sounds ery quiet [18:07:16] though, i'm in a lecture so can't speak [18:07:38] Parul's taking right now [18:07:42] So it's not quiet [18:09:37] hmm, the numbers are wrong [18:11:25] it seems to just manage to ring random numbers then do nothing [18:11:27] that's interesting [18:12:02] *Reedy shrugs [18:22:45] TrevorParscal: We're not making any changes to what before 2.0? [18:22:48] (Call broke up a bit) [18:23:58] um... not sure [18:24:02] Gadegets [18:24:06] that's what [18:24:34] OK [18:24:40] *Gadgets [18:24:42] Do we intend to do full {{PLURAL}} support? [18:24:50] it's not critical [18:25:03] we can deploy with or without [18:25:19] ideally with, but we shouldn't let it block [18:26:36] OK [18:27:43] RoanKattouw: you see my post on the list about deployment queue? [18:28:03] Haven't read that thread yet [19:02:00] alolita: Did you share that UW doc with me yet? [19:08:09] RoanKattouw, just shared it with you [19:10:17] Thanks [19:13:03] basile: OK... that doesn't tell me a whol lot but I guess flipzagging and I can go over it after lunch [19:14:29] yep [20:26:57] RoanKattouw: howdy [20:34:02] RoanKattouw: what's up [20:34:40] RoanKattouw is hiding [20:36:36] don't blame him [20:37:08] I'm here [20:37:11] Was on the phone [20:37:34] RoanKattouw: it just occurred to me that I need to de-RL this code before I merge [20:37:36] otherwise I'm close [20:37:41] shouldn't you be asleep? [20:37:50] Nah [20:37:53] 9:39pmp [20:38:04] I'm not *that* young ;) [20:38:14] hah [20:38:28] (We had the DST switch already so the time difference is an hour less now; that's kinda confusing) [20:38:29] I agree w/ you and Trevor that need-enable seems wrong [20:38:47] :) [20:38:53] RoanKattouw: I know, interestingly enough Google Calendar warned me about it, since I have an alt-timezone in +0 [20:39:30] I think it's sort of strange that there are bugs associated with patches [20:39:32] ha [20:39:37] or even entire features [20:39:46] Yeah I had Pacific Time set but it DST-switched that one as well [20:39:47] does it feel weird to you? [20:39:55] Had to set "Pacific Time / Tijuana" or it wouldn't work right [20:40:08] Strangely the closest anchor cities were Tijuana and Vancouver [20:40:09] it = the idea that there is a bugzilla item for a patch that needs to be moved over [20:40:21] Only a little bit [20:40:23] Doesn't bother me [20:40:34] We also have bugs for config changes [20:40:37] I mean, I could understand tagging a changelist (although SVN doesn't really allow that) [20:40:45] I need to stop writing on this post, I'm getting frustrated [20:40:59] flipzagging: Oh wait you mean a bug for "merge X into Y"? [20:41:04] yes [20:41:08] that seems weird to me [20:41:26] because the definition of what X and Y is are going to change, and you'll have to keep updating the bug. [20:41:37] Yeah so for *merges*, you tag revs in CR [20:41:43] ok [20:41:48] For *patches* (things that aren't in SVN anywhere yet), bugs are reasonable [20:41:55] RoanKattouw: how have we already lost sight of the position that was established in D.C. where deployment is the center-point of the review/merge/deploy cycle, not review? [20:42:25] TrevorParscal: I very deliberately lost sight of that in my post, didn't you notice? [20:42:37] yes, and I'm confused why [20:42:40] Deployment is the conceptual center point [20:42:44] Workload-wise, review is [20:42:59] By that I mean that the reviewer should take the code they review and run with it for the rest of the process/cycle [20:43:03] I know, I read your writing 2 times [20:43:16] I'm not saying we dissagree [20:43:36] I'm saying it seems dissonant to what RobLa is working towards... [20:43:50] Hmm [20:43:56] You're saying it's straying off topic? [20:44:07] *robla reads backlog [20:44:12] Very possible, I just took everything I thought was wrong and rebuked it [20:44:18] hi robla [20:44:30] maybe this is offtopic, but does it seem weird to anyone else that we have these concepts of "features" but they sort of exist in some hazy area between bugzilla and svn merging? [20:44:32] Without paying much attention to where the thread started at, my istake [20:44:52] where would I go if I wanted to know what a feature was, what files it affected [20:44:53] i'm somewhat confused about that post, initially it seemed we were discussing extension review/deployment - but it seems it moved to general review/deployment [20:45:13] roberthl: Yeah that's what Trevor was saying I think [20:45:19] hee....ok, where to start.... [20:45:35] I'm saying that what I took away from the conversation in D.C. is that by us focusing on review we lost sight of what to review and would nearly never deploy it [20:45:45] flipzagging: Yeah, right now you kinda don't. I think robla was trying to kinda fix that with his projects listing, but only did the EPM end of it (who's involved, high level description) rather than the dev end (which files) [20:46:15] I wasn't part of the DC discussion but IMO it's essential to have the dev end [20:46:24] <^demon> TrevorParscal: If we take that approach, things not affecting deployment won't get reviewed. [20:46:28] TrevorParscal: OK so what I think we should do is focus on deployment when thinking about the grand scheme of things, but when dealing with specific things, review is at the center, practicaly [20:46:45] ^demon: in what case should we be reviewing things that will not be deployed? [20:46:50] flipzagging: It is. You're bringing up a deficiency I hadn't even noticed. [20:46:56] Because usually I either just know or don't care [20:47:03] so...the project pages are EPM-centric because EPMs are the only ones writing them right now. However, we don't have to limit the format to just the stuff that the EPMs are explicitly staying on top of [20:47:12] right [20:47:18] <^demon> TrevorParscal: *All* changes to core should be reviewed, regardless of whether they affect WMF [20:47:22] <^demon> Installer being a great example [20:47:28] and from a dev perspective, perhaps a single EPM feature is really multiple tech features (or vice versa). [20:47:34] Yes [20:47:39] Installer is also an example of something that probably should have a project page :) [20:47:47] Yes, all core changes should be reviewed [20:47:56] <^demon> robla: [[mw:New-installer issues]] is the closest we've got ;-) [20:47:57] This discussion desperately needs to regain its focus on extensions [20:48:04] ^demon: interesting point - perhaps deploy/release should be somewhat merged in my comments then [20:48:10] would anyone be offended if I went ahead and formalized the Aryeh method of pushing changes? [20:48:20] in other words a centralized feature flag flipper [20:48:32] It's been used before [20:48:41] Feel free to formalize, but don't encourage overuse [20:48:46] flipzagging: I'm so offended! Agh! (anger and screaming)... (not really) [20:48:54] what I mean by formalize is a page that lists "features" that could be enabled. [20:48:58] It's a tactic that's suited to somethings and not suited to others [20:49:02] Oh right [20:49:14] Like a distilled version of [[Manual:Configuration variables]] ? [20:49:30] this is separate from general config, or a subset thereof let's say. [20:49:32] flipzagging: sounds like a fine idea [20:49:42] ok, no promises but I'll give it a shot [20:50:21] ^demon: but the point of a deployment queue is not to be the ONLY reason code gets reviewed, it's just that review must take place (hence my use of the phrase by-product) [20:50:41] <^demon> Yeah I agree there. [20:50:54] <^demon> I'm just saying if we only focus on deployment then other stuff might get forgotten :) [20:50:59] I think having a deployment queue which causes code to get reviewed, can run in parallel to normal review for releases [20:51:00] TrevorParscal: did you read my latest email to the list? [20:51:41] robla: yes, but I will need to read it again.. the 7 states sort of seemed so complex my eyes were sort of glazing over [20:52:20] TrevorParscal: well...let me paraphrase the important part [20:53:03] it's important for those of us who are trying to keep track of this stuff (e.g. me) that we maintain a distinction between deployment-bound stuff that hasn't been reviewed, and the stuff that has [20:53:29] thats what the new/fixme/reverted/resolved/ok state is for [20:53:37] in bugzilla [20:53:41] why? [20:54:03] I'm not morally opposed, I'm just noticing that now you are splitting the work between 2 tools? [20:54:08] see this list: https://bugzilla.wikimedia.org/buglist.cgi?keywords=need-review&query_format=advanced&keywords_type=allwords&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=Site%20requests&resolution=---&product=Wikimedia [20:54:32] I'm trying to make sense of that list, but I don't have good metadata to attach to that list [20:54:54] well, my first question is why does this stuff need review? [20:55:25] and my second question is what actual code do these requests call for review of? [20:55:32] some of them are better than others [20:55:59] but these are pretty hard to connect to actual code in the cases I'm seeing [20:56:29] so is the "need-review" tag, as exists, useless? [20:56:46] to be honest, I think that at point it's premature to ask for review for new features/extensions whatever [20:57:14] we're more than a thousands revs behind on phase3 alone [20:57:20] yeah I think it's useless [20:57:43] well, that's a big problem then [20:58:19] once caught up on code review, site requests like this should be requests for deployment, and review may or may not be done - and may be driven by the task of satisfying one of these requests [20:58:37] we could put phase3 on top of the review queue :p [20:58:40] s/done/complete/ [20:59:17] no....we need a place for non-devs to request features [20:59:41] I don't want to be evangelizing the idea of a deployment queue if everyone thinks it's dumb, I'm mostly just defending my understanding of the progress made in D.C. on the subject [21:00:29] robla: request for deplyment is no more difficult for non-devs to make, and all of these requests are in fact requests for deployment [21:00:54] sure...but they're in various states of completion [21:00:55] they are not saying please review some code, they are saying "set this up", "enable that", "turn on this thing" [21:01:01] yup [21:01:04] 15308 is not a deployment request [21:01:22] although it seems to be the only one that isn't [21:01:46] fair enough, but it's sort of a strange request - shouldn't that be an implementation detail for what they are really getting after, deploying that extension? [21:02:06] It starts with "I am planning to start a vote about whether the Babel extension should be [21:02:06] activated on the German wikipedia" [21:02:12] yeah [21:02:28] TrevorParscal: we need a place where we track the implementation details [21:02:48] Seems like bugzilla is a good place to start [21:03:03] isn't that the point? [21:03:23] roberthl: yup, I think so [21:04:49] I'm sure we agree on most of this, I am specifically presenting the idea of having 1 queue, which is a deployment queue, meaning to be marked resolved it would need to be deployed or not [21:04:59] you could use any queuing system for this [21:05:03] even R.T. would work [21:05:11] each system with it's own pros and cons [21:05:33] *RoanKattouw is officially zoning out now and watching CNN [21:06:21] my point is that if the resolution comes only when something is deployed or decided to never be deployed, than contributions from everyone (staff and volunteers alike) will not be lost in the void of reviewed and forgotten [21:06:34] or not reviewed and unknown [21:07:08] You're saying there's only one useful state to keep track of, which is whether or not it has been deployed, which misses my point [21:07:31] it may be one queue, but there are multiple steps which are useful to keep track of [21:08:59] you seem to be proposing a large level of additional work and complexity to enable quantitative analysis [21:09:20] bugzilla already provides qualitative information to be stored for each request in the form of comments [21:09:23] you seem to be proposing that we keep all of this in our heads [21:09:40] ...or worse, having to read the comments to figure out what state an issue is in [21:09:49] Worse? [21:09:53] worse [21:10:02] ok... [21:10:28] I want to be able to size up an issue and actually mark it, so I don't have to start at the top of the list every time I want to figure out the state of the queue [21:11:34] so you are proposing that we use a collection of tags which in various combinations mean different things, which we are all supposed to calculate in our heads, to describe these states? [21:12:18] I think we might be able to simplify the list of tags, but I don't think it's as complicated as you're making out [21:12:45] ...and we would document all of this [21:13:09] ...and make it so that the process for seeing a particular queue is: "go to a wiki page, find link, click it" [21:13:30] my point is, a sustainable system is a simple one, and the simpler the system can be the more likely it will actually be used and maintained [21:13:42] so if you can make this simple, you will have my support [21:13:57] it doesn't look simple the way you described it, so I started getting nervous [21:14:19] and it wasn't very deployment-centric so I started getting worried we weren't fixing a major problem [21:14:53] brb- meeting [21:14:54] ok....that's fine. You still haven't acknowledged my need to tell the difference between a deployment-bound item that hasn't been reviewed, and one that has [21:24:37] Bryan: (or anyone) is there a relatively easy way of generating a graph/table over time of the historical state of the review queue? [21:25:29] robla: no there is no easy way to do that [21:25:38] luckily, I did that hard work for you ;) [21:25:41] http://toolserver.org/~bryan/stats/codereview-status.png [21:26:00] http://toolserver.org/~bryan/stats/codereview-status.sh [21:27:15] thanks! [21:27:47] *robla digs up his old toolserver access request to see what happened to it [21:29:59] the source that is available in that directory, so you can regenerate the graph at different time intervals yourself [21:30:20] btw those are the things I love about python [21:30:22] open('code_ok_time.txt', 'w').writelines('%s %s\n' % (i[1].strip(), i[0]) for i in enumerate(open('code_ok.txt'), 1) if i[1].strip()) [21:30:24] open('code_all_time.txt', 'w').writelines('%s %s\n' % (i[1].strip(), i[0]) for i in enumerate(open('code_all.txt'), 1) if i[1].strip()) [21:30:36] AryehGregor: is this something you can help me out with? https://jira.toolserver.org/browse/ACCAPP-223 [21:31:27] robla, poke felicity_ [21:31:35] indeed [21:31:39] or Duesentrieb [21:31:42] Yus [21:31:57] robla, and probably poke them in #wikimedia-toolserver [21:32:25] I think dab first should officially say "yes" before some root can continue creating your account [21:37:03] k...thanks [21:42:29] Bryan: you said earlier: "we're more than a thousands revs behind on phase3 alone"....that's not what your graph is showing [21:43:05] then my graph is wrong [21:43:16] oh...I see there's a zero missing on the left hand labels [21:43:52] no, there is somethign odd out there [21:48:07] <^demon> We're between 1000 and 1100 revs behind on /trunk/phase3 [21:48:33] I fucked up with the JOIN in the second query [21:48:35] <^demon> 1082. [21:49:00] <^demon> That's "new." There's 38 fixmes on phase3 [21:53:01] there: http://toolserver.org/~bryan/stats/codereview-status.png [21:53:03] that looks better [21:53:13] (ctrl+f5 to bypass your cache) [21:54:05] <^demon> Should there be a scale on the right side for total revs? [21:54:57] uh no? [21:55:11] note that the graph is revs in /trunk/phase3, not in / [21:56:03] also, it also only takes into account revs that had their status changed via codereview (-> entry in code_prop_changes) or are new [21:56:34] <^demon> Shouldn't there be more revs than ok revs then? [21:57:26] green is the number of revs [21:58:38] <^demon> Wow. [21:58:41] <^demon> Yeah [21:58:47] <^demon> I swear I'm not color blind. [22:00:15] im'off to bed, so if there are any questions or incorrectness, you'll have to check the source code [22:02:09] ^demon, the source of your confusion is probably because the labels are in reverse order from the curves [22:02:18] <^demon> Probably :) [22:03:07] wow, that's impressive [22:03:34] it's funny how the backlog has remained relatively constant at 2000 [22:03:49] is it possible those are the same revisions [22:05:00] you can see the effect of the new code reviewers, though. Slope kicks up a bit. [22:08:34] flipzagging: so, did you make any progress with the language stuff before switching gears/ [22:08:43] no, didn't even start [22:09:03] ok [22:09:05] no worries [22:09:11] just wondering where I should start :) [22:09:17] at the very beginning [22:09:18] The end! [22:09:21] a very good place to start [22:09:32] esp. in this case [22:09:37] hi Reedy [22:09:40] loha [23:37:54] RAAAAAAAAGE. [23:47:53] nimish_g: Why are you committing directly to the WMF branch? [23:48:57] because we're trying to deploy this today [23:49:14] Shirley: ^^ [23:49:40] nimish_g: but you promise to backport? [23:49:43] It seems like a pretty poor idea and practice to commit directly to the WMF branch like that. [23:49:56] nimish_g: do not commit to that branch, merge into that branch [23:50:06] or you will get reverted [23:50:57] TrevorParscal: Shirley flipzagging It's this extension http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/LandingCheck/ and I did a svn copy to put it in deployment. I didn't just make some code and put it in there directly [23:52:24] So you didn't change the code? You just merged it from trunk? [23:52:30] yes [23:52:34] Okay. [23:52:43] Mention that in the commit summary, please. :-) [23:52:47] can we even tell the difference in codurr ? [23:52:51] perhaps a better commit message would have helped, it says "creating" [23:53:08] http://svn.wikimedia.org/viewvc/mediawiki/branches/wmf/1.16wmf4/extensions/LandingCheck/LandingCheck.i18n.php?view=log [23:53:20] "MFT" is your friend. It's the only way we can track merged code in SVN, as far as I'm aware. [23:53:22] I can see the history of where it came from [23:53:31] Hmm, fair enough. [23:53:48] Shirley: is that a convention for commit messages, if so how does one use it. [23:53:50] ? [23:53:50] but yeah - "creating" sort of threw us nimish [23:54:22] "merged from trunk" ? [23:54:25] 'creating' suggested it was written there, [23:54:27] flipzagging: example: 1.16wmf4: MFT r74311 [23:54:33] ok [23:54:38] flipzagging: You type "MFT rXXXXX". [23:54:43] Oh, Trevor got it. [23:54:46] Example: http://svn.wikimedia.org/viewvc/mediawiki/branches/wmf/1.16wmf4/extensions/CodeReview/?view=log [23:54:56] Here's one Tim did "Merged all changes from trunk/extensions/Collection up to HEAD (r65974)" [23:55:00] The description of what was done would be in the commit message of the original revision. [23:55:17] probably less of a magical format, more of mentioning the words merge, trunk and a relevant revision number [23:55:26] Yes [23:55:29] Rev number is essential [23:55:33] of course [23:55:38] Plus some vague indication of where it came from [23:55:43] 'trunk' is good enough [23:55:56] And when in doubt, copy from the veterans :) [23:56:35] there are a number of veterans who seem to get this wrong. ;) [23:56:47] *TrevorParscal copy-pastes Tim's code from 2006 [23:57:16] anyway, * * * the more you know [23:58:02] flipzagging: aww.. i wasn't done attacking mish mish [23:59:53] AGH! http://svn.wikimedia.org/viewvc/mediawiki/trunk/phpwiki/fpw/wikiPage.php?revision=20&view=markup&pathrev=20