[00:00] yes, but we're getting back to the topic i raised on the dev list - i disagree with our current workflow because it encourages only superficial qa just get get stuff deployed rather than testing for defects / verification [00:01] wallyworld: uhm, thats the point though. [00:01] not imho :-) [00:01] wallyworld: accept *some* risk, in return for velocity. [00:01] wallyworld: higher velocity gives faster TTR [00:01] wallyworld: and smaller deltas per deploy [00:01] sure, but i think we go too far and rework is the enemy of velocity [00:01] wallyworld: and that gives a gaster TTD [00:01] wallyworld: we are doing far less rework than in the old system [00:02] Anyone want to review https://code.launchpad.net/~wgrant/launchpad/bug-728836/+merge/52355? [00:03] wgrant: I think it may conflict with my fix [00:03] the distroseries attribute in particular [00:03] now, if there were metrics to show the number of bugs that had to be reopened/reworked, that would be interesting [00:03] lifeless: Which fix? [00:03] wallyworld: I don't see how the ok to deploy process affects rework in this case [00:03] wallyworld: 723560 or whatever it is [00:04] wgrant: bug 727560 [00:04] <_mup_> Bug #727560: Archive:EntryResource:getPublishedSources < https://launchpad.net/bugs/727560 > [00:04] Ah, right. [00:04] wallyworld: the process of closing bugs when the first deploy against them is done is easily tweaked and doesn't affect the deploy discussion at all. [00:05] wallyworld: I appreciate that we need to improve the way these two processes interact, but its also -extremly- important we don't conflate the way we improve one with the way we improve the other. [00:05] I think the qatagger needs a patch to give a list of bugs that can be closed by the rev we can deploy to. [00:05] lifeless: if affects rework because it encourages only superficial qa and not a "proper" check that the issue supposed to be fixed really is fully fixed. and so increases the chance that the defect will have to be revisited to fix it "properly" [00:05] wallyworld: once a commit is in trunk, it *must* be deployable or rolledback in a matter of houres [00:05] Makes it easier to cut-n-paste into LPS [00:06] lifeless: It appears not to conflict. [00:06] StevenK: there is a bug open, and when Ursinha rolls out my tweak to the templates it wil lshow Bug:1234 rather than Bug 1234 in the report [00:06] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts < https://launchpad.net/bugs/1234 > [00:06] wgrant: cool [00:07] Haha, I love that bug [00:07] Since it STILL is [00:08] lifeless: I meant a line at the top that has "If we deploy, the following bugs can be closed: 58585 58568 58922 66856 ..." [00:08] StevenK: That bug's fix is the cause of it being so terrible. [00:08] StevenK: yes there is a bug open for that [00:10] gina needs a good hard rewrite [00:11] wgrant: does get_archive do queries ? [00:11] lifeless: I made Archive.debug_archive a cachedproperty to prevent that. [00:12] where does bpr come from ? [00:13] 278 + candidates = (And( [00:13] 279 + BinaryPackagePublishingHistory.archiveID == [00:13] 280 + get_archive(archive, bpr).id, [00:13] oh, I see [00:13] 8 line generator. [00:13] wgrant: not the clearest [00:13] Bah. [00:14] Don't blame me for generators being backwards :P [00:14] forward ones are known as 'for loops' [00:16] Maybe. [00:16] It wasn't initially quite so big. [00:16] The archive used to be in the main query. [00:19] * StevenK notes SMM is now out of date, given 45 second PQM is real [00:20] And I think we could go one better and hook tarmac into Jenkins with a paramaterized build [00:20] Heh. [00:22] lifeless: Thanks. [00:23] benji: Not around? [00:33] wgrant: what do you need ? [00:33] lifeless: Unfreezing. [00:33] wgrant: we don't need benji, we need a losa [00:36] wgrant: IIRC the docs were updated on friday [00:36] wgrant: so it should be a simple point, ask a losa, and mail benji & the list [00:36] I haven't read the new ones. === almaisan-away is now known as al-maisan [00:36] wgrant: might be an idea ;) [00:37] Better to ignore the docs and see what works ;) === al-maisan is now known as almaisan-away [00:39] wgrant: other folk will look to the docs for reference [00:39] wgrant: so keeping them in sync is important [00:39] (or delete if not needed) [00:40] * thumper is close to pounding the table in frustration... [00:40] lifeless: Where are these docs? [00:40] thumper: If you need to pound a table, please choose BranchRevision. [00:40] haha [00:40] If you can break a few indices off it would be great. [00:41] wgrant: we have a solution, but no time to implement [00:41] It is like 130GB! [00:41] wgrant: jam and abentley have a workable solution that'll fix loggerhead speed too [00:41] wgrant: they just need the OK to spend some time doing it [00:41] Ah. [00:41] wgrant: using bzr-historydb [00:41] Will that work for LP too? [00:41] wgrant: it'll kill the table completely [00:42] wgrant: as far as we are aware [00:42] wth is getQuery for [00:42] I thought that was only planned for loggerhead. [00:42] That's great news. [00:42] wgrant: quite a bit of analysis went into it [00:42] lifeless: on what? [00:42] thumper: grep for '\' [00:43] heh [00:43] kill it [00:43] It's not needed by the Zope vocab stuff? [00:43] ah... maybe [00:43] check the Interface [00:44] I'm grepping. [00:44] Doesn't seem to be. [00:45] Yeah, I had grepped there already [00:45] * thumper stabs some tech-debt in the face [00:46] lifeless: https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadRollout says that we can only unfreeze once the stable rev is determined. [00:46] By the RM. [00:46] This is why I don't like reading documentation. [00:47] Because I means I have to knowingly subvert processes instead of just being ignorant of them. [00:48] wgrant: === this stuff below is old and somewhat invalid with buildbot === [00:48] lifeless: Not there... near the bottom of the first section of "Preparatory Tasks" [00:49] "Once all QA is done (including any RC branches that were landed after the db-stable -> devel merge), the RM will let the LOSAs know the revno of stable that we will use as the release branch. Once this release branch is determined, a LOSA can put devel back into normal mode on pqm and prep the stable branch for rollout" [00:50] anyone know if the teamparticipation table is designed reflect valid team memberships taking account of expiry dates, membership status etc? ie can i just query that one teamparticipation table to see if a person validly belongs to a team? [00:50] wallyworld: Yes, use TeamParticipation. [00:51] wgrant: thanks [00:51] wallyworld: It is unreliable in one case: some code (eg. inTeam) considers the team owner to be an implicit member. [00:51] But we consider that a bug, and anything that uses TP directly (lots of stuff does) does not see that. [00:53] wgrant: ok. so add a teamparticipation clause to a query is considered ok i assume [00:53] adding [00:53] Yup. [00:53] cool [00:53] That's part of the point of it. [00:53] Nice and easy. [00:53] And quick. [00:53] sure is. so that means there must be code to maintain that table based on expring memberships etc [00:54] wgrant: fixed [00:59] thanks doko [01:00] What about doko? [01:00] mbf on dh_python [01:00] Aha. [01:00] so my inbox just exploded [01:10] * wgrant finds food and works out whether to drive +copy-packages down further or attack checkwatches. [01:11] wgrant: 59 / 0 LanguageSet:CollectionResource:#languages [01:11] wgrant: has noone attacking it right now [01:12] lifeless: Maybe, but I want to get +copy-packages down low enough that I can stick a test over it. [01:12] I basically just need to preload source files now. [01:12] Didn't we add a CopyPackagesJob or so? [01:13] There is the package clone job which is used for copy archives. [01:13] But anyone pushing normal package copying out into a job is insane and likes causing QISEs. [01:13] (see delayed copies, for example) [01:14] Yes, you said earlier delayed copies don't need to exist? [01:14] One reason for the existence (reuploading files to the public librarian) is wrong. [01:14] Another reason (slowness) will be wrong once this lands. [01:15] And the other (correctness when copying into the primary archive) is easily fixed by moving the overriding and emailing stuff into the normal copy logic. [01:16] StevenK: before we move things into backend jobs we should make them efficient. [01:16] lifeless: It is a dupe, but I cannot remember the summary of the original :/ [01:16] nor I [01:17] wgrant: Lets kill delayed copies, then? :-) [01:17] StevenK: When I have a moment I am going to investigate how much work that is. [01:18] Custom uploads were another reason for delayed copies, but they were never actually implemented. [01:18] And any future implementation should be done by making custom uploads not INSANE. [01:19] Right, I have my test written, now comes the lovely "test dies with a permission error, edit security.cfg, make schema", rinse and repeat [01:22] StevenK: i did that over the w/e. not much fun :-( [01:26] you don't need to run the whole make schema do you? [01:26] just python database/schema/security.py or something [01:27] I investigated last time I had this issue, and the only thing that helped was the full monty of make schema [01:27] enjoy then [01:27] you need to run it against the template test database [01:27] but yes, you don't need full schema build [01:29] It was only 3 perms, so the pain was minimal [01:34] Oh, sigh, every SPPH for Debian is PENDING. [01:34] *That'll* help. [01:44] StevenK: We're going to need to solve that eventually. [01:44] I have considered getting the dominator to run over it. [01:45] And after it takes 4 days? [01:45] But we also need to handle deletions somehow. [01:45] * thumper grabs a bite to eat, then gets the girls [01:46] wgrant: Just trying to write a better query to see how much of Debian's SPR.changelog are None [01:46] StevenK: You should always use IN (1, 2), whenever you are querying for publications. [01:46] Querying only for 2 is always wrong, unless you are the dominator. [01:49] Apparently, 12k. I think my query is wrong, anyway [01:53] StevenK: Maybe just SELECT COUNT(*) FROM sourcepackagerelease WHERE changelog IS NULL and upload_archive=3; [01:53] Won't only give you current stuff. [01:53] But meh. [01:54] wgrant: Can't we craft the query like the populator does and ignore stuff with expired SPRFs? [01:55] StevenK: You could. But nothing in Debian should be expired. [01:55] Because our GC is sort of awful awful awful awful. [02:00] I guess the timing of a test can't really be taken as anything? [02:01] What do you mean? [02:02] From devel: Total: 16 tests, 0 failures, 0 errors in 1 minutes 4.196 seconds. [02:02] what about it [02:02] My branch: Total: 17 tests, 0 failures, 0 errors in 1 minutes 5.195 seconds. [02:02] sounds like your branch adds a 1 second test [02:03] Clearly, my question is that number "reliable" [02:03] repeat it 5 times [02:03] take the lowest time for devel and the lowest time for your branch === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | PQM: open RM: benji === lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews [02:09] LEAN [02:09] Heh. [02:09] Hard / Soft Page ID [02:09] 130 / 223 BugTask:+index [02:09] 109 / 0 LanguageSet:CollectionResource:#languages [02:10] wgrant: ^ let me encourage you to stay flexible and responsive [02:10] wgrant: we will get back to copy packages [02:10] Indeed. [02:10] * wgrant finds a timeout. [02:11] Hmm. Or I could fix two checkwatches OOPSes and get us below 1000 exceptions by the end of the week. [02:11] Tempting, tempting. [02:11] But #languages it is. [02:12] WTF, why is it querying Karma? [02:12] * wgrant deletes #languages as being stupid. [02:14] Thereby fixing the timeout? [02:14] Yes. [02:15] ... maybe people use it? [02:15] It fixes OOPSes *and* decreases WTF/m. [02:15] wgrant: Sigh, SELECT count(spr.id) from sourcepackagerelease as spr JOIN sourcepackagereleasefile as sprf ON sprf.sourcepackagerelease = spr.id JOIN libraryfilealias AS lfa ON sprf.libraryfile = lfa.id WHERE lfa.content is NULL and spr.upload_archive = 3; => 0 [02:15] Who cares if peopel use it :P [02:18] wgrant: The users, I guess. [02:18] Hmm. [02:18] I think I will unexport Language.translators_count, and maybe turn it into a method. [02:19] Maybe people use that too? :-) [02:19] No widely distributed scripts use it, so I do not care much about the users. [02:19] They can adapt. [02:19] What are you, a kernel developer? [02:20] Probably. [02:20] wgrant: is it in 1.0 ? [02:20] wgrant: was it in 1.0 at release ? [02:21] lifeless: It was added in March 2010. So it was probably just after 1.0 was declared. [02:21] lifeless: Anyway, aren't you supposed to drop the lowest, the highest and take the average of the remaining? [02:22] StevenK: huh? [02:22] lifeless: Rather than run the tests 5 times, and just take the lowest number [02:23] So, I could preload, or I could temporarily break a couple of scripts that might not exist and make requests a second or so faster. [02:23] jtv: Heh, I was just looking at that. [02:24] StevenK: we assume that a noisy environment can't make your test faster [02:24] StevenK: and thus everything that makes it slower is noise [02:25] jtv: We could optimise the query, or we could reexport the attribute as a method, breaking all of the very few scripts that use it. [02:26] wow [02:26] wgrant: I would default to optimising in the first instance [02:26] wgrant: its easier (than the coordination to remove something in 1.0) [02:27] lifeless: We need to coordinate the removal of most of 1.0 soon. [02:27] Total: 16 tests, 0 failures, 0 errors in 56.713 seconds. [02:27] Total: 17 tests, 0 failures, 0 errors in 1 minutes 2.982 seconds. [02:27] wgrant: is that hyperbole or do you know something I don't ? [02:27] lifeless: We have committed to supporting 1.0 for another 4 years. That is completely stupid. [02:28] 6 seconds with the two best times, 2 seconds with the two worst times. [02:28] We need to rescind that commitment. [02:28] wgrant: I agree that is has a high cost; its why I'm encouraging devs to only put stuff in devel, and am sure that for 1.1 (or $label) we will only want to move some stuff into supported. [02:29] so [02:29] I have an idea [02:29] why don't we write a caching layer for milestones [02:30] and use it for the hidden edit forms but not for the visible bugtask rows. [02:32] Hi wgrant—whatever works, I guess. :) I'm not sure that "it's a method now" will console many people though… [02:32] wgrant: plus, there's already a bug for timeouts on… getAllLanguages IIRC. So if you want a method that times out rather than a property that times out, well, you've already got one. [02:32] Though I do think what you say has merit in itself! [02:32] jtv: Hmm? getAllLanguages is exactly the same problem. [02:33] It gets lots of Languages, and serialising the Language calculates the translators_count. [02:33] Yes, I figured, but ironically the bug page didn't load. [02:33] That definitely shouldn't be a property, no… [02:33] It is always going to be expensive. [02:33] It doesn't have to be so expensive. [02:33] so [02:34] But it's still going to be expensive. [02:34] The number of reasonable uses for that property by an API script is 0. [02:34] I was assuming that the API request specifically was deliberately getting contributor counts for all languages. [02:34] I really suggest a) optimise, b) if we want to change start the discussion to change it [02:35] Hmm. [02:35] Maybe I can reexport it on devel, and preload on 1.0. [02:36] I need a reviewer [02:36] https://code.launchpad.net/~lifeless/launchpad/bug-724033/+merge/52358 [02:37] wgrant: yes. Which means starting with the preload, and then (probably) file a bug to do something about it in a while in devel. [02:37] :P [02:37] Right. [02:38] hmm, POFile:+translate is still showing up [02:39] Yes, it's difficult and IIRC there was a rewrite that we never completed. [02:39] lifeless: looking at your branch… [02:41] jtv: wanna review my fix for 407260 when you are free? https://code.launchpad.net/~wallyworld/launchpad/branch-picker-team-branches/+merge/52356 [02:42] wallyworld: I'm just reviewing Robert's branch [02:42] jtv: no hurry at all. i just thought you may be interested :-) [02:42] I am, I am… just not free to look at it just yet. :) [02:43] wgrant: DistroSeries:EntryResource:getBuildRecords - improved by your branch ? [02:43] lifeless: no. [02:45] thumper: do you have any examples of making a ws api call on one of our domain objects within javascript? [02:45] * thumper looks [02:46] jtv: fixing the silly docstring [02:47] wallyworld: there is something in lp.code.tests.test_branch_webservice [02:47] thumper: thanks. [02:49] lifeless: speaking of docstrings, it might be nice to have one on CachedMilestoneFactory._load. I have a feeling there's more going on there than I understand. [02:49] thumper: that's all python. i was after javascript :-) [02:49] jtv: what do you think is going on ? [02:49] thumper: i know how to do it from python :-) [02:49] wallyworld: ah... [02:50] wallyworld: what do you want to do? [02:50] jtv: ah, its buggy. Fixed. [02:50] lifeless: the fact that it's based on self.contexts suggests that it's meant to be called only once, but if it were meant to, I get the impression it would've been a one-liner. [02:50] thumper: i want to invoke the recently exported pending_builds api on a recipe object from within javascript [02:51] jtv: pushing the just once guard now. [02:51] The what [02:51] ? [02:51] Ahhhh, _that_ is what the comment meant… [02:51] jtv: uhm its not a one liner because our vocabularies are based on /a context/ not on /contexts/ [02:51] …it meant you only want to call this once? [02:51] It was very, very unclear and helped confuse me. [02:51] jtv: its called many times [02:52] thumper: so i'm on the recipe index page and there'll be a recipe web_link i can use [02:52] jtv: I want the heavy lifting to take place just once, and all at once [02:52] jtv: we currently have some bugs where we construct *300* milestone vocabularies. [02:53] wallyworld: you want to do something like... : [02:53] lp = Y.lp.client.Launchpad(); [02:53] jtv: http://bazaar.launchpad.net/~lifeless/launchpad/bug-724033/revision/12538 [02:53] lp.get(some_path, config)l; [02:53] and that'll be the recipe [02:53] then call the method on that object [02:54] var client = new Y.lp.client.Launchpad(); [02:54] thumper: oh ok. looks reasonable. i'll give it a go thanks. [02:56] wallyworld: grep for "client.get" and you'll find some stuff [02:56] thumper: yeah, just grepping for ".get(" right now in fact :-) [02:56] looks like I get POFile:+translate again [03:01] thumper: i've got enough to go on now but there really don't seem to be very many places at all we use the ws api from our js. unless i only had a boy look :-) [03:01] wallyworld: correct, we don't [03:02] thumper: is that something considered bad or alternatively we just haven't gotten around to it yet? i would have thought it would be the "right thing to do" from a soa perspective [03:05] wallyworld: we don't make many api calls over javascript to code objects [03:07] thumper: in that case would you prefer that i got the pending builds for a recipe another way? the ws api seems correct though. otherwise i'll need to hack zcml and add zope stuff [03:07] wallyworld: what are you doing? [03:08] thumper: may be easier via mumble? [03:08] wallyworld: yep, [03:08] me hooks up [03:12] client.asserts.assertProperty( [03:12] jquery=u'("div#edit-lifecycle_status span.value")', [03:12] validator=u'className|branchstatusEXPERIMENTAL') [03:18] ahh I'm back. lifeless, the last I got from you was "I want the heavy lifting to take place just once, and all at once." It makes sense to me now that you've fixed it: the code I read initially re-created all the MilestoneVocabs on every invocation. [03:18] (Unless I'm going completely dyslexic, which I also wouldn't discount as a possibility :) [03:19] wallyworld: posted a comment on your branch… hard-hitting questions about your approach. :) [03:20] jtv: thanks. otp. will look soon [03:22] lifeless: to explain what I meant with _load being essentially a one-liner: I was thinking if the work is done just once, then ISTM it would amount to self.vocabularies = dict(target, MilestoneVocabularyTarget(target) for target in map(MilestoneVocabulary.getMilestoneTarget, set(self.contexts))) [03:23] Is that correct or am I still misunderstanding something? [03:28] jtv: you're missing that it instantiates the vocaularies [03:28] jtv: not the targes [03:28] targets [03:28] milestone_vocabulary = MilestoneVocabulary(target) [03:28] I thought MilestoneVocabularyTarget(target) instantiated a vocabulary? [03:29] * thumper afk for a while, back later tonight [03:29] jtv: a product and a product series of that product share a set of milestones [03:29] jtv: there is no MilestoneVocabularyTarget [03:29] Sorry, I mis-typed that. [03:29] Scratch the Target. [03:29] jtv: so its a two pass filter: one to map context->targets which is the actual things that we need milestones on [03:29] jtv: and a second to construct the vocabularies for each target [03:30] jtv: a later branch will make the second pass a single call to do optimised sql and generate all the vocabularies out of a minimal set of lookups [03:32] lifeless: but without the typo, and modulo icky external references to self.vocabularies, you're saying _load does not amount to "self.vocabularies = dict(target, MilestoneVocabulary(target) for target in map(MilestoneVocabulary.getMilestoneTarget, set(self.contexts)))"? [03:32] jtv: it won't once the next stage is done [03:32] The set() needs to be outside the map() perhaps? [03:32] jtv: because it won't loop at that point [03:32] Ah, that'll be moved inside some batched method? [03:32] yes [03:33] this is prep work to do an eager load optimisation on bugs that have 150 different products / distro combinations [03:33] it will reduce the query counts we have today substantially I hope, and make it easier to do the next stage [03:34] Then maybe you'd also like to move the self.cached_milestone_source.contexts.add() outside the loop that calls _getTableRowView? The loop iterates over a list anyway. [03:34] Whaa I need to be afk for a moment [03:34] jtv: I wanted to keep it adjacent to the code that hands out the milestone_source [03:34] jtv: that way they can't get out of sync [03:41] back [03:41] jtv: so its layering: someone calling _addTableRow or whatever its called *has* to make sure the context is added to the contexts set or the assertion will trip [03:41] jtv: the easiest way to ensure that is to have addTableRow do it [03:42] lifeless: sure, makes sense [03:42] _getTableRow [03:42] View [03:42] right [03:42] I'm in POFile:+translate now, so going from memory [03:42] (Also, I just noticed it's called in another place as well) [03:42] (Still in the same loop, but nevertheless) [03:43] lifeless: if you have a bug open for the future task of batching this, it'd be nice to make that TODO comment a proper XXX so that all you have to do later is grep for the bug number. Or someone else doing the same job, if it comes to that. [03:43] jtv: its the same bug [03:43] Oh so you're doing that right after this branch? [03:43] probably [03:44] depends on the impact, but I suspect we'll still have timeouts on this once this lands [03:44] BugTask:+index is our #1 timeout [03:49] lifeless: I'd prefer a note to check up on that (and file a bug if appropriate—whether it's timing out or "still a bit slow") over a TODO comment in the source TBH. [03:50] (Since you're going to Q/A this anyway, I'm assuming that your eyes will pass over the relevant data anyway) [03:51] jtv: I think that thats waste TBH: the data will tell us [03:51] I can delete teh comment if you like, but thats also waste - we're probably going to be back here in two days doing more. [03:52] the comment will tell someone else guided here by profiling an option I've considered; a bug would not be usefully triaged outside of the data that we have driving maintenance [03:54] I don't think the comment will be very helpful to someone else reading it. It's little more than a reference to something you have in your head that they'll have to reconstruct by reading the same data, or dig up who wrote it so they can ask. [03:54] If you can make it clearer, then great. [03:54] I take that back; it's clearer now. [03:57] Only other thing is test—it'd be good to know that calls for the same target will return the same vocab. [03:57] I'm really not inclined to - because: [03:58] - I've refactored, vs introducing a new layer: whatever tests there are for this either already ensure that, or were judged unnecessary in the past [03:58] - the key thing isn't whether the same instance is returned, its whether the query count is flat [03:58] - and we can't test the key thing yet because the page is so darn horrible. [04:00] lifeless: so there is a test to ensure that the query count is flat? [04:00] jtv: no, because its not [04:00] jtv: 675 OOPS-1891H475 NullBugTask:+index for instance [04:03] wgrant: want to mentor https://code.launchpad.net/~stevenk/launchpad/populate-spr-changelogs/+merge/52363? [04:03] sorry, be mentored on [04:03] lifeless: I probably shouldn't, since it's an adaptation of my code. But I could. [04:04] wgrant: I'll still give it a full review [04:04] k [04:04] jtv: can I ask a question about pofile:+translate [04:04] go ahead [04:04] in lib/lp/translations/browser/translationmessage.py [04:04] oh God [04:04] line 1287 says if self.form_is_writeable: [04:04] explaining we don't nee dsuggestions if the user cannot do translations [04:04] but [04:05] after the else clause of that if block [04:05] lifeless, wgrant: I'm still attempting to get LP to generate a diff [04:05] jtv: there is another if block starting with if self.sec_lang is None: [04:05] StevenK: Push again. If that doesn't work, push -2 then push again. [04:05] I think I know what's going on, but can't check because ENOLOSA. [04:05] jtv: and it *also* asks for suggestions, but is not guarded by the form_is_writable check [04:05] jtv: I am thinking that that is a bug, but is it ? [04:06] lifeless: arguably… the secondary language serves two very different use cases. [04:06] Unable to obtain lock held by stevenk@bazaar.launchpad.net [04:06] at crowberry [process #14934], acquired 52 minutes, 15 seconds ago. [04:06] <_mup_> Bug #14934: [warty] mozilla-browser: JS can access any mozilla memory < https://launchpad.net/bugs/14934 > [04:06] Whee! [04:06] jtv: e.g. alt_submissions should be [] if form_is_writable is False [04:06] One is "this language is so similar, I'd like suggestions from it so I can just click them into the translation I'm working on." [04:07] The other is "me speak english no good, me like read translations other language as well" [04:08] jtv: ok, so its not a bug [04:08] No [04:08] so, I'll make it more complex there to keep the behaviour [04:09] Sorry to hear it, but I think it's for the best. [04:09] jtv: its about 80% more efficient to query for the alt language with the primary language than to query seperately [04:09] * jtv whistles [04:09] 350ms query * two, or one 355ms query [04:10] There's something that could be done about that, but not now: [04:11]