[00:21] Urgh [00:21] bzr-tarmacland breaks 'bzr selftest' [00:30] maxb, as in, it has failing tests, or it breaks it entirely? [00:30] popping into supermarket back in a bit [00:52] as in, it has code in its tests that failed to import, so the entire execution dies [01:29] thumper: Are you looking at the buildbot failure too? [01:29] It is legit, for once. [01:29] I wasn't [01:29] * wgrant does. [01:39] gah, my landing failed due to the non [testfix] nature [01:39] * thumper leaves the devel fix to wgrant [01:40] wgrant: is it obvious? [01:42] thumper: Yes. [01:42] thumper: Just running the Bugs tests now. [01:43] (the test suite was clearly not run over the problematic branch :/) [02:05] running rocketfuel-get just now it fails in mailman: [02:05] Compiling /home/bryce/launchpad/lp-branches/devel/lib/mailman/Mailman/i18n.py ... [02:05] Compiling /home/bryce/launchpad/lp-branches/devel/lib/mailman/Mailman/versions.py ... [02:05] make[1]: Leaving directory `/home/bryce/launchpad/lp-sourcedeps/sourcecode/mailman' [02:05] make: *** [compile] Error 2 [02:05] make: Leaving directory `/home/bryce/launchpad/lp-branches/devel' [02:06] yup [02:06] use lucid [02:06] or fiddle with stuff under the hood as per sinzui's bug about this [02:06] $ grep CODENAME /etc/lsb-release [02:06] DISTRIB_CODENAME=lucid [02:06] bug #? [02:08] interesting [02:08] hmm, possibly we've broken mailman on lucid by fixing for natty>< [02:08] sinzui: ^ [02:09] So we're aiming for Lucid, Maverick and Natty? [02:10] we deploy on lucid. [02:11] its mandatory until a new LTS is ready [02:11] everything else I don't particularly care about :) === Ursinha-afk is now known as Ursinha [02:31] ARGH! [02:31] who made the change that makes it impossible to suspend a user without forcibly resetting their password? [02:31] * spm grumps [02:32] spm: not me [02:33] spm: Wha? LP doesn't have passwords. [02:34] fiik. wouldn't let me suspend them unless I set their password as well. [02:34] +reviewaccount fwiw. has password fields now [02:35] click the 'change' button and get a "No! Password not set! bad Losa!" error message. [02:36] file a bug [02:37] nearly completed. I was ranting here so the bug won't be quite so vitrolic. [02:37] :-) [02:37] === Top 10 Time Out Counts by Page ID === [02:37] Hard / Soft Page ID [02:37] 150 / 5403 Archive:+index [02:37] 98 / 385 BugTask:+index [02:37] 97 / 126 Archive:EntryResource:getPublishedBinaries [02:37] 37 / 332 Distribution:+bugs [02:38] 29 / 134 ProjectGroupSet:CollectionResource:#project_groups [02:38] 20 / 33 MailingListApplication:MailingListAPIView [02:38] 13 / 8 ProjectGroup:+milestones [02:38] 10 / 13 DistroSeriesLanguage:+index [02:38] 9 / 307 Distribution:+bugtarget-portlet-bugfilters-stats [02:38] 7 / 14 NullBugTask:+index [02:44] thumper: do we have any juju to remove comments from merge proposals? [02:44] spm: no [02:44] spm: just sql [02:44] spm: just another of the reasons we should have a singular comment interface [02:45] (which we don't have) [02:45] I don't spose you have that handy? [02:45] heh [02:45] spm: sorry, no [02:45] spm: the table is codereviewcomment [02:45] * spm files another bug ;-) [02:49] thumper: it is pretty much a single thing in the data model; what do you see as needed to propogate it higher? [02:49] bugs handle comments differently [02:49] so do answers fwiw [02:49] lifeless: bugs store the initial description as the first comment (which is hidden in the UI) [02:50] lifeless: there are also bug specific fields on the message table [02:50] lifeless: and the comments pretend to be email messages [02:50] And don't even start thinking about attachments... [02:50] which they aren't always [02:50] thumper: there are? I thought those fields were in BugMessage [02:50] I seem to recall some specific bug thing [02:50] perhaps it is gone now [02:51] but the underlying model is quite different [02:51] and should be normalised [02:51] and extracted from the message table [02:51] which is a pile of poo [02:51] wgrant: how are those tests going? [02:52] thumper: what would that leave behind? why isn't it just s/message/comment/ (and thus not very interesting) [02:53] lifeless: the incoming email processor stores all emails directly in the message / messagechunk tables [02:53] as well as the librarian [02:53] it is not a good model for comments [02:53] the message table doesn't store the text [02:53] there are one or more message chunks that do that [02:53] it is just overly messy [02:53] yes, thats done to handle ginormous comments [02:54] well, I don't have the original raisins [02:54] it lets us sequence comments without having to deal with a very fat table [02:54] so its faster [02:57] thumper: Sorry, got distracted with payroll stuff. I'm pretty sure they try to make it as awkward and unintuitive as possible. [02:57] * wgrant creates an MP. [03:02] wgrant: if it is a testfix, rs=me [03:03] thumper: https://code.launchpad.net/~wgrant/launchpad/makeBug-testfix/+merge/45200 [03:05] wgrant: done [03:06] thumper: Thanks. [03:55] poolie: around? [04:04] lifeless, hi [04:04] poolie: call ? [04:16] lifeless, hi, now? [04:19] https://dev.launchpad.net/BugTriage [04:23] https://bugs.launchpad.net/launchpad-project/+bugs [06:03] wgrant: hey [06:03] stub: hi [06:04] yo [06:04] archive:+index is getting worse daily [06:04] any chance you can drill in a bit to get some faster way to answer the questions it needs to ? [06:05] dogfood sort of fails to be terribly useful at analysing this sort of query. [06:05] Because dogfood is awful. [06:05] it succeeds at being terrible [06:07] I'm supposed to be dealing with the test suite leaving garbage db's around, which I guess I should bump in favor of the timeouts. [06:08] ah [06:08] Do we have any real slow queries, including the ids in the IN clauses? [06:08] only the 500ms ones [06:08] (which is pretty slow given the amount of data they are returning) [06:09] stub: well, I can't speak for your priorities right now :) - but to me the test suite stuff is important, but unblocking other developers is more important [for you specifically] [06:09] I don't know if gary would agree [06:10] I can try to reproduce slow queries using random ids in the IN clause, but genuine data will work better. [06:11] I can try to find some genuine data. [06:11] wgrant: are you able to generate a representative ready-to-run query ? [06:11] jinx! [06:11] Not sure how valid it will be, given that DF is from October. [06:11] But we'll see. [06:11] wgrant: perhaps a template query and a couple of queries to run on prod to populate data like archive ids etc [06:12] ok, I need to run for a while to organise dinner [06:15] wgrant: I can run a query on production to generate the list of ids if that helps [06:16] stub: Thanks. I'll work one out soonish. === almaisan-away is now known as al-maisan [06:31] Good morning ! [06:32] Morning al-maisan. [06:55] bryceh: fwiw bug 697441 [06:55] <_mup_> Bug #697441: buildmailman fails under python 2.7 (natty) < https://launchpad.net/bugs/697441 > [07:24] wgrant: When we are doing those 400-1000ms queries with the SourcepackagePublishingHistory.id IN (...) clauses, do we already have the SourcepackagePublishingHistory objects available? I suspect we don't need to actually join with that (big) table in most cases. [07:26] stub: We should have them. But that should be fairly cheap regardless, right? [07:27] I'm curious what an explain analyze says is up [07:27] Its a big table, and unnecessary joins constrain the planner. And I usually consider 100ms 'fairly cheap', so yes :) [07:33] wgrant: Do you know what the BuildFarmJob.status codes we are selecting for? [07:33] stub: Let me see if I can remember which method it is. [07:38] lifeless: http://paste.ubuntu.com/550516/ with random ids and buildfarmjob.status IN (1,2) (both statuses are fairly large categories) [07:41] so its having to generate temp datasets [07:42] both of which are being built and sorted rather than delivered from indices [07:44] it also looks to be highly correlated [07:45] stub: are both halves of the union equally expensive? [07:48] lifeless: roughly [07:50] Unfortunately I can't easily benchmark the variant that eliminates the two unnecessary ORDER BY and SourcePackagePublishingHistory joins, as I end up with about 6 subqueries that make it go slower. [07:50] hmm [07:50] I see 193 and 749 now that I look closely [07:50] so the >< side is the one to focus on [07:53] Where do you see that? I see 1067 and 908 [07:54] Oh... actual time. I'm using estimated time. Actual time will be affected because rows will already be in RAM [07:55] welll. run it twice ;) [07:56] we've seen mismatches between estimate and actual that matter before, haven't we? [08:05] Interesting Gnome lockup... [08:05] Anyway... [08:06] just removing the two unnecessary ORDER BY statements in the subqueries seems to half the runtime by itself. Removing the SourcePackagePublishingHistory table from the joins should be a decent win too. [08:35] good morning [08:58] Morning [11:04] Would any kindly Launchpad developer be able to give me a list of the top, say, 50 Launchpad projects by number of blueprints they have? [11:14] mpt: https://pastebin.canonical.com/41512/, but it's a couple of months out of date. [11:14] wgrant, brilliant, thanks. === Ursinha-afk is now known as Ursinha === matsubara-afk is now known as matsubara [12:02] Morning, all. [12:32] mpt: Are we? [12:33] wgrant, are we what? [12:33] mpt: Starting to contact the projects that most use blueprints. [12:33] wgrant, ah, yes, I just talked with mrevell about it [12:34] Excellent, excellent news. [12:40] gmb, i seem to be using an ec2test image that doesn't have the python-lxml dependency you added around dec. 23 [12:40] do you know how that could be happening? [12:41] Is the branch you're running utilities/ec2 from reasonably up-to-date? [12:41] wgrant: i think so, but maybe not [12:41] i'm updating now [12:41] hopefully that'll fix it [12:41] The test run will merge devel before it starts, but you need a recent version locally to have the image whitelisted. [12:45] thanks, i'm guessing that was the problem [12:45] trying again now [12:46] "using machine image version 504" [12:46] Looks good. === leonardr is now known as leonardr-afk === mrevell is now known as mrevell-lunch === yofel_ is now known as yofel === matsubara is now known as matsubara-lunch === mrevell-lunch is now known as mrevell [14:59] abentley, adeuring, allenap , bac, benji, danilo, sinzui, deryck, EdwinGrubbs, flacoste, gary, gmb, henninge, jelmer, jcsackett, jtv, bigjools, leonard, mars, mrevell: Reviewer meeting ping [14:59] thanks [14:59] yes, thanks [14:59] bac: thanks for the reminder! [15:00] Ta [15:20] henninge: ping. [15:20] Hi jcsackett! [15:21] hi henninge. is recife still undergoing qa? [15:21] jcsackett: yup [15:21] do you know when it might be done? i'd like to be able to be sure it will make release. :-) [15:22] jcsackett: I plan to finish tomorrow around this time. I don't expect any problems atm. [15:23] henninge: that sounds excellent. can you let me know if you run into any hurdles or if there's any way i can help out? [15:23] jcsackett: sure, I will [15:23] thanks for offering! ;) [15:23] :-) [15:23] thanks, henninge. === matsubara-lunch is now known as matsubara [15:52] Edwin-afk, sinzui: how is QA of bug 682727 coming along? [15:52] <_mup_> Bug #682727: obsolete-junk/+series times out when the user is not anonymous

< https://launchpad.net/bugs/682727 > [15:52] jcsackett: can you QA bug 589584? [15:52] <_mup_> Bug #589584: merge proposal status is clickable but doesn't show hand cursor

< https://launchpad.net/bugs/589584 > [15:53] flacoste: it's done, I just marked it now. [15:53] thanks EdwinGrubbs! [15:53] flacoste: qaing it now. === deryck is now known as deryck[lunch] === salgado is now known as salgado-lunch [15:58] flacoste: i'm having to hunt down another problem--the branch merge proposal page is OOPSing on qastaging on opening diffs, which isn't something i've modified. [15:58] at least, i don't believe it is, and don't see the behavior on launchpad.dev with that branch. [16:00] jcsackett: you might ask abentley for help with that problem [16:00] flacoste: thanks. [16:01] abentley: i can't seem to open any branchmergeproposal page on qastaging--its OOPSing on trying to open the diff. thoughts? [16:01] jcsackett, the librarian is FUBARed with old merge proprosals. You could create a new one, but if you do, you'll need to manually run the scripts that update diffs. [16:02] jcsackett, I recommend using staging instead. [16:02] abentley: dig. thanks. [16:02] jcsackett, because the cron scripts are run automatically. [16:02] abentley: that makes sense. [16:02] good to know it's an issue on qastaging, not with the code. [16:04] abentley: what needs to be fixed on qastaging for this to work properly? [16:05] flacoste, the librarian doesn't fall back to the production data correctly. [16:05] abentley: do we have a RT for that? [16:05] are the losa aware of this problem [16:05] ? [16:06] flacoste, I don't know, other people discovered this problem. [16:06] flacoste, I just saw it discussed on IRC. [16:07] abentley: do you remember who was discussing it? [16:07] flacoste, Sorry, no. It was a while ago. [16:07] ok, i'll investigate === leonardr-afk is now known as leonardr [16:11] are LEPs meant to be kept up to date after they're implmented or are they simply historical? [16:18] benji: historical [16:18] cool, thanks === beuno is now known as beuno-lunch === Ursinha is now known as Ursinha-lunch === salgado-lunch is now known as salgado === deryck[lunch] is now known as deryck === al-maisan is now known as almaisan-away === benji is now known as benji-lunch [17:43] gary_poster, ping [17:43] rockstar, pong, though I was seconds away from announcing lunchtime :-) [17:43] gary_poster, just wondering where your Tarmac mp went. [17:44] rockstar: oh, thanks for following up! I meant it to go to the lp fork, so I deleted the oe to trunk. sorry for the noise [17:44] one [17:44] gary_poster, does the bug not affect my upstream? [17:44] no rockstar [17:45] gary_poster, ah, okay. It looked like a pretty scary bug, so I was concerned. [17:45] yeah, it was interesting rockstar :-) [17:45] gary_poster, thanks. That's one less thing off my actionable list. [17:45] cool, np === gary_poster is now known as gary-lunch [18:18] deryck, are you a good person to talk to about lazr-js stuff in Launchpad right now? [18:18] Basically, when I take an axe to lazr-js, whose life am I making more difficult? === Ursinha-lunch is now known as Ursinha [18:25] rockstar: I'm probably the best one to do that with, yes. [18:27] deryck, okay. I don't think start of it will affect you too much, as the combo loader will get pulled out first, and you don't use that anyway. [18:27] deryck, but the build system will have to become part of Launchpad soon. [18:27] ah, ok === benji-lunch is now known as benji [18:39] rockstar: sorry, internets are flaky in AL when it storms. ;) === beuno-lunch is now known as beuno === gary-lunch is now known as gary_poster [19:52] flacoste: what did you think of my triage mail ? [19:53] flacoste: also I've forgotten the thing I was to mail you and jml about for consideration [19:55] lifeless: i liked it very much! there are a few things i'd like to clarify, but overall i found it very clear [19:55] awesome [19:55] lifeless: i don't remember what the other email should have been [19:55] what would you like to clarify ? [19:56] in the triaging guidlines, you didn't specify the bucket to use [19:56] i think you did that on purpose [19:56] maybe not [19:56] yeah, it was [19:56] you only say 'in front' [19:56] later than [19:56] etc [19:57] i understand the intent, but i think to be practical, we need to be more explicit [19:57] the problem with saying 'bucket x' is that we then have a scale problem: a large number of bugs matching will swell without swelling our engineering resources etc [19:57] right [19:57] but we only have buckets [19:57] so 'in front' doesn't really mean anything [19:58] I can expand on that [19:58] (because it does mean something :)) [19:58] i know it does :-) [19:59] but what it means operationally isn't clear [19:59] in that document we're saying that what we want is bugs that are less important than 'the least important in the high bucket' are low [19:59] and that queue jumpers only are critical [20:01] flacoste: so, we could do an experiment without an explicit rule->bucket mapping for 'high', and see if its hard for folk, or if the results after a week or two are inconsistent with what you'd like to have seen [20:01] so a bug escalated by a stakeholder would be marked critical? [20:01] flacoste: I think so, when we accept it. [20:01] ok [20:01] we will need to change our DefinitionOfCritical [20:02] well, rename it to DefitionOfAnIncident [20:02] flacoste: I think we need to make the definitionofcritical more clearly talk about operational incidents vs code changes [20:02] but i think that would be a good change [20:02] agreed [20:02] hah yes +1 [20:03] poolie and I had an interesting discussion about 'how many high bugs should we have' [20:04] we expect about 1000 bugs closed a year by maintenance team work [20:04] tha suggests the critical backlog (https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=timeout,oops) to be cleared in ~ 3 months [20:05] and after that ~ 500 bugs in high every 6 months [20:05] its possible that having 700 bugs in high (as we do) isn't a problem per se: thats a 9 month queue, yes, but in 9 months most bugs will still sort into the same bucket [20:06] flacoste: what do you think? [20:07] lifeless: that's my analysis also [20:07] and we should have a much shorter queue in a couple of months [20:07] flacoste: we'll see some movement, yes. [20:07] flacoste: I'd like to try tightening up the 'front' etc stuff in that section before we try making it more fixed [20:08] flacoste: because by the july epic we'll be needing to promote medium bugs to high - the goal posts should be shifting [20:09] flacoste: at the very least I'd like to do a re-triage of high bugs before writing declarative rules for what should be high [20:09] (so that the rules can reasonably match :)) [20:09] lifeless: doing it like in your proposal would remove the need for a 'escalated' tag -- which i was toying with to mark out the queue jumper in the High bucket [20:10] flacoste: we may want such a tag for convenience in recall ('where are the escalated stakeholder bugs') [20:10] right [20:10] but we wouldn't need to hunt for it [20:10] but it wouldn't be needed for 'what do I need to work on next' [20:10] they would sort at the top because of their critical priority [20:10] right [20:11] and the initial critical bucket if we implement my proposal will be ~ 3 months deep [20:11] which is good [20:11] not brilliant [20:11] but a good starting point to clean up from [20:11] lifeless: OOPS, timeout and regression -> Critical ? [20:11] + escalted [20:11] + escalated [20:11] works for me though [20:12] https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=regression [20:12] 6 bugs [20:13] 172 oops [20:13] and 58 timeout [20:13] yeah [20:19] flacoste: ok, so IIUC you're actually ok as-is now with a little tightening around the meaning of front etc - perhaps a use case. [20:19] flacoste: were there other things in it that you'd like to clarify? [20:19] lifeless: no, that was it, really [20:20] lifeless: i found the whole rationale very clear [20:20] excellent === almaisan-away is now known as al-maisan === henninge_ is now known as henninge [20:28] jcsackett: I subscribed you to a bug on staging where our QA is failing. I am investigating. [20:28] s/on staging// [20:28] henninge: thanks for the heads up. === salgado is now known as salgado-afk [20:47] arse [20:47] * thumper wonders how to fix this [20:48] flacoste: popping into the doctor with Lynne, back soon [20:52] lifeless: ttyl === matsubara is now known as matsubara-afk [20:53] flacoste: I have an issue with recipe builds [20:53] thumper: what's the issue? [20:53] (/me is on a call) [20:53] flacoste: an early design decision was to have the recipe builds live under the recipe for the canonical url [20:53] however the recipe for the build is now optional [20:53] in order to maintain some traceability [20:53] meaning that the recipe can be deleted? [20:53] which means we have some recipe builds without recipes [20:54] which are "dead" [20:54] right [20:54] yes, the recipe can be deleted [20:54] but the builds live on [20:54] create a graveyard parent? [20:54] well... [20:54] in canonical_url, pseudo-code: [20:54] I wanted to have them hang off the ppa [20:54] like ppa binary builds [20:55] however both the binary build and the recipe build have exported themselves [20:55] so in order to keep the wadl stable, we can't really change them [20:55] thumper: the URL isn't in the wadl [20:55] I'd ideally like to move both binary builds and recipe builds to live under the same URL [20:55] isn't it? [20:55] that's interesting [20:55] it's not [20:56] ~user/+build/ [20:56] only the schema is part of the wadl [20:56] hmm... [20:56] so this may well be fine then [20:56] the url is part of the documentation [20:56] ok [20:56] perhaps I may bug wgrant about this when he is up [20:56] just to make sure I don't fubar anything important [20:57] flacoste, wow, really? We have a RESTful API that doesn't specify the URLs of anything? [20:57] abentley: we don't because everything is discoverable [20:57] through introspection [20:57] _link [20:58] you get a resource and then navigate the object graph [20:58] abentley: lucky us I guess :) [20:58] or call methods and get back references [20:58] only the service root is a well-known name === al-maisan is now known as almaisan-away [21:00] thumper, kinda. I'm not sure whether our javascript would handle URL changes gracefully. [21:00] abentley: what do you mean? [21:01] thumper, it doesn't use launchpadlib, so it may have hand-crafted URLs in places. [21:02] I don't think we have many of those... [21:02] I could be wrong [21:04] thumper, I'm changing merge proposals so that only recently-used proposal targets are suggested. Where should I test it? Test the widget? Extract a vocabulary and test that? Test the +register view? The current tests are pagetests. [21:05] I think test the widget, or test the code that the widget uses [21:10] abentley: we usually don't generate url directly in the JS [21:10] well we shouldn't [21:11] the LP.client is the launchpadlib analog [21:11] or they are generated properly server-side [21:19] hello, I need some help installing launchpad in a VM. [21:20] After getting rocketfuel-setup, and running it. I'm prompted for my launchpad username. It doesn't seem to work though. Whenever I type in my lp username and password, I continue to get the password prompt. [21:21] and I'm unable to get past this point as simply hitting enter after being prompted for my username results in the default username being used. [21:21] flacoste: i believe we do generate lots of urls in the js, because the ajax environment doesn't support navigation the way a custom client does [21:52] leonardr: right, but usually either server-side, isn't? [21:52] by or by using the json dump of the context [22:02] poolie, lifeless, we'd like input from one or both of you on https://bugs.launchpad.net/launchpad/+bug/636193 . Might be quick reply, might not. [22:02] <_mup_> Bug #636193: feature flags need to self document

< https://launchpad.net/bugs/636193 > [22:12] thumper: It should be fine. Just change the PPA +build traversal to use PackageBuild instead of BinaryPackageBuild. [22:12] wgrant: actually we are considering /+build/ [22:12] wgrant: for all build farm jobs [22:13] wgrant: which includes the translation jobs [22:13] thumper: Translation jobs don't have an archive. [22:13] wgrant: so removing the inside part of binary package buids [22:13] wgrant: exactly [22:13]