[00:00] no, not :) [00:00] :( [00:00] wallyworld: one common idiom is an 'integration' branch holding things merged from other people that is merged to trunk [00:00] another is a 'bits' branch where you do little trivial things [00:00] see e.g. stubs pending-db-patches branch [00:00] yes, i totally ignored those [00:00] in my thnking [00:00] wallyworld: its ok, really. LP has -massive- use cases [00:00] bad mistake. mad at myself for making it [00:01] and our object model being so heavy warps our thinking. [00:01] I do it all the time, and have to back up and do another run at the problem. [00:01] that's true actually, about the object model [00:01] especially for newer people like me [00:01] yes [00:02] its a map, with lots of here-b-dragons, and not the territory. [00:02] wallyworld: here's another case - one I'm looking at at the moment [00:02] it's also "decay" in the codebase [00:02] wallyworld: https://bugs.qastaging.launchpad.net/ubuntu/+source/afflib/+bug/230350/+index [00:02] <_mup_> Bug #230350: Missing Debian Maintainer field

that has 160 bug tasks. [00:03] *160* [00:03] * wallyworld looks [00:03] wallyworld: this is just an example of where users go waaaaay outside the expected bounds us mere developers created. [00:03] * wallyworld tried to look but got a timeout [00:03] right [00:04] thus I'm looking at it :> [00:04] :-) [00:05] * lifeless goes back to bug-279513 [00:06] Hm [00:06] Jenkins, I'm disappointed. [00:06] lifeless: Thanks. [00:06] I was expecting a "trigger another build when this one is started." [00:07] StevenK: I think the advanced triggers plugin can do that [00:09] lifeless: I can't see that on the plugins page [00:11] StevenK: #jenkins I think [00:11] a quick google doesn't show me anything [00:11] it would be easy to do a plugin for it [00:11] but I'm reasonably sure there is one [00:13] I can't see one either, but I can work around it [00:14] Project db-devel build #407: STILL FAILING in 5 hr 36 min: https://hudson.wedontsleep.org/job/db-devel/407/ [00:14] wgrant: So, what do I do to this to make it only run windmill tests? [00:15] StevenK: How do you call the test suite at the moment? [00:15] make TESTOPTS="--subunit" check | subunit2junitxml -f -o test-results.xml [00:15] Add '--layer=WindmillLayer' to TESTOPTS [00:16] make TESTOPTS="--subunit --layer=WindmillLayer" check | subunit2junitxml -f -o test-results.xml [00:16] Yup. [00:16] Added [00:16] Thanks. [00:17] Scheduled a new build of it [00:17] They only take ~35 minutes on ec2. [00:19] StevenK: Is there a bug for the checkwatches.txt thing? [00:19] Not that I can recall [00:19] OK. [00:19] It's only 500 lines, it should be shot. [00:21] I need to rewrite most of it to get rid of more OOPSes. [00:21] So I might. [00:21] But checkwatches :( [00:21] Haha [00:22] Ah, good. [00:30] oops [00:30] forgot to add a particular tag to that landing [00:32] thumper: Which? [00:32] wgrant: the mantis reland [00:33] I did an ec2 land [00:33] It seems to have been rejected anyway. [00:33] Ahh. [00:33] What was missing? It doesn't want to be --rollback. [00:33] It looks fine to me. [00:33] oh, ok [00:33] I already rolled it back last night. [00:33] So we are clear QA-wise. [00:34] ok [00:34] good [00:34] * thumper needs lunch === Ursinha is now known as Ursinha-afk [01:28] Finished: SUCCESS [01:29] wgrant? [01:29] StevenK: windmill worked. [01:29] \o/ [01:29] Thanks! [01:30] It took an hour, though. :-( [01:30] Yeah. [01:30] I should be able to cut about 30 minutes off Jenkins build times by working on EBS [01:30] But I have no idea where to start [01:31] is bug 181368 fixed? [01:31] Maybe. [01:32] Certainly not released. [01:32] But maybe fixed. [01:35] wgrant: I thought the publisher was in nodwontime [01:35] lifeless: No, because of poppy. [01:35] No separate tree yet. [01:47] https://code.launchpad.net/~thumper/lazr.enum/case-insensitive-getTokenByTerm/+merge/51843 anyone? [01:52] why does jenkins now show recent success for db-devel? [01:54] It doesn't? [01:56] last success 6 days ago [01:56] that isn't recent to me [01:57] Oh. s/now/not/ ? [01:57] oh [01:57] yeah [01:57] * thumper is on school run [01:57] Because checkwatches.txt has been failing pretty much every test run [01:58] But not on ec2 or buildbot :-( [02:15] hmm.... [02:15] why? [02:16] Neither wgrant or I have any clue [02:18] thumper: I adjusted a couple of things relating to that test. [02:18] thumper: So I'm going to look at it this afternoon. [02:18] And either fix or delete it. [02:19] ok [02:19] lifeless: you mentioned before that the lp templates mostly show bug tasks and not bugs..... however i think we want to stick with just displaying bugs for revisions listing on the branch index page [02:20] why? [02:20] a bug can have many bug tasks and we really just want the one bug item which the user can click on don't we? there's already a lot of info displayed [02:20] wallyworld: bugtask:+index already picks a single task [02:20] wallyworld: see the method I pointed you at ;) [02:20] the bug summarises the issue the mp is solving [02:21] if you mean the getLinkedBugTasks(), i think we need an anlogous getLinkedBugs() method [02:21] we don't always want the entire list of bug tasks, sometimes just the bugs [02:22] We have too many h2s. [02:22] But it is tempting to keep them because they just look so nice. [02:23] lifeless: i think the current extended revision listing looks ok as is, but we just want to be able to hide private bugs properly [02:23] wallyworld: you're not making any sense. [02:24] wallyworld: get linked bug tasks already chooses *precisely one task* [02:24] wallyworld: the difference you are arguing for is precisely empty. [02:24] but a bug can have many associated bug tasks, no? [02:24] yes, but thats unrelated to the discussion [02:24] because getLinkedBugtasks never returns more than one task per found bug [02:25] just saw that now [02:25] wallyworld: you *must* have a task to show importance, status, tags, context. Bugs on there own are approximately never interesting. [02:25] why is that? [02:26] why only return just the one task? [02:26] wallyworld: because thats what bugtask:+index spent 500 queries figuring out. [02:26] wallyworld: I was merely fixing the performance not the definition. [02:27] ok. fair enough. where in lp then can the user see all bug tasks associated with a branch? [02:27] and why is the method called getLinkedBugTasks if it only returns one? [02:28] because it returns one task per bug - it returns many tasks [02:28] just not many tasks per linked bug [02:29] of course, reading comprehension problem :-( [02:29] there is nowhere in LP that you can see all the bug tasks associated with a branch. The model links to bug, but linking to bug isn't useful for the rest of the system. [02:29] s/model/schema/ [02:29] ok [02:30] wallyworld: series branches only show bugtask for bugs which have an open bugtask; regular branches show a bugtask for all their bugs. [02:30] wallyworld: whether this is right or wrong is a separate discussion IMO : I want to just highlight a few key things: [02:31] - everything about a bug except visibility, description, comments,attachments - is on bugtask [02:32] - our /convention/ throughout the system is to not show bugs, only bugtasks. [02:32] and also on bug are the associated branches from memory [02:32] wallyworld: bugs, questions, specs and other htings are indeed related by bu. [02:32] *bug* [02:33] - we show bugtasks because we show status and importance. And we badge things with 'has brnach', 'has spec' etc etc. [02:33] ok. there's currently functionality which constructs mp emails using bugs not bugtasks. i guess this needs changing too? [02:33] wallyworld: case by case: we're talking web UI here. [02:34] the web UI is different to email because: [02:34] - its live: folk expect data to be presented rather than clicking through [02:34] - email they expect it to be stale - to be given deltas rather than seeing it as it is right now [02:35] i ask because i think (from memory) the email stuff uses branch.linked_bugs and that needs to be removed [02:36] because that also exposes private bugs to email recipients [02:37] so it possibly needs to replaced with something using getLinkedBugTasks [02:37] The codebrowse OOPSes have stopped! [02:37] Surely not! [02:38] Maybe it's just hung again :P [02:39] wallyworld: right, I'd use getLinkedBugTasks [02:39] wallyworld: you could use task.bug [02:40] wallyworld: or you could show bug status as well in the email [02:40] lifeless: yes, i'm doing just that elsewhere atm [02:40] using task.bug i mean [02:41] have to look at performance though. hopefully any alternatives are no worse that using branch.linked_bugs [02:42] wgrant: saw the email about windmill. me sad. a windmill test of mine actually caught a legitimate bug so we do need those tests [02:43] wallyworld: Which are being run on Jenkins [02:43] wallyworld: Sure, we need to turn them back on at some point. [02:43] But for now they are out of the critical path, but Jenkins will tell us if things go bad. [02:43] StevenK: yes but not as part of ec2 land hence we can now land bad code [02:44] wallyworld: It was turned off for most of last year anyway. [02:44] The number of issues that it catches is miniscule. [02:44] sure, we just got lucky [02:44] We would be better served by finding them later and being able to fix them more quickly. [02:44] Which is what this gives us. [02:44] Because branches will no longer be delayed by 10 hours due to Windmill being shit. [02:45] well if we use more and more XHR then miniscule won't be necessarily true [02:45] This is a short-term thing. [02:45] huh [02:45] qatagger is lying [02:45] Eventually we will convince deryck to fix it. [02:45] wgrant: just wanted to hear that it is short term :-) [02:45] lifeless: Oh? [02:45] look at it now [02:45] then file a bug :) [02:45] You mean how it shows it as deployable? [02:46] It has always done that. [02:46] no [02:46] I mean the 2nd line [02:46] earlier today it was showing 12486 [02:46] which was correct [02:46] * wallyworld needs food [02:46] now its showing 12488 [02:46] rather than 'nothing can be deployed' [02:46] lifeless: That was probably before the rollback was in place. [02:50] wgrant: no [02:50] wgrant: it wasn't [02:50] the /rev/ can be ok without it being show deployable at the top [02:50] Ah. [02:51] wgrant: this is a previously unobserved corner case [02:51] the rule fo rdeployable is 'all the revs before deployable and any rollbacks for broken revs included in the deploy [02:55] wgrant: https://bugs.launchpad.net/qa-tagger/+bug/727552 [02:55] <_mup_> Bug #727552: when first rev is bad, with a later rollback, qatagger incorrectly reports it deployable atthe top < https://launchpad.net/bugs/727552 > [02:55] lifeless: Thanks. [02:55] its probably an off by one [02:57] * thumper hangs head [02:57] WTF... [02:57] Project devel build #492: FAILURE in 6 hr 8 min: https://hudson.wedontsleep.org/job/devel/492/ [02:58] WTF @ Hudson [02:59] But checkwatches.txt passed again... [03:00] what's the sop for deprecating something in the web services interface? [03:00] we don't [03:00] getUtility(ILaunchBag).user.preferredemail.email inside the email handler [03:00] if its in beta, leave it there. [03:00] even if it's a security/privacy flaw? [03:00] if its in 1.0 leave it there. [03:00] if its devel, just delete it from devel. [03:01] wallyworld: What is? [03:01] there isn't a user in the launchbag for process mail [03:01] wallyworld: change its behaviour [03:01] because we export branch.linked_bugs [03:01] wallyworld: lazr.restful checks launchpad.View on each object in a collection before it returns it. [03:01] wallyworld: just change it to only return visible bug. But I fixed this already I thought. [03:01] it is handled by lazr.restful [03:01] we don't need to mess with it [03:01] currently it's still defined as an SQLRelatedJoin [03:02] wallyworld: do you *think* its broken, or have you *shown* it [03:02] ok. didn't realise lazr.restful did some filtering [03:02] wallyworld: it will be doing sucky late evaluation at the moment [03:02] wallyworld: and the collection size will be wrong. [03:02] lifeless, i guess "7% headroom" comes from 13/14 [03:02] wallyworld: so its improvable, but it won't actually be disclosing [03:02] poolie: 1/14, yes. [03:03] poolie: I realised the flaw right after I hit send. [03:03] but i don't really see how that corresponds to requests/day [03:03] oh ok [03:03] nice mail otherwise though [03:04] poolie: we'll free up 1 second for every request that is > 13 seconds today. [03:04] poolie: which is a smaller number. A thousand or so [03:04] * wallyworld still thinks we should be able to mark stuff as deprecated if required whether it be a security hole or implementation issue [03:04] wallyworld: we can in extremis, but it needs to be last-resort [03:05] python, java etc all do it :-) [03:05] wallyworld: this is why I don't want *any* new verbs / attributes or types in the 1.0 web service. [03:05] so you'll save ~701s of cpu time per day? [03:05] oh, a bit more than that if you also kill those in the >13s range [03:05] right [03:05] wallyworld: we made a promise to not break 1.0 for the folk using it in shipped Ubuntu versions. [03:05] over 32 cores? [03:05] poolie: the 701 is the >14 requests. [03:06] right, got that [03:06] so say 1000 requests, and you'll cut off one second each [03:06] poolie: currently over 18 python processes. [03:06] so we could mark something as deprecated and then support it until the lts runs out [03:06] wallyworld: there is no deprecation marker. [03:06] wallyworld: we'd just remove it from devel. [03:06] so it's less than .001% more headroom [03:06] yes, and i'm suggesting we need such a marker :-) [03:07] wallyworld: I think it would be counterproductive. [03:07] still worth doing [03:07] wallyworld: 1.0 users cannot use the replacement. [03:07] wallyworld: devel users don't need the old method anymore. [03:08] but in the general case, marking things as deprecated is a fairly common paradigm [03:08] sure [03:08] this isn't the general case [03:08] its a webservice with fairly specific constraints [03:09] one of which is that things work smoothly and seamlessly with the 1.0 version of the service. [03:09] Separately, I don't want use carrying the debt of things we want to remove *in devel* until we delete every prior edition. [03:09] we have enough debt. [03:10] sure, but we should still be able to work towards a 1.1 version, no? ie we need a story around how we evolve the interface [03:10] wallyworld: we have one [03:10] wallyworld: whats the problem you are trying to solve? [03:11] talking generalities. the problem of being able to marked certain things as "do not use, will disappear in a future version". give people time to migrate away [03:11] wallyworld: but it doesn't for us. [03:12] this is more a pub discussion :-) [03:12] wallyworld: the timescale impedance is immense. [03:12] wallyworld: 5 years vs daily change. [03:12] wallyworld: and new things *are not accessible* until you step over the version, at which point - unless we carry that *5 year* burden for *10 years* - the old stuff is flat gone. [03:13] yes, the timeframes are large [03:14] it would be interesting to know which apis were being actively used. i don't suppose we gather those sorts of metrics [03:14] we have logs that can tell us reasonably well [03:15] moot point for now. i was more just thinking out loud. i have to stop doing that [03:15] wallyworld: its fine - I do that too [03:15] wallyworld: but expect to be engaged on such utterances ;) [03:16] :-) [03:16] wallyworld: happens to me all the time - surely you've seen me go 'I have no real answer to hand' :) [03:18] yes :-) [03:19] \o/ I now can start coding today. [03:19] this is why I'm so unproductive, no cycles to write code [03:20] doesn't help you get dragged into various discussions all the time [03:24] You know your jet lag is bad when you catch yourself thinking that you want database sharting. [03:30] it seems to me that there should never be a user in the ILaunchBag during process-mail [03:32] why not ? [03:32] when the sender of the mail is identified we should setup a participation and security policy for them. [03:33] I filed a bug about this. [03:37] Rargh, and then devel #492 fails with _lock_actions garbage [03:46] lifeless: https://code.launchpad.net/~wgrant/launchpad/unbreak-incoming-mail/+merge/51850 [03:46] Slow scan and diff generation are slow. === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: StevenK | https://code.launchpad.net/launchpad-project/+activereviews [03:55] is lib/lp/soyuz/tests/../stories/soyuz/xx-distributionsourcepackagerelease-pages.txt of any use [03:56] or is it redundant with unit tests? [04:02] lifeless: That doctest makes me sad [04:02] StevenK: It's a doctest. [04:02] Haha [04:15] can I just delete soyuuz ? [04:15] Please. [04:15] But delete checkwatches first. [04:15] lifeless: Patches welcome [04:15] sob [04:16] why is default distroseries different to current [04:16] Default distroseries? [04:16] - http://launchpad.dev/ubuntutest/+source/testing-dspr/1.0 [04:16] + http://launchpad.dev/ubuntutest/hoary-test/+source/testing-dspr/1.0 [04:16] in that test [04:17] after I tell getPubSource where to publish - the ubuntutest currentseries [04:17] That's a DSPR wersus a DSSPR... [04:17] Wow. versus. [04:17] >>> anon_browser.open( [04:17] ... 'http://launchpad.dev/ubuntutest/+source/testing-dspr') [04:18] >>> anon_browser.getLink('1.0').click() [04:18] are the lead in lines [04:18] >>> print anon_browser.url [04:20] getLink('1.0') is a little ambiguous. [04:21] wgrant: I'd really like to just delete the test :) [04:31] wgrant: so [04:31] you think there are multiple 1.0 links ? [04:32] lifeless: Quite possibly. [04:32] Can't check details right now though, sorry. [04:57] wgrant: argh [04:58] Oh? [04:58] wgrant: I *think* I may have found a reason for distro.getCurrentSourceReleases. [04:58] wgrant: perhaps not a good reason [04:58] wgrant: /ubuntu/+source/packagedeletedinseries-1 [04:59] lifeless: Latest upload? [04:59] yeah [05:07] what about dropping 'latest upload' as uninteresting [05:10] Component, Maintainer and Architectures are potentially useful. [05:10] Urgency and Latest upload are not. [05:15] sob [05:15] maintainer etc all come from 'current' [05:15] so, does this need to handle packages never published in 'currentseries' ? [05:15] * lifeless thinks [05:16] It would be nice. But it's not really critical. [05:16] I'm going to shelve the branch [05:16] its taking up too much time [05:16] I say use the current series' publications, otherwise say it's not published. [05:17] makes sense to me too [05:17] but the perf win for this is no where near big enough to justify the time investment [05:19] https://code.launchpad.net/~lifeless/launchpad/bug-279513/+merge/51063 - abandoned [05:37] anyone know - does storm sniff tables in SQL(...) ? [05:39] whats a good test class for Archive:getPublishedSources? [05:48] wgrant: ^ [05:49] wgrant: also, soyuz permissions - are they lists of attributes, or just-add-to-interface-and-its-done ? [05:50] lifeless: You may need to create a new class in test_archive. [05:50] lifeless: Most of Archive is tested in archive.txt. [05:50] lifeless: As for permissions, it depends on the class. [05:50] You'll have to check configure.zcml. [05:59] wgrant: thanks [06:01] lifeless: No, SQL is essentially a string. Storm doesn't know how to parse SQL - just generate it. [06:01] stub: thanks [06:01] I'll use a using clause [06:03] whats the easiest way to find what a Archive:EntryResource:getPublishedSources?ws.op=getPublishedSources looks like given that its timing out [06:04] You want to know the data from a specific URL that is timing out? [06:04] (also, QA party) [06:05] wgrant: yes [06:05] wgrant: we're qa'd ? [06:06] No, it's time for a QA party to QA all the stuff that is now on qas. [06:06] wgrant: ah [06:06] I'll do mine straight up [06:07] !!! frell [06:07] ? [06:07] Still broken? [06:07] TypeError [06:07] just getting a traceback [06:07] ('Could not adapt', , ) [06:07] Hah. [06:07] I suggest rolling both back. [06:08] ... and adding tests. [06:08] doit [06:08] Me, or you? [06:08] you, if you would; its 7pm here and I'm about to get snatched for dinner [06:08] k [06:09] I landed this by accident if you recall :( [06:10] But it passed buildbot [06:10] yes [06:10] so ec2 would not have helper. [06:10] *helped* [06:10] I'm just saying its cursed. [06:10] Heh. [06:14] In PQM. [06:15] thanks [06:23] OK, how do I delete launchpadlib's credentials? [06:23] I am trying to log in as one of my alternate SSO accounts on qas. [06:24] But I can't work out how to remove my system authorization. [06:24] Hm, maybe my system launchpadlib still uses GNOME Keyring. [06:25] Ah, there. [06:26] so, we get 800 hits a day on /branches [06:27] > 800 - 800 soft timeouts [06:27] so probably 0.02% of traffic or so, if we wanted to let it die for a day. [06:27] just a thought [06:28]