[11:49] * danilos -> lunch [12:29] bac benji danilos gmb call in 2 [12:29] ok [12:29] or 1 [12:32] danilos: What's the best way to test if a POTMsgSet isn't used in any templates (as opposed to being obsolete)? I just want to double-check for sanity. [12:32] gmb, "not in (select all potmsgset)" [12:32] danilos: Hurrah! That's what I've been doing. Good. [12:33] Oh, no. [12:33] Hang on [12:33] danilos: that doesn't make sense. [12:39] bac benji danilos gmb, I meant to congratulate us on CHR this week. Go us! I think we did a great job. Special thanks to gmb who did a bunch of the question cleanup on Monday. [12:39] danilos: Is POTMsgSet.potemplate used for anything? [12:40] bac, don't forget to put the stats on the page at the end of CHR. We can decide if they are actually valuable later: flacoste pointed out that we do have the graphs linked at the top of the CHR page. [12:40] gmb, yes, but not what you are bound to think of first (it's for diverged translations, i.e. saying "this one is different only in this template") [12:41] gary_poster: ok [12:41] Okay. [12:43] danilos: So if I want to know if a POTMsgSet is unused, what do I actually need to look at to determine that? Should I join to POTemplate via TranslationTemplateItem? [12:43] gmb, so, basically, potmsgset is in a template if there is a TranslationTemplateItem that references potmsgset and potemplate [12:43] Right. [12:44] Makes sense. [12:44] gmb, and potmsgset is not in any templates if the count of templates it is in is zero :) [12:44] Also makes sense :) [12:46] gmb, of the top of my head, something like this should give you "unused potmsgsets": select potmsgset from translationtemplateitem where sequence=0 group by potmsgset having count(potemplate)=0 union select id from potmsgset where id not in (select potmsgset from translationtemplateitem); [12:47] danilos: Ah, thanks. I'm trying to work up a Storm expression at the mometn, so I'll use that as a guide and see what happens... [12:47] gmb, I ain't exactly sure how you specify the having clause in Storm, but there must be a way :) [12:48] danilos: Yeah. If all else fails, subqueries :) [12:49] * gmb -> grabbing some food [12:51] gmb, also note that the above query is wrong, it needs to be "sequence != 0" [12:53] danilos: Noted, thanks. [12:53] * gmb -> really grabbing some food this time [13:07] gmb, a few more improvements to the query which is now tested on staging: https://pastebin.canonical.com/50458/ [13:08] danilos: Ah, you crafty devil. I forgot you had staging DB access :) [13:08] danilos: I shall try to turn that into something useable and Storm-like, but if all else fails I'll use SQL directly. Thanks.] [13:09] who? me? what's staging anyway! [13:10] gmb, also, staging tells me there's roughly 2M unused POTMsgSets in the database already, so we'll have to drop those with a script [13:11] danilos: Right. I always figured we'd need to do that before we started the garbo job. [13:31] gmb, actually, perhaps there's something we can do so we slowly remove the previous cruft instead (eg. do a "limit 10000" to remove at most 10000 potmsgsets in one garbo run) [13:32] danilos: That could work too. Can we be sure that we'll ever clear out all the cruft that way? [13:32] gmb, well, as long as we don't introduce 10k unused messages every day, we will [13:32] Fair enough. [13:33] (and that's very unlikely, imho) [13:34] gmb, we should probably make it bigger until we clear up the queue (like 30k so we clear the backlog in ~60-70 days) [13:34] though, that's best discussed with stub [13:34] danilos: That works for me. I'm not sure Stuart will necessarily be happy about it ;) [13:35] gmb, right, for discussing it with Stuart, we should start with 100k and then "accommodate him" at 30k or 20k :)) [13:35] gmb, just kidding though, I believe we should have a safe-guard like this in anyway [13:35] True. [13:36] gmb, also, the bigger problem is going to be the amount of TranslationMessages that need removing (these 2M seem to correspond to 16M TMs, so roughly 1:8 order of magnitude) [13:36] ouch. [13:37] I can imagine Stuart wanting this done with a dblooptuner or something ideally [13:37] danilos: Garbo stuff is all TunableLoop anyway. [13:37] gmb, oh, cool [13:37] So it's not much work to adapt what I've done already. [13:37] gmb, sounds good [13:37] gmb, I'll leave you to it then [13:38] danilos: Cool. Shouldn't be too long now. [14:05] * gmb -> errand; bbaib [14:59] CHR... [16:54] AAAAAAARGH. [16:54] Why is list slicing so hard to get right? [17:10] * gary_poster lunches. [17:11] Don't cut your thumb while you work gmb. We don't like blood in our code. [17:14] :) [17:16] That reminds me of this http://www.sorehands.com/humor/kling.htm [17:18] It doesn't help that Garbo silently swallows exceptions before raising the helpfully named SilentLaunchpadScriptFailure [20:20] benji: you're going to be jealous you missed out on bug 818232 as CHR [20:20] <_mup_> Bug #818232: translation in french a englich picture movie < https://launchpad.net/bugs/818232 > [20:20] heh [20:21] wow, that's one for the ages [20:31] lol [20:32] next we'll have people asking for home repair tips [20:33] gary_poster: for CHR stats, how do you want to characterize RT tasks? there are two open, but they are assigned and have been worked. for CHR i'd call that 0. [20:34] bac, if they are stalled that's easy. if it's "our turn" I'd argue that they ought to be in a separate but recorded value. I don't care a lot though; I agree that "unopened" or whatever it is called is the more important. [20:35] "new" [20:35] yeah, these have back-forth with the OP and matthew. [20:35] i'd say matthew owns it and they are not CHR tasks anymore, so i'll count them as 0 [20:36] gary_poster: and this? https://answers.launchpad.net/launchpad-project/+questions?field.search_text=&field.sort=RELEVANCY&field.sort-empty-marker=1&field.actions.search=Search&field.language=en&field.language-empty-marker=1&field.status=OPEN&field.status-empty-marker=1 [20:36] how did you count these? [20:37] bac, I think I had a parenthetical number [20:37] so I'd represent this as 0 (9), IIRC [20:38] gotcha [20:38] ok, I need to run, not least because my feet are tired :-P [20:39] bye [20:40] so we finish the week with no outstanding CHR tasks. whee. outstanding. [20:42] bac: do you have a second to sanity-check something for me? [20:47] In case you come back: I'm adding a little nicety that will suggest the longest number in a branch name when associating a branch with a bug. The way I have it now, I disregard any sequence of digits shorter than 6 in length because all new bug numbers are at least that long. This way if you have a version number in a string like 3.14 it won't suggest "14" as the bug number. [20:49] I expect this to greatly reduce false positives. The rub is, it won't work for *other* instances of LP. How much do we care? [20:50] Since this won't hurt other people -- just keep one bit of UX polish from helping them out -- I doubt we care much. OK, I've convinced myself, I'm going to have it ignore runs of digits smaller than 6 in length. (But will make it defined in a constant, both for testing, magic-number avoidance, and visibility if someone wants to change it for their LP install.) [20:53] hi benji. [20:53] reading [20:54] benji: now that i've finished i see i was just a foil and you convinced yourself. [20:54] glad to have been of assistance [20:55] bac: well, I let you read it because I would like your validation of my self-convincing [20:55] heh