[00:01:32] should we have a separate channel for the git meeting? this channel seems pretty busy [00:02:20] I can shut up about things unrelated to git [00:02:31] *sumanah looks at http://etherpad.wikimedia.org/Git [00:02:39] <^demon> I'm finishing up a phone call, will be just a minute or two and we can get started. [00:05:30] <^demon> Alrighty. From our meeting earlier, we managed to agree on the repo structure and naming conventions. [00:05:43] <^demon> Then we began to discuss the merits/issues with gerrit. [00:06:57] <^demon> The impression I got is that this is more confusing a migration than I had estimated, and giving people more "playing around with it time" would help. [00:07:02] <^demon> Does that sound accurate? [00:07:19] I think you are right, ^demon [00:09:03] ^demon: I think we should aggressively request beta testing from different kinds of developers ... WMF, extension, Wikia, i18n folks, etc. [00:09:48] <^demon> I'd like to at least get more than one core dev playing with it first ;-) [00:10:15] ^demon: and then iterate based on that feedback, then go after more of the community? [00:10:43] <^demon> *nod* [00:11:19] <^demon> I'd love to get the process of "getting your ldap account setup with gerrit" more automagic. [00:11:27] <^demon> So we can stop bugging Ryan_Lane. [00:11:28] ^demon: ok. is that a Ryan_Lane dependency? [00:11:29] so.... [00:11:30] ha [00:11:39] you don't actually need me to make the accounts [00:11:59] also, at some point, people should just be able to make accounts through labsconsole [00:12:18] for svn people, we'd obviously want to make the accounts for them [00:12:33] <^demon> Right, I'd like to see everyone who's currently in SVN be setup. [00:12:35] otherwise the accounts wouldn't link properly [00:12:43] you can link the accounts [00:13:14] <^demon> How? [00:13:32] add-labs-user ???wikiname="" ???mail="" " [00:13:35] err [00:13:39] add-labs-user ???wikiname="" ???mail="" [00:13:45] where ??? is -- [00:13:51] stupid autocorrecting client [00:14:16] on formey [00:14:47] then the people need to follow instructions at: https://labsconsole.wikimedia.org/wiki/Access#Initial_log_in [00:15:23] hmm. do you have access to that command via sudo? [00:15:29] *Ryan_Lane checks [00:15:52] yep [00:15:53] you do [00:16:10] <^demon> Mmmk, good to know now. [00:16:26] in fact, you can make labs accounts for anyone too [00:16:47] <^demon> Well, I got most of my questions answered in the earlier meeting. I guess I'll open the floor to any questions/comments/concerns about the migration. [00:17:25] ^demon: will there be unicorns, and fairy tears, and free kittens? [00:17:39] <^demon> Only if you sign the contributor agreement ;-) [00:17:44] :D [00:17:50] are we going to have one of those? [00:18:48] <^demon> No, I know of no plans to use the contributor agreements feature in gerrit. [00:19:20] is it possible to continue merging changes to trunk and the release branches of the subversion server after the migration for the benefit of general MW users doing production document root MW checkouts? [00:20:22] <^demon> I assume it'd be possible. The plan was to leave the SVN box up as a read-only version anyway. [00:20:42] <^demon> So I don't see any reason we couldn't automate a user to merge them to svn once they're accepted into master. [00:20:59] if subversion has any strengths over git then it's for that application [00:21:14] <^demon> Ryan: Possible via gerrit post-merge hook probably? [00:21:49] a lot of people probably have subversion checkouts who don't really care about development practices [00:21:50] so, gerrit hook would trigger a git->svn update? [00:22:00] <^demon> Right. [00:22:12] <^demon> After it's been accepted to master, so abandoned changes wouldn't get merged. [00:22:14] I don't see why not [00:22:19] <^demon> And you'd only get the final changeset. [00:22:30] we can do it via the patchset-merged hook [00:22:49] and can check the branch, to ensure it's only the master [00:23:19] <^demon> Well, we'd want master -> trunk, and the release branches to go to their appropriate branch [00:23:31] that should be doable [00:24:13] I think it'd be a nice touch [00:24:22] this is going to be http-only svn, right/ [00:24:26] <^demon> I agree, thanks for bringing it up. I'll add it to my "list of scripts that need writing" [00:24:27] can we kill off the ssh access? [00:24:36] I have a *lot* of source tree checkouts on my hard drive, it always annoys me when one of them stops updating with no explanation [00:24:37] <^demon> Yeah, we should be able to kill the ssh access. [00:24:50] can we kill off the users on the system too? [00:25:05] yes [00:25:07] Ryan_Lane seems bloodthirsty [00:25:12] \o/ [00:25:19] I don't want LDAP running on any production systems [00:25:34] the histories and everything will still look the same with all the users deleted [00:25:40] great [00:25:54] maybe you could have one SSH user for the git -> svn push [00:26:05] well, they are on the same box right now [00:26:10] right [00:26:23] I think it's probably ok to keep it that way [00:26:24] <^demon> I figured we'd just have a single bot user doing the git->svn push [00:26:33] <^demon> Which would have rw, and everyone else could just have r. [00:26:39] the hooks run as the gerrit user [00:26:43] it can just own the svn repos too [00:27:46] see if there's a script around for it already [00:28:52] you don't want to write your own script and then discover that some rare event breaks it once a month or so [00:29:17] best if it's zero maintenance [00:29:26] agreed [00:29:32] you instead want to deploy someone else's script and discover that some rare event breaks it once a month or so :) [00:29:33] <^demon> It looks like it's just a matter of doing some stuff with dcommit. [00:30:24] hmm. I don't have a gerrit labs project up yet, do i? [00:30:31] I'd really like to test this somewhere not production [00:30:34] <^demon> Don't think so. [00:30:51] *Ryan_Lane goes to make a project [00:31:34] <^demon> How difficult will it be to make that web UI for creating new gerrit projects? [00:31:58] <^demon> Because if we're doing one-project-per-extension, that's going to be a PITA to manage for each new extension someone dreams up :) [00:32:11] probably not terribly hard [00:32:21] the gerrit commands are run via ssh [00:32:30] php has an ssh module [00:33:07] should we find a contractor who doesn't mind developing in Java to do work on things like Gerrit? [00:33:12] of course now that I said it shouldn't be too hard, I'll find out that it's incredibly difficult :) [00:33:23] robla: that would be nice [00:33:34] *robla doesn't want to have a custom feature for something that seems like everyone would want it [00:33:34] what's gitorious written in? [00:33:34] <^demon> robla: If we've got the contracting dollars for it, I think ++ [00:33:41] <^demon> php? [00:33:57] gitorious is ruby [00:34:05] *Ryan_Lane pukes [00:34:15] ok. so, back to that java developer :) [00:34:20] lol [00:34:34] <^demon> We had our daily dose of ruby :) [00:35:09] no one likes ruby :'( [00:35:13] there's a number of features we'd like to add to gerrit [00:35:22] so, it would be nice to have a contractor, if possible. [00:35:22] <^demon> We should be ultra-aggressive in collecting bug reports and pushing them upstream. [00:35:29] +1 [00:35:33] it's managed by google [00:35:36] <^demon> Even if we don't get a contractor, we can always throw them there and hope google devs care :) [00:35:44] if we don't add the features, it's unlikely they'll get added [00:35:55] we should team up with the openstack people [00:36:04] they also have a number of things they want added [00:36:07] yup, push them upstream, then if we don't see any action, hire the contractor to make them happen [00:36:21] sounds good [00:36:39] let's make sure we're keeping track of the stuff we're pushing upstream [00:36:43] <^demon> Ryan_Lane: I found another bug in gerrit that annoys me today http://code.google.com/p/gerrit/issues/detail?id=862 [00:37:04] yep [00:37:10] Ryan_Lane: you've seen https://labsconsole.wikimedia.org/wiki/Gerrit_bugs_that_matter I assume [00:37:16] I thought it said "Requires verified" [00:37:27] we really need to consolidate some wikis [00:37:34] heh [00:38:23] I think Roan had a couple too [00:38:37] freeform tags, like we have in our code review tool would be really nice [00:38:47] <^demon> The summary Roan and I gave of gerrit earlier is "Yeah the UI kind of sucks, but the technology behind it is actually pretty solid and we like that." [00:38:52] <^demon> It's just the UI that needs love. [00:39:00] <^demon> Is that accurate from where you're sitting Ryan? [00:39:00] a single combined diff would be nice too [00:39:05] yes [00:39:32] I'm thinking we should add some mediawiki->gerrit integration either way [00:39:42] it would be nice to have documentation pages for each repo [00:39:47] <^demon> Too bad they don't expose a real API :p [00:39:51] yeah [00:40:00] the ssh command is enough for repo creation [00:40:25] a real API would definitely be nice, though [00:40:46] it's unfortunate that there aren't many options for git interfaces. [00:41:15] <^demon> Someone wrote a python library for interfacing with the gerrit jsonrpc interface :p [00:41:27] I'm hoping we can get out of the business of getting too crazy on custom dev tool development [00:41:49] ^demon: it isn't terribly stable, though [00:41:54] the interface, that is [00:42:08] <^demon> Yeah, that's the excuse I read for why they didn't make a web api yet. [00:42:08] robla: well, this would be fairly minimal [00:42:17] I agree with you, though [00:42:23] <^demon> Because the JSONRPC api changes too often :p [00:42:37] <^demon> So I'm like "How about you stop changing it all the time?" [00:42:37] hell, I'm trying my best to move most of my openstack code from OSM to openstack itself [00:42:38] <^demon> :) [00:42:42] :D [00:42:51] it's meant as an internal api [00:43:00] <^demon> Mhmm. [00:43:20] <^demon> But the excuse I read was "The internal API changes all the time, so we're not going to write an external API" [00:43:24] heh [00:43:28] <^demon> Imagine if we used that excuse ;-) [00:43:31] <^demon> api.php wouldn't exist! [00:43:35] heh [00:43:46] yeah. google as the project owner annoys me [00:44:02] they run open source projects in a really poor way [00:44:10] I think it's fair to say "we have no idea what a good api would look like (just look how often we change the internal api), so we're not going to publish one yet" [00:45:11] ^demon: I made a gerrit project, I'll try to get a gerrit test instance going in there [00:45:43] <^demon> We do try to avoid changing it in a breaking way, but sometimes its unavoidable, like the listOpenChanges breakage when we moved to the query syntax and a generic query API. Right now I'm not sure we can promise a stable RPC API. Though we can try harder (see below) because I know a number of people who use Eclipse would appreciate having a task connector for Gerrit." [00:46:18] ah [00:46:30] well, that's actually an acceptable answer. as long as they announce breaking changes. [00:47:26] Good morning all :) Can someone here remind me of the day you had the conversation in here about the Harvard/SciencesPo banner? [00:47:34] I'd really like an interface in gerrit to create projects, and have gerrit use the mediawiki api to add documentation pages [00:47:42] <^demon> +1 [00:47:54] rather than write an interface to go the other way [00:48:01] oh, there we go...yeah, that would be nice [00:48:05] it's cleaner, and more people could benefit from it [00:48:09] ...and general purpse [00:48:10] I'm speaking to someone who completed the work, and has not had their payment - we just need a reminder of when the banner was put up [00:48:11] that's what I'm doing with openstack as well [00:48:23] he says he did it the same day [00:48:29] <^demon> Anyway, we're coming up on an hour again. Any last questions/comments/concerns for me? [00:48:34] <^demon> Or can I wander off to find some dinner. [00:48:48] *robla skims Git etherpad [00:49:13] <^demon> "Things we still need to decide" is the important section. [00:49:31] what's the etherpad link again? [00:49:37] <^demon> http://etherpad.wikimedia.org/Git [00:50:19] I never liked externals anyway [00:50:27] ^demon: do you have everything settled that you need to tackle everything here? http://www.mediawiki.org/wiki/Git_conversion#Plan_of_attack [00:50:29] so, we're not considering gitorious anymore? [00:50:35] BarkingFish: I don't know, but it was within the last few weeks if you want to just load up each of the channel logs & do a Control-F search? [00:50:39] they're insecure since code changes are applied outside of the review process [00:50:41] (that doesn't bother me, I hate managing ruby apps) [00:50:45] <^demon> robla: "Plan of attack" is horribly outdated. [00:51:00] ^demon: could you fix that? :) [00:51:09] <^demon> TimStarling: That's part of the reason brion suggested just importing 3rd party libs by hand. [00:51:34] and perhaps stuff will break less too due to api changes [00:51:38] maybe the timeline section is the more important [00:51:47] (which is also outdated) [00:51:51] though that hasn't come up yet afaik [00:51:52] yeah sorry I was talking to the etherpad [00:52:18] you said look at that section and I did and it inspired me to say that [00:52:38] <^demon> robla: All the git pages are outdated. I suck at documentation. I'll make it my big goal to update them all tomorrow. [00:52:44] <^demon> With current status & plan of attack. [00:53:33] ^demon: cool...something rough will do, and I'm happy to collaborate on it if you want to have an etherpad session sometime [00:53:50] <^demon> We can talk about that in our 1:1 tomorrow :) [00:55:29] <^demon> Ryan_Lane: I've thought about it, and decided against it for 2 reasons. [00:55:33] <^demon> (re: gitorious) [00:55:35] from the wiki: "Will Gerrit work as repo browser, or only patch manager?". do we feel like the gitweb stuff is sufficient for our needs? [00:55:36] <^demon> 1) It's ruby. [00:55:56] *robla waits for #2 [00:56:07] 2) it's ruby [00:56:08] :) [00:56:10] its not PHP? :D [00:56:13] <^demon> 2) Duplication of effort. If we're already using gerrit for wmf stuff core, I don't (as a developer) want to have to go to our gitorious install *too* [00:56:44] well, if you guys decided gitorious was the bees-knees, and were going to use it, we'd probably switch eventually [00:56:59] <^demon> Oh and #3. [00:57:00] <^demon> It's ruby [00:57:00] I though that was part of the cabal against gerrit [00:57:22] I like gerrit workflow but is GUI is far from being ergonomic [00:57:29] we hate the gerrit interface just as much as everyone else :) [00:57:47] but gitorious being ruby is a major hurdle for us [00:58:08] <^demon> hashar: Right. Gerrit does a "push for review" model, which I kind of like. [00:58:19] <^demon> gitorious uses the github "Please review then pull my change" model [00:58:21] I think it'd be easier to find PHP programmers who would be willing to try Ruby than to find PHP devs that want to give Java a shot [00:58:26] I also kind of like push for review rather than pull requests [00:58:37] <^demon> robla: Count me out of that group. I'd take Java over PHP. [00:58:52] robla: but ops hates managing ruby apps with a passion [00:59:06] I agree with robla [00:59:06] like puppet? [00:59:08] we don't mind java nearly as much [00:59:11] TimStarling: yes. [00:59:12] want's wrong with Java? [00:59:23] <^demon> Oh, major point. [00:59:29] <^demon> Does gitorious support ldap integration? [00:59:41] the alternative to puppet is chef??? which is also ruby [00:59:42] <^demon> If not, that's a bit of a show-stopper I think. [00:59:47] ^demon: I believe it does, yes [01:00:04] <^demon> Ah, looks like it. [01:00:12] yeah, we'd need to add ldap if it didn't support it [01:00:19] what's the problem with ruby that makes it hard to support? [01:00:25] <^demon> lib/gitorious/authentication/ldap.rb [01:00:39] TimStarling: generally ruby devs want everything to come from gems [01:00:43] including ruby itself [01:00:51] right, makes sense [01:01:10] I understand from the dev perspective, but it's a bitch to manage from an ops perspective [01:01:16] especially as a non-core app [01:01:34] the good thing with github/gitorious is that volunteers can have their patches reviewed without needing to send pull requests [01:01:34] <^demon> It would be just as annoying as if we built MW using a dozen different PEAR packages. [01:01:53] I gotta head off, but am seconding Rob that (in terms of volunteers) it's easier to find interest in working in Ruby than interest in working in Java. Look at our Lucene situation for example. [01:01:53] yeah, Ruby is awful from ops perspective, I know [01:01:56] <^demon> hashar: You can review without merging in gerrit. [01:02:03] whereas in gerrit, you have to push to get reviewed. We might end up with a looong queue in gerrit [01:02:04] ^demon: well, perl apps are like that [01:02:11] they depend on a million things from CPAN [01:02:15] hashar: you can have topic branches [01:02:17] but gems are their own special kind of suckage [01:02:17] <^demon> Yeah, doesn't make it nice :) [01:02:40] I'm told that usually particular versions of libraries are required [01:02:46] *robla has another meeting to go to [01:02:53] <^demon> hashar: You still have to push to your clone and bug someone to review it and then pull [01:03:03] <^demon> With gerrit, you push and it's put in the review queue regardless. [01:03:12] No chance kaldari is around? [01:03:18] > The page at https://wikimediafoundation.org/wiki/Thank_You/en displayed insecure content from http://www.mediawiki.org/wiki/Special:HideBanners. [01:03:21] Is that a known bug? [01:03:22] <^demon> (Except i18n committers, which I think we'll give push-without-review privs) [01:03:39] should be easy to fix in the template [01:03:42] Joan, /me facepalms [01:03:47] I'll take a look [01:03:48] Oh. [01:03:52] you're in here. Sorry. Hi. :-) [01:04:37] That page is also quite ugly. [01:05:11] But that's someone's else department. :-) [01:05:32] Joan: OK, should be fixed now [01:05:51] kaldari: Just saw the edit. Didn't realize it was on-wiki. Lovely. Thanks. :-) [01:06:03] bed time for good. Have fun :) [01:06:09] <^demon> Goodnight hashar. [01:06:23] ^demon: and thanks for git :)) [01:06:49] be it gerrit or gitorious or Extension:CodeReviewGit ??? That is just an interface :) [01:07:26] *Ryan_Lane grumbles [01:07:28] <^demon> We're not writing CodeReviewGit :) [01:07:40] mental note. svn up in labs, then in production [01:07:42] I just broke labsconsole [01:07:44] <^demon> No way on earth are we going down that road. [01:07:46] *Ryan_Lane sighs [01:08:20] <^demon> We went down the "Let's write our own code review tool" road before. [01:09:17] Joan: We seem to specialize in ugly :P [01:09:24] https://wikimediafoundation.org/wiki/User_talk:Zackexley#Thank_You.2Fen [01:09:37] There are some people who like to make things prettier. [01:09:52] And some of them are willing to do it voluntarily. Site needs a few more editors. [08:41:43] good morning hashar [08:41:58] gwicke: hi : [08:41:58] ) [08:42:09] how many tests are passing nowadays? :) [08:42:22] i'm neglecting the tests really [08:42:33] working on template expansion currently [08:42:48] but eventually that should fix a lot of tests [08:42:51] ;) [08:44:15] TOC generation should be easy too [08:44:38] yes, and link/image conversion [08:45:09] but templates require changes to the underlying token transform infrastructure [08:45:23] so I try to tackle them now [08:46:53] would be great to have some kind of caching systems when resolving templates [08:47:18] per request or parser that should be simple [08:47:54] template requests are asynchronous, so can also be batched [08:48:25] the idea is to make it possible to execute the tokenizer, token transforms and tree building in parallel on multiple cores [10:21:45] I have created some notes on token transformations in the JS parser at https://www.mediawiki.org/wiki/Future/Parser_development/Token_stream_transformations, please review / sanity check / comment [18:26:10] Reedy: Hey you around? I'm supposed to deploy the XSS fixes for Contest and re-enable the extension, but could you take that from me? [18:26:17] I think that's preferable to deploy-then-flee :) [18:54:29] *aharoni waves at alolita and SQPRobin [18:58:48] good evening [18:58:49] RoanKattouw_away, it's not in use, so I guess either way it doesn't really matter [18:58:51] But I will do [19:04:12] Hi features team !! [19:04:22] ready to do our team meeting online today [19:04:55] My irc client messed itself up >_> [19:05:14] i sent out an agenda [19:05:18] let's start [19:05:33] gwicke, neilk: you there? [19:05:53] ok, will start [19:06:05] basically, what is on Etherpad [19:06:06] please do [19:06:21] this is the RFC about token transformations: https://www.mediawiki.org/wiki/Future/Parser_development/Token_stream_transformations [19:06:36] feel free to comment / ask etc [19:07:00] any questions for gabriel? [19:07:02] Reedy: I thought the same, but Erik pointed out they need it for judging [19:07:23] Ah [19:07:26] True [19:07:48] alolita: I'm sorry for being late to the meeting. Can we change the schedule a little bit so I can jump in line? [19:07:48] gwicke: anything else to add [19:07:58] (i.e. do RL2 after VE) [19:08:05] RoanKattouw: ok [19:08:11] hope to get some feedback despite christmas.. [19:08:39] but I'm done [19:08:50] gwicke: yes i hope so before we do detail design discussions in early jan on visual editor [19:08:54] thanks gabriel [19:09:02] RoanKattouw: you're next [19:09:30] Alright, thanks [19:09:37] So, I should explain why I'm so impatient [19:09:47] Roan: that would be good to know :-) [19:10:01] I live with my parents right now and they're moving, so things are crazy over here [19:10:17] I just ate dinner and I'm about to leave again to help haul a bunch of boxes [19:10:41] This also means I will probably not have internet access this Friday, so I'll be out Friday through Monday, inclusive [19:10:47] Anyway -- [19:10:49] Roan: moving is lots of fun (not!) [19:11:01] I've picked up the pace on RL2 a bit [19:11:02] well, we weren [19:11:03] 't [19:11:10] weren't going to be snapping the whip over christmas. [19:11:18] and we're off on monday, anyway. [19:11:21] Not exactly, no, and Monday is a free day anyway [19:11:23] Yeah [19:11:28] So for RL2 I've been writing unit tests [19:11:52] And I have some more things I want to do, like integrating some more of Salvatore's code and tidying up various loose ends [19:12:13] RoanKattouw: great; is there any dependency on timo completing some of the front-end parts [19:12:25] I do also need Timo to do things, yes [19:12:42] But I haven't had the time to take a comprehensive look at the State of the Project just yet [19:12:49] And probably won't until the new year [19:13:07] But I should do that when I can [19:13:32] And when AFTv5 stops taking up half my time like it's been doing this past week [19:13:49] Roan: we should definitely do a recap on RL2 functionality by first week of jan so that we can test for 3 weeks before rel 1.19 [19:14:13] I don't think we're realistically gonna get it into 1.19 [19:14:23] And I think RobLa will kill you if you even dare suggest it :) [19:14:31] However, that's OK [19:14:39] It's an extension, so it's self-contained and we can deploy it whenever [19:14:46] Roan: OK for robla to kill me ;-) [19:14:55] The only requirement is that it's deployed after 1.19 but that's not a practical conern [19:14:57] *concern [19:15:08] heh [19:15:12] Yup [19:15:13] No, it's OK not to get it into 1.19 [19:15:46] let's talk about that because we had targeted rel 1.19 initially [19:16:12] any other areas you want to cover: code review, deployment woes etc. [19:17:02] Roan: going once, then we move on to editor retention projects [19:17:12] Well so like I said AFT5 with the review and deployment and fallout took like half my time [19:17:33] But that wasn't totally unexpected and there's nothing really weird going on there [19:17:43] And the storm has pretty much blown over [19:17:48] *RoanKattouw is done now :) [19:17:56] thanks for pulling the weight on AFT v5; couldn't have done this without your help [19:18:02] thanks Roan! [19:18:11] B. Editor Retention: Feedback Dashboard [Benny, RobM, Brandon], AFT v5 [Howie, Dario] [19:18:19] Brandon: editor retention [19:18:30] feedback dashboard updates? [19:18:47] we're doing a lot of little and big things. [19:19:01] adding in "mark as Helpful" functionality is going to be pretty big. [19:19:07] to give us 360 degree feedback. [19:19:09] yup [19:19:29] there's a bit of a visual refresh happening; i'm going to be delivering the icons. . . now. [19:19:57] we have a deployment tomorrow, i believe. [19:20:08] + enabling email notification of responses and measuring the clickthrough rate [19:20:09] errr, a prototype deployment. [19:20:24] deployment to prototype tomorrow [19:20:33] push to production on thursday [19:20:38] as per Roan's schedule [19:20:48] are we going through updates by feature or by person? Sorry I missed the beginning of the meeting [19:20:49] Huh [19:21:00] No, the editor retention prod deployment window is on Wednesday [19:21:01] and testing feedback from howie, dartar [19:21:11] DarTar: By feature, see the e-mail with the agenda [19:21:19] ok [19:22:06] Roan: Wed is our scheduled window; this week we can't complete feature development till tomorrow morning; so need to test and verify for 24 hours thereafter [19:22:16] jorm: anything else to add [19:22:31] uhm, we met with wikia a lot over the past week. [19:22:51] to discuss notifications and structured discussion systems. [19:22:51] ' [19:23:20] jorm: great; any next steps on iterating with wikia [19:23:28] jorm: as in liquidthreads, or alternatives? [19:23:50] alolita: OK, that's fine. Then the deploy is the only thing I'll be doing on Thursday, cause that's moving day [19:23:51] gwicke: they have their own thing, called "message wall" and it's pretty advanced. [19:24:04] it's pretty much what LQT is *supposed* to become. [19:24:05] *RoanKattouw reschedules deployment on the calendar & wiki page [19:24:13] ah, ic [19:24:26] Roan: let me talk with howie / robm / benny to see if we can deploy on wed pm [19:24:32] we probably can't use it because the time to port it from wikia specific code is about the same as it would be to fix up lqt. [19:24:41] alolita: I prefer Thu AM over Wed PM [19:25:02] not a nice place to be in decision-wise [19:25:06] roan: thurs am your time or Pacific time [19:25:14] PST [19:25:16] RoanKattouw: Benny and I like your preference :) [19:25:35] Putting it in for Thursday 11am-noon PST [19:25:39] Roan: that's cool - thurs am it is then - i see rmoen agrees; benny, jorm? [19:25:48] Roan: thanks much! [19:25:53] Only MoodBar changes, right? [19:25:56] yup [19:25:57] (feedback dashboarD) [19:25:57] yes, that's cool [19:26:08] Includes deployment of new extension : http://www.mediawiki.org/wiki/Mark_as_Helpful [19:26:10] is mark as helpful deploying as well? [19:26:13] yeah. [19:26:15] great! [19:26:31] rmoen: do you want to add any other updates [19:26:48] jorm: No, neither of the Marks deploys MW code [19:26:59] Other than what has been mentioned, Benny and I are testing the new extension and making final changes today [19:27:00] heh. [19:27:07] no. the name of the extension is "Mark as helpful" [19:27:10] Roan: heh indeed [19:27:22] rmoen: OK, then please send me an e-mail with anything you need me to do on Thu besides updating MoodBar to trunk state [19:27:24] rmoen: thanks [19:27:39] RoanKattouw: will do :) [19:27:41] bsitu [19:27:42] *JeroenDeDauw_ wants +1 buttons on CR [19:27:52] JeroenDeDauw_: Gerrit has +1 [19:28:05] <^demon|away> +1? [19:28:13] <^demon|away> Like for that silly Google+ site? [19:28:13] final note on FD we're also working on new data/metrics (clicktracking in particular) and we've started displaying real-time response data on the toolserver: http://toolserver.org/~dartar/fd/ [19:28:24] dartar: anything else to add [19:28:25] real-time-ish [19:28:31] ^^ [19:28:37] on feedback dashboard, aft and the like [19:29:15] re: AFT, we've also finalized the design of the hand coding tool with Oliver and Aaron [19:29:33] what is the hand coding tool? [19:29:36] it will be used to invite community members to evaluate and categorize the comments that we get via AFT [19:29:44] i see - so its a script right [19:29:55] alolita: http://en.wikipedia.org/wiki/Wikipedia:Article_Feedback_Tool/Version_5/Feedback_evaluation [19:30:02] thanks [19:30:41] hfung: anything else on aft to add; do we have any deployment pushes planned till end of this year? [19:31:02] it's an awesome tool that can be configured to get {editors|readers|turkers} to qualitative code any kind of feedback that we get (not just AFT) [19:31:20] DarTar: I'm not sure who's writing this tool, but we should talk. It has a lot in common with PageTriage, and we could perhaps share some code or resources. [19:31:42] so let's move on to I18n [19:31:46] C. I18n/L10n Tools: Narayam, Translate, Narayam [Siebrand, Niklas, Santhosh, Amir, Gerard] [19:31:52] alolita: not at this point [19:31:58] hi [19:32:01] howief: thanks! [19:32:11] amir: go for it [19:32:13] omniti will be working on some fixes (e.g., geotag collision, IE7), but they won't be deployed until the new year [19:32:22] most of the last week was about webfonts webfonts webfonts. [19:32:34] howief: ok that works! [19:32:37] raindrift: sure, you can ping IronHolds, EpochFail or myself if you're interested in the code, but it's mostly designed for feedback data [19:32:45] post-deployment bugs and processing user comments. [19:32:51] lots of feedback on webfonts [19:32:53] raindrift: the code was written by EpochFail [19:33:03] reported some upstream bugs in browsers. [19:33:06] post-processing of comments and bug reports [19:33:18] aharoni: great [19:33:38] [Firefox had the least issues, if anyone wondered.] [19:33:53] which version of firefox (all or some) [19:34:49] we got some very vague and hardly reproducible reports about older Firefox versions. [19:35:00] hi [19:35:17] nikerabbit, amir: any other major blockers on webfonts [19:35:37] on IE 6 and 8 we had to disable webfonts, which is unfortunate, but probably necessary. [19:35:50] which is sad, because it's over 17% of our readers. [19:35:54] IE8 on XP [19:36:09] is there a workaround we have [19:36:14] afaik IE8 on Windows 7 is broken, too. [19:36:15] or are working on [19:36:31] aharoni: haven't seen reports about that, have you? [19:36:32] no, no workaround, although i tried to email some Microsoft contacts. [19:36:40] and there has been lots of positive and negative reports about webfonts on mobile devices [19:36:54] i received a report about gibberish in IE8 on Windows 7. [19:37:00] okay [19:37:12] yes, so mobile: [19:37:19] amir: is that in bugzilla [19:37:35] alolita, yes, i'll find the number in a minute. [19:37:49] amir: thanks [19:37:51] some people in India were happy about WebFonts and they want it on the mobile site, too. [19:38:16] aharoni: that's great to hear; now for the hard work to ensure support [19:38:30] nikerabbit: any issues on translate on mediawiki [19:38:37] alolita: https://bugzilla.wikimedia.org/show_bug.cgi?id=32775 [19:38:43] amir: thanks [19:38:52]