| === henninge changed the topic of #launchpad-reviews to: On Call: henninge || reviewing: - || queue: [-] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews | ||
| jtv | henninge: got one for you! https://code.launchpad.net/~jtv/launchpad/bug-590688/+merge/26929 | 11:42 |
|---|---|---|
| === henninge changed the topic of #launchpad-reviews to: On Call: henninge || reviewing: jtv || queue: [-] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews | ||
| henninge | jtv: I wonder if the method should not be called "switchDbUser" like the Layer function. | 12:06 |
| jtv | henninge: I wanted this to be "attractive" and have a name that doesn't say "you probably don't need to know about this." At the same time, this doesn't just switch the db user but also commits because otherwise the switch doesn't make much sense. So naming it after one part of the task would be misleading. | 12:32 |
| henninge | I had a feeling you'd say something like that ... ;) | 12:33 |
| jtv | ah :) | 12:34 |
| jtv | Hang on... Network Manager _may_ be trying to tell me the wifi connection is back up (but then again it may just be trying to confuse me)... I'll see if I can get off this gprs. | 12:34 |
| henninge | jtv: I am not sure I go a long with your assesment of "attractive" method names but it's not all that important, I guess. | 12:34 |
| henninge | jtv: so, r=me | 12:35 |
| === henninge changed the topic of #launchpad-reviews to: On Call: henninge || reviewing: - || queue: [-] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews | ||
| jtv | henninge: thanks. Suggestions for a better name always welcome, of course. | 12:59 |
| === salgado-lunch is now known as salgado | ||
| === matsubara is now known as matsubara-lunch | ||
| === abentley changed the topic of #launchpad-reviews to: On Call: henninge || reviewing: - || queue: [-] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews | ||
| === abentley changed the topic of #launchpad-reviews to: On Call: henninge, abentley || reviewing: -, - || queue: [-] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews | ||
| === Ursinha is now known as Ursinha-lunch | ||
| mars | gary_poster, when you have a moment, could you please review https://code.launchpad.net/~mars/launchpad/use-zope.testing-3.9.4-p0/+merge/26961 ? | 16:41 |
| gary_poster | mars, ack, will be available in 5 | 16:42 |
| gary_poster | mars, done, thanks | 16:46 |
| abentley | rockstar, mumble? | 16:48 |
| rockstar | abentley, sure. | 16:49 |
| === matsubara-lunch is now known as matsubara | ||
| adiroiban | jtv, henninge: I have pushed a MP to start the pre-implementation chat for bug 583934 https://code.edge.launchpad.net/~adiroiban/launchpad/bug-583934/+merge/26965 | 17:21 |
| mup | Bug #583934: API for POFile attributes <api> <Launchpad Translations:In Progress by adiroiban> <https://launchpad.net/bugs/583934> | 17:21 |
| adiroiban | should I add you as reviewers? | 17:21 |
| jtv | adiroiban: personally I wouldn't worry about that just now—it's not a merge proposal as such quite yet. :) The main thing is that pre-imp. | 17:23 |
| adiroiban | jtv: yes. I just wanted to make sure that you are aware of that branch and to schedule a pre-imp chat based on that branch | 17:25 |
| jtv | adiroiban: and that you have achieved. There's no stopping you, is there? :-) | 17:25 |
| jtv | You're really getting into the tough ones here... there's also the fact that we're not really keeping up with refreshing the POFile statistics data. | 17:26 |
| adiroiban | jtv: yes this branch is more about deciding an API for IRosettaStats ... I have also briefly discussed with Henning during the UDS | 17:27 |
| adiroiban | jtv: how come that the POFile statistics are not updated? | 17:28 |
| jtv | Cool. It's an area that could do with some fresh thinking. It's something I haven't touched that much myself... sort of been hoping that if I don't touch it, it won't bite. | 17:28 |
| adiroiban | jtv: I mean the per POFile statistics | 17:28 |
| adiroiban | not the aggregated per distroserieslanguage | 17:28 |
| jtv | Short answer: message sharing. | 17:28 |
| adiroiban | I see | 17:29 |
| jtv | Makes it much harder to keep track of exactly which POFiles have been changed. | 17:29 |
| adiroiban | so the POFile statistis will not be updated for the shared POFiles? | 17:29 |
| jtv | Exactly. We do refresh all of them in a cron job, sort of as a stopgap, | 17:30 |
| adiroiban | ok | 17:30 |
| jtv | but with message sharing that's become very inefficient. | 17:30 |
| jtv | It's too costly to find and update all the POFiles that may be affected by a translations update, so we can't do that. | 17:30 |
| adiroiban | but this should be solved in a new bug/branch | 17:30 |
| jtv | Yes. | 17:30 |
| jtv | We've already done a bit of research into that. | 17:30 |
| adiroiban | this branch is mainly about finding the right names for those statistics attributes | 17:30 |
| jtv | Right. But be aware that this is not a particularly good time to expose them; they'll be pretty badly maintained. | 17:31 |
| jtv | What we need is a cron job that figures out which POFiles share with ones that have been updated, and updates the stats for those. | 17:32 |
| henninge | jtv: they are exposed anyway through the webui. | 17:33 |
| jtv | Yes... what I mean is that anyone writing clients based on this would have to be acutely aware that the stats aren't particularly reliable. | 17:34 |
| adiroiban | yes. No new data will be exposed in the current API and in fact the whole Translations Statistics API work is to replace the web crawling of those data | 17:34 |
| henninge | what I meant. | 17:34 |
| adiroiban | jtv: I assume that in the next year only I and dpm will use the API and we will use them for weekly or monthly reporting | 17:35 |
| adiroiban | one day delay will not be much of a problem | 17:36 |
| jtv | Personally I'd prefer clear documentation on the point to an assumption that nobody will use this. :-) | 17:36 |
| adiroiban | in this state, the Translation API is to scarce to be used in a real application | 17:37 |
| adiroiban | that could be affected by those cronjobs | 17:37 |
| bac | henninge, abentley: may i get a review for https://code.edge.launchpad.net/~bac/launchpad/bug-588773/+merge/26968 ? | 17:38 |
| adiroiban | but if you think that those cronjobs are a blocker, we can suspend the for on Translations Statistics API | 17:38 |
| adiroiban | and try to first solve those problems | 17:39 |
| henninge | adiroiban: well, that would be better for sure ... ;-) | 17:39 |
| adiroiban | :) | 17:39 |
| abentley | bac, I can have a look when I'm back from lunch. | 17:39 |
| bac | abentley: that's perfect as it allows me to go eat too! | 17:40 |
| === henninge changed the topic of #launchpad-reviews to: On Call: abentley || reviewing: - || queue: [-] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews | ||
| adiroiban | henninge, jtv : I think that the work for this branch is somehow independent of the one day delay in statistics. With or without real time statistiscs we still have to decide for what statistics attributes to expose via the API | 17:41 |
| jtv | adiroiban: very true | 17:41 |
| henninge | adiroiban: it is one week delay, btw, is it not, jtv? | 17:41 |
| henninge | up to one week | 17:41 |
| jtv | Not quite that simple | 17:41 |
| jtv | In theory, we run one full statistics update job on all POFiles per week, and a smaller job on just the more recent POFiles per day. | 17:42 |
| jtv | Those runs have started to take much, much longer | 17:42 |
| jtv | And they share a lock. | 17:43 |
| jtv | This all needs serious work. | 17:43 |
| adiroiban | But since most of the translation work is done on the lates Ubuntu series, at least Ubuntu Lucid statistics are preety accurate | 17:43 |
| adiroiban | I did not encouter any error in Romanian Lucid translation statistics | 17:43 |
| adiroiban | jtv: is there a bug report for that? | 17:43 |
| * jtv looks | 17:44 | |
| adiroiban | bug 373269 ? | 17:44 |
| mup | Bug #373269: Message sharing and POFile statistics <message-sharing> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/373269> | 17:44 |
| jtv | Yes | 17:44 |
| jtv | Frankly I'm not even sure we still run the daily updates, since I'm not getting output for them, nor how long the weekly runs take. | 17:45 |
| jtv | The daily partial runs were always meant as an interim measure; at that time it covered all the POFiles that did any sharing at all. | 17:46 |
| henninge | jtv: I am pretty sure the daily runs are disabled. | 17:46 |
| * henninge pulls the crontabs | 17:46 | |
| henninge | yup, disabled | 17:47 |
| jtv | The daily runs don't make as much sense now that we, but neither do we have anything to replace them. | 17:47 |
| jtv | s/now that we/now that we have been migrating existing POFiles to message sharing/ | 17:48 |
| adiroiban | jtv, henninge: ok. so back to POFile API branch. are we going to halt the work on Translation Statistics until this bug is fixed? or how do you suggest we should proced with this work? | 17:51 |
| henninge | adiroiban: no, I don't think we should do that. As you pointed out, they don't really depend on each other. | 17:52 |
| jtv | Independently from all this, I think it's still useful to figure out an appropriate structure for the statistics. | 17:53 |
| jtv | The work we're doing towards sharing between ubuntu and projects is going to affect the design. | 17:53 |
| henninge | You mean the design of the API? | 17:54 |
| jtv | Yes. For starters, the meaning of what is now current/imported changes a bit. | 17:55 |
| henninge | true | 17:55 |
| jtv | In fact, it may even become simpler. | 17:56 |
| henninge | yes, should | 17:56 |
| adiroiban | jtv, henninge: in the current branch lib/lp/translations/interfaces/statistics.py | 17:56 |
| adiroiban | there are the names and docstring for the exported attributes | 17:56 |
| jtv | Arguably the only sensible way to look at the distinction is now to keep completely separate views of the statistics per POFile. | 17:56 |
| adiroiban | and they are not using current/imported terminology | 17:57 |
| jtv | current/imported is more the technical underpinnings of what you see there. | 17:57 |
| jtv | For instance, rosettaCount counts translationmessages that are "current" but not "imported." | 17:58 |
| jtv | Message sharing complicated that, but the combination with the Ubunbu/projects sharing makes it even more treacherous. | 17:59 |
| adiroiban | yep, I had to digg a little to understand rosettaCount and updatesCount | 17:59 |
| jtv | And so arguably the only sensible way to look at it is to make it simpler. | 18:00 |
| adiroiban | jtv: ok | 18:00 |
| adiroiban | jtv: this branch should be about finding a name and a docstring for those simple attributes | 18:00 |
| adiroiban | and it should not care about the internal implementation | 18:00 |
| jtv | My expectation right now is that rosettaCount and newCount would just not exist in the future. | 18:01 |
| adiroiban | and the MP details I have added the list of exported attributes | 18:01 |
| adiroiban | jtv: I can understand why rosettaCount should not be exported | 18:01 |
| adiroiban | by why we should not export newCount() ? | 18:02 |
| jtv | I'm not just saying they shouldn't be exported, but that I feel they won't exist. | 18:02 |
| adiroiban | ok | 18:02 |
| adiroiban | but still, API users will want to know the ammount of new translations in Launchpad | 18:03 |
| jtv | newCount counts POTMsgSets that have a "current" TM but no "imported' TM | 18:03 |
| adiroiban | how is this going to be implemented in the future if newCount will no longer exist | 18:03 |
| jtv | I think that would have to be lifted out of POFile, to a slightly higher level of abstraction. | 18:03 |
| jtv | It'd become a kind of difference operation between two POFiles. | 18:04 |
| adiroiban | jtv: ok. then we can no longer export those statistics as POFile attributes | 18:04 |
| adiroiban | but have a method that returns them | 18:04 |
| henninge | jtv: why do you think that? | 18:05 |
| adiroiban | and so POFile will no longer have to implement all those individual statistics attributes | 18:05 |
| jtv | henninge: because of divergence. | 18:05 |
| jtv | henninge: a TM can be upstream-diverged or it can be ubuntu-diverged, but it can't be both because in one case it diverges by being specific to an upstream template, and in the other it diverges by being specific to an ubuntu template. | 18:06 |
| jtv | So there's no single POFile that you can query to compare the ubuntu translation state to the upstream translation state. You need to compare an ubuntu pofile to an upstream pofile. | 18:07 |
| jtv | That's not saying we can't have a fixed coupling between an ubuntu pofile and an upstream pofile, of course. | 18:08 |
| henninge | jtv: I am not sure I follow you | 18:09 |
| henninge | but, it's too late for me to think myself into that ... | 18:09 |
| * henninge know about jtv's time zon | 18:09 | |
| henninge | e | 18:09 |
| henninge | ;-) | 18:09 |
| jtv | heh... midnight already | 18:10 |
| henninge | adiroiban, jtv: I have to go, sorry. | 18:10 |
| === deryck is now known as deryck[lunch] | ||
| jtv | anyway, I just mean that if we want to figure out how many messages in an ubuntu pofile differ from upstream, we can no longer look at just that pofile's messages—because any upstream-diverged messages will be in a different pofile from any ubuntu-diverged ones. | 18:11 |
| jtv | OK, but glad we had some opportunity to start thinking about this. adiroiban, do you need a quick update on what's happening on this front? | 18:11 |
| henninge | seriously, I don't understand the consequence of that. I will have to draw a picture ... ;) | 18:12 |
| jtv | pictures help! | 18:12 |
| henninge | but not today anymore ... | 18:13 |
| jtv | exactly. :) | 18:13 |
| adiroiban | jtv: so upstream-diverged statistics will no longer be cached? | 18:13 |
| jtv | They would be, but they are something that's recognizable in the upstream pofile, not in the ubuntu one. | 18:14 |
| adiroiban | ok. but we will continue to represent the upstream-diverged value in the web browser, together with other attributes specific to downstream file... or no? | 18:15 |
| jtv | For purposes of the statistics, I expect we'll still want to follow the usual divergence/sharing protocol: "if this POTMsgSet has a diverged current TM specific to this POTemplate, that's the current TM. Otherwise, look for a shared current TM." | 18:15 |
| jtv | adiroiban: I think that would make sense simply because it has value in the process we want to support, but I don't know if POFile will remain the right place to keep that information. | 18:16 |
| henninge | bye guys | 18:17 |
| adiroiban | jtv: and where it will be stored? | 18:18 |
| adiroiban | from an API user point of view, I will like to just get a POFile and have all its statistics as attributes | 18:18 |
| adiroiban | or as a POFile method | 18:19 |
| jtv | adiroiban: give it time—I'm off duty and I've been looking at this for less than an hour, with a Simpsons episode on the side. :-) | 18:19 |
| adiroiban | :) | 18:19 |
| adiroiban | ok | 18:19 |
| jtv | What I'm saying is that the distinction we currently have of upstream and downstream within one pofile is going away. | 18:19 |
| adiroiban | then can you please add your comments on the MP so that we can move forward... not now. when you will have time | 18:19 |
| jtv | With pleasure. I'd want to sleep on all of this. What I'm trying to do for now is highlight what changes will affect the statistics we keep. | 18:20 |
| adiroiban | yes. basicaly this is what we need to discuss in the pre-imp phase :) | 18:22 |
| jtv | In the future, when you're looking at one template in one language, there will be one view for each ubuntu release series it's in, as well as one for each project release series. | 18:22 |
| adiroiban | if statistics are going to be changes | 18:22 |
| jtv | (I'm using "view" as "way of looking at things" here, not anything formal) | 18:23 |
| jtv | Each of these views is basically a pofile. | 18:23 |
| jtv | Some of these pofiles will be upstream ones, others will be ubuntu ones. | 18:23 |
| jtv | They will all share most of their translationmessages. | 18:23 |
| adiroiban | we can create the API to handle the new way of viewing things :) | 18:23 |
| jtv | Sure. | 18:23 |
| jtv | The big change is in what happens when upstream messages differ from ubuntu ones. | 18:24 |
| jtv | No longer will the ubuntu one contain a "dual view" of upstream ("published") and downstream messages. | 18:24 |
| jtv | Each just contains its own active translations. Most will be shared; others will be specific to that pofile. | 18:25 |
| jtv | So when you look at an ubuntu pofile and ask "how does this differ from upstream?" you need to compare to a matching upstream pofile. | 18:26 |
| jtv | If we make sure we have such a matching upstream pofile for each ubuntu pofile, that makes things relatively simple, because we'll always know what to compare. | 18:26 |
| === Ursinha-lunch is now known as Ursinha | ||
| adiroiban | but the API end user will only ask for how_does_this_differ_from_upstream(void). | 18:28 |
| adiroiban | or the API user will have to first identify the upstream template and then ask for how_does_this_differ_from_upstream(upstream_template) | 18:29 |
| jtv | Right. So that's an open design question depending on how the ongoing ubuntu/project sharing work comes out. | 18:29 |
| jtv | adiroiban: btw your branch has landed and passed buildbot. | 18:32 |
| adiroiban | ok. then we should first see how ubuntu/project sharing work will be done and then come back to upstream_changed statistics attribute | 18:33 |
| adiroiban | what about the other attribtes listed in the MP ? | 18:33 |
| === deryck[lunch] is now known as deryck | ||
| jtv | adiroiban: last update and last translator have become a bit shaky and the way we keep track of them may have to change, but that's a generic sharing issue. | 18:35 |
| jtv | As a simple example, if you translate an untranslated message in Maverick and the same message was also present in Lucid, that should probably also count as an update to the Lucid translation as well. | 18:37 |
| jtv | Again that probably doesn't speak against aggregating and caching the information in the pofile. | 18:38 |
| adiroiban | jtv: yes, and how does this affect the API ? | 18:38 |
| adiroiban | or the API design | 18:38 |
| jtv | I hope it won't affect the API; all we know for now is that something there needs to change. | 18:39 |
| jtv | Probably just implementation, but I'd be amiss not to mention it. | 18:39 |
| adiroiban | :) | 18:40 |
| adiroiban | ok | 18:40 |
| jtv | Don't see any risks with the rest. | 18:40 |
| jtv | By the way, it may not hold true that (length - translated messages) == untranslated messages. | 18:42 |
| jtv | So depending on your needs, you may want to include a count of untranslated messages. | 18:42 |
| jtv | (think translation credits) | 18:42 |
| adiroiban | but (lenght - untransalated) == translated ? | 18:43 |
| adiroiban | of this is also not true :) | 18:43 |
| jtv | All depends on the definitions I guess :) | 18:43 |
| adiroiban | I was thinking to keep the API simple | 18:43 |
| adiroiban | but if you think it is needed | 18:43 |
| adiroiban | I can add an translation_message_untranslated_count attribute | 18:44 |
| jtv | Not saying it is, just pointing out something to think about in the requirements. :) | 18:44 |
| jtv | Maybe counting credits messages as translated would satisfy everyone. | 18:44 |
| adiroiban | agree :) | 18:44 |
| jtv | adiroiban: the branch I landed for you will be on staging with revision 9434. | 18:51 |
| adiroiban | jtv: it will not be landed on edge? | 18:51 |
| jtv | adiroiban: yes, that too. But staging's nice if you want to play around freely. | 18:51 |
| adiroiban | jtv: I saw that it was commited to edge in r10953 | 18:51 |
| jtv | Right, that's the revision. | 18:52 |
| adiroiban | jtv: ok. so future work on ubuntu-upstream translation sharing is a blocker for this branch ? is they a way to predict those changes and move forward with the API design? | 19:00 |
| jtv | adiroiban: one easy thing to do is start with the uncontroversial stuff. | 19:01 |
| jtv | And last update & last translator, as far as I'm concerned, can be exported with a big caveat in the documentation. | 19:03 |
| adiroiban | jtv: why is it so ? | 19:04 |
| adiroiban | even if the translations are shared | 19:04 |
| adiroiban | ah... | 19:04 |
| adiroiban | I see | 19:04 |
| adiroiban | they will not be updated | 19:04 |
| jtv | Exactly. | 19:04 |
| adiroiban | just like any other shared statistic | 19:04 |
| jtv | But I would expect that whatever we do to them, they would probably stay unchanged API-wise. | 19:04 |
| jtv | (We can't freeze all work out of fear of any API ever changing in any way :-) | 19:05 |
| adiroiban | well, the note on documentation that they are not updated in real time should be made for almost all attributes | 19:05 |
| jtv | True. But personally I like to have a realistic sense of proportion: "may be as much as a week out of date" versus "may be a few seconds behind depending on replication lag" is a pretty big distinction, but weasel-word them enough and they'll look the same. :-) | 19:06 |
| adiroiban | :) | 19:07 |
| adiroiban | are we going to have ubuntu-upstrea message sharing implemented for Maverick ? | 19:08 |
| adiroiban | as far as I know, API freeze is done on each Ubuntu relase | 19:08 |
| adiroiban | so we can change the API during this devel timeframe | 19:09 |
| jtv | Hmm... it may not be a completely black-and-white thing. | 19:09 |
| jtv | It could be that we land a working feature, but find lots more things to change, fix & adjust afterwards. | 19:10 |
| adiroiban | so that work may also affect the API ... thus we can push the API regarding the ubuntu-upstream divergence as it is implemented now | 19:12 |
| adiroiban | and change it later | 19:12 |
| adiroiban | :) | 19:12 |
| jtv | That's an option, though on general principle we'll want to minimize such changes. | 19:14 |
| jtv | But now I must go. Good night! | 19:18 |
| adiroiban | yes, but as of this pre-imp talk I would like to have some conclusions and next step actions or creat a list of blockers for those next steps | 19:18 |
| === bac changed the topic of #launchpad-reviews to: On Call: abentley || reviewing: - || queue: [bac] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews | ||
| bac | abentley: you around for my review? | 19:26 |
| abentley | bac, sorry, been distracted by production problems. | 19:26 |
| bac | np abentley | 19:27 |
| abentley | bac, all I see is a few places where an extra blank line could go. | 19:34 |
| bac | abentley: ok, i'm good at adding blank lines. | 19:35 |
| abentley | bac, e.g. between "EditByOwnersRegistryExpertsOrAdmins(AuthorizationBase):" and "permission = 'launchpad.Edit'" | 19:35 |
| abentley | bac, and between lines 100 and 101. | 19:35 |
| abentley | bac, similar for EditProject and EditPersonBySelfRegistryExpertsOrAdmins | 19:39 |
| bac | abentley: ok. i just looked at security.py and it is a real mixed bag wrt to blank lines between the class/docstring and the first line of code. i can clean it up. | 19:39 |
| bac | s/can/will | 19:39 |
| abentley | bac, cool. | 19:40 |
| === abentley changed the topic of #launchpad-reviews to: On Call: abentley || reviewing: - || queue: [] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews | ||
| === matsubara is now known as matsubara-afk | ||
| === abentley changed the topic of #launchpad-reviews to: On Call: - || reviewing: - || queue: [] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.edge.launchpad.net/launchpad/+activereviews | ||
| === Ursinha is now known as Ursinha-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!