=== danilos [n=danilo@adsl-221-97.eunet.yu] has joined #launchpad-meeting === carlos [n=carlos@54.Red-88-18-197.staticIP.rima-tde.net] has joined #launchpad-meeting [05:01] hi [05:01] hi [05:01] hi all [05:01] let's start anyway [05:01] sure [05:02] first of all, what are you guys currently working on? [05:02] sorry if I confused you today Steve, I guess my connection to #launchpad dropped, while I was stil in #canonical [05:02] (and I lost my phone in Sunnyvale, so didn't have your number right away) [05:02] danilos: ok. I was worried you were ill like many people seem to be right now [05:02] no, I am fine, or at least not counting mental illness :) [05:03] atm, I'm finishing bug-68014 [05:03] about the reverting translations [05:03] what's left to do there, carlos? [05:03] and have pending TranslationReview's review answer [05:03] anyway, I am wrapping up firefox stuff... I managed to break PO import (i.e. some tests are failing for me), so I am fixing that now [05:04] SteveA: improve the 'locking' detection code [05:04] actually, make it work as it should [05:04] I also have a couple simple bugfixes on my plate [05:04] and fix all tests [05:04] I would like to leave it in the review queue today [05:05] ok [05:05] we should get it reviewed as a priority [05:05] danilos: tell me about how the FF stuff is going [05:05] sure [05:06] I have import and export working, but still have to switch to store actual alternate_msgid inside potmsgset table (I started with storing an ID into pomsgid table, but Carlos and I discussed it on UDS, and agreed that there is no point in that) [05:07] since the code involves changes to PO import/export as well, I have that slightly broken right now [05:08] and I haven't yet ported all the other importing mechanisms to ITranslationImport (such as tarballs, KDE langpacks,...) [05:08] I also have OOo import but no export yet [05:08] danilos: could you finish FF without changing tarballs and KDE langpacks? [05:09] carlos: yes, that's the plan, actually [05:09] ok, I would prefer to do that in different branches so we get smaller branches and merges more often... [05:09] carlos: sure, makes sense [05:09] ff is already quite big.. [05:09] there seem to be a lot of unfinished branches on the PendingReviews page [05:10] and, having code that is not landed on mainline, well, it gets more difficult to maintain as time goes on [05:10] bug-44214 is already answered and should be ready to merge, unless I missed anything [05:10] I have a couple which are partial bug-fixes for some of my in-progress bugs [05:10] what's a partial bug fix? [05:11] the other branches I have there are not high priority and I had to leave them stopped because are not near finishing. Though, I want to resume them as soon as possible [05:11] which fixes some instances of the problem (eg. the one with legend being shown on pages when no language stats are shown) [05:12] (and there are several templates, and one of them will require some code refactoring to fix it cleanly) [05:12] danilos: I see. thanks. although it seems strange to me that it needs the same kind of fix in many places [05:13] SteveA: well, we have page which list multiple POtemplates, and only a single "legend", and another page which has a single POtemplate and "legend" [05:13] danilos: couldn't we share some code there? [05:13] carlos: sure, but that exactly means some "code refactoring" I mentioned above :) [05:14] I see [05:14] ok [05:14] so, thinking concretely about the data-loss fix [05:14] carlos, you said you expect it to be up for review today? [05:15] btw, we also have more of those +rosetta-index oopses for yesterday [05:15] I hope that, yes, unless the tests gave me more problems than they should... [05:15] how big is the diff? [05:16] it's not working so I don't know how will be the final diff, but it shouldn't be more than 100-200 line changes/additions [05:17] without counting tests [05:17] even less... [05:17] ok, so a smallish review [05:17] I think so, yes [05:18] so, we should get it reviewed by someone right away, when it is ready [05:18] I think test changes will be higher than code changes [05:18] ok [05:18] danilos: about the FF work, how long do you think before you can get something for review? [05:18] SteveA: just a couple of days--tuesday/wednesday most likely [05:19] and what parts of the spec does that cover? [05:19] SteveA: any chance of getting this cherrypicked before 1.0 if review goes favourably and without too many changes? [05:19] SteveA: well, complete spec: we get Firefox XPI export/import [05:20] ok, so the expectation we're talking about is the firefox support spec being up for review by wednesday? [05:20] exactly [05:20] with full tests [05:20] that would be wonderful. how confident do you feel about that? [05:21] pretty confident [05:21] ok, thanks [05:22] if I run into problems, I'll ask carlos for some help [05:22] also, tell me and kikok [05:22] danilos: please, do it [05:22] we want to hear about your problems [05:22] and when things go well too [05:22] and he won't mind at all, since he'd like to get to know the code for kde plural forms bug [05:22] just ping us on irc and tell us things [05:22] about how it is going [05:22] SteveA: ok, I know I've been pretty bad about communicating with you [05:22] and kiko [05:23] looks like we're planning to have FF stuff rolled out around 12 December [05:24] SteveA: should we talk also about Rosetta DB optimizations? [05:24] SteveA: how does that fit into 1.0 and time-based releases after that? [05:25] btw, I will be off the week before that (4th-10th) [05:25] danilos: we still need to work that out [05:25] SteveA: ok, I'll start some discussion on launchpad list [05:25] about what? [05:26] kiko and I have been discussing what to do about 1.0->1.1 [05:26] we need to discuss the whole thing with mark today (in about 10 mins) [05:26] and then write a plan for it [05:26] well, about what is going to be the meaning of 1.1, 2.0 etc. [05:26] I don't think there's much to discuss on the launchpad list yet, until we've got approval for the basic idea [05:27] iow, I am not entirely sure I understand what you mean by that [05:27] are we simply going to replace our "rollouts" with "releases"? [05:27] no [05:27] we'll still do regular rollouts every 1-2 weeks [05:27] or 2-3 weeks [05:27] we'll do planning of features on a 13 week cycle [05:28] ok, we're probably getting into marketing area then, if I am not mistaken? [05:28] I don't want a lot of discussion on the list. I just want to receive comments and feedback at this point [05:29] SteveA: ok, sure, I'll think about it some more, and post you my comments [05:29] once we've got the general direction approved, then I'd like discussion with everyone [05:29] yeah, got it [05:29] let's talk about the db optimizations [05:29] ok, let me check if stub updated the spec with latest "findings" from UDS [05:29] kiko suggested to implement it before improve translation form performance [05:30] I really don't mind to do it before or after that [05:31] I don't think stub updated it; we basically agreed that we want all our 40+M row tables merged into one [05:31] but I guess that will only delay the performance fix [05:31] well, I think the kiko's suggestion is because we probably won't need much translation form optimization work afterwards [05:32] we're currently doing joins across 3 40M row tables, and we'd be doing it over 1 50M row table afterwards instead [05:33] well, I don't think it's a bad thing to change the way suggestions work as we planned to do it [05:33] that will allow us to scale better in the future === kiko [n=kiko@200-171-140-32.dsl.telesp.net.br] has joined #launchpad-meeting [05:34] hey kiko [05:34] ho SteveA [05:34] I'm waiting on hold, btw [05:34] hey kiko [05:34] on the subject of the FF spec [05:35] danilo is pretty confident that it will be up for review, with tests etc. by wednesday [05:35] if that's so, I expect it to be rolled out right before or after the xmas break [05:36] carlos expects the data-loss fixes to be up for review tonight [05:36] SteveA: hum, when's the christmas break? (you mentioned 12 December above, but that doesn't sound "christmassy" to me ;) [05:37] it is a small patch [05:37] danilos: did I? for some reason I wrote 24 dec in my notes [05:37] must have got confused with today's date [05:37] SteveA: yeah, you said 12 December [05:37] looks like we're planning to have FF stuff rolled out around 12 December [05:37] ok, that's more like it [05:38] there remains a question about when to do the DB optimisations discussed at UDS [05:39] I think that is really important [05:40] it will make performance much better [05:40] it would have the most effect across most users [05:40] if we want to use that to fix timeouts as well, it should be of relatively high priotity [05:40] s/priotity/priority/ [05:40] and it will allow improvements later to be made much more easily [05:40] and I'd also need somewhat for proper search support [05:40] kiko: I'm fine, as long as we don't forget the suggestions improvements we had planned before that DB change [05:41] we didn't yet talk about: search, translation review, OO work [05:41] carlos, I think the suggestions improvements may be rendered unnecessary by the DB work. [05:41] ok, we've had john berkus (I think) from postgres to join us on db optimisations session on UDS as well [05:41] SteveA, this new age is very soothing [05:41] kiko: well, I think that we should do it, better code, more clean, and will allow us to scale much more in the future... [05:41] I think I'll dial back in and cowboy the leader code in there [05:42] carlos, what are you referring to there? [05:42] he mentioned a really cool thing about something called "partial indexes" (well, I thought it was cool anyway), where you can have indexes for only some values of certain column in a table [05:42] yeah [05:42] not in pg8.1 I think [05:42] kiko: well, instead of doing 3-4 queries for each entry to get all suggestions, making just one query [05:43] i.e. we'd also need to add "language" column to our potranslations table, so we can have per-language indexes [05:43] with the change danilos just said, we could split our DB per language in different databases [05:44] (and just to explain the context, we were very much concerned about performance of substring searches in 12M row table) [05:44] reducing the amount of rows too [05:44] carlos: I think there is actually no need to split database if we can have partial indexes [05:44] danilos: I said that we could, not that we should do it right now [05:44] but as kiko said, yes, this requires 8.2, and stub didn't seem too fond of the idea [05:44] it's just one idea from Mark [05:45] so I was pointing that we would be able to implement it [05:45] danilos, yeah. we can do that later, anyway. a partial index on approved strings would be cool, I can see. [05:46] well, maybe "not too fond" is a bit too strong; he just mentioned something about it not being too simple to do (=time, care) [05:46] but that it's planned anyway [05:46] carlos, so what about TR? I saw the UI at allhands and had some comments.. do you have time for it in the short term? [05:47] time to finish it? [05:47] or to implement your comments? [05:47] both answers are 'yes' [05:48] both yes [05:48] I got an initial review from Bjorn [05:48] I will address all his comments and once that's approved, I will implement the UI changes you suggested [05:49] so I don't complicate bjorn's life too much [05:49] ok. [05:49] hmm, not sure whether that expression is valid too in English... ;-) [05:50] it is! [05:51] ok ;-) [05:52] next point? [05:52] or do you have a phone call now? [05:52] we're mid-phone call, yes [05:52] according to SteveA's summary of points above, OO work [05:52] ok [05:52] yes, please dive in [05:53] ok, I'll put out current state anyway, so you can comment when you get back [05:53] and tell us all about this OO work [05:54] it's the same as pre-UDS/AllHands: OOo import is working (importing single GSI file into multiple translation domains), export not started yet [05:55] on UDS/AllHands, had a couple discussions with doko (OOo package maintainer) about how to best provide GSI files for him, and what domains to use, so need to incorporate his feedback as well (i.e. some bits different for help translation--actually have to check with him for more details on that one) [05:56] (which reminds me: carlos and I also had a discussion with pitti on documentation language packs, and one of the suggestions was to actually support direct import/export of DocBook XML files in Rosetta, just like we're going to support other formats such as FF/OOo) [06:18] danilos: anyway, that's another spec that we should write and plan to implement, if we have time [06:20] carlos: right, but that's another thing distro team wants of launchpad, so I thought I should also bring it up ;)