[00:00] <lifeless> spm: https://bugs.launchpad.net/launchpad-foundations/+bug/669296 - added what we need there
[00:00] <_mup_> Bug #669296: lpnet11 "critical timeout" to nagios, non responsive <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/669296>
[00:01] <lifeless> mwhudson: 18th, no.
[00:01] <lifeless> ok, popping this off stack
[00:01] <lifeless> mbarnett: did you get that db user setup ?
[00:01] <spm> mwhudson: hrm. no. the lucid u/g on this server was back in mid august
[00:02] <spm> actually - doesn't appear to have had any interesting activity of note in quite some time - heh, the dbg was installed the day after that core file. probably directly as to why I asked for it.
[00:21] <lifeless> is this a typical windmill failure:
[00:21] <lifeless> WindmillTestClientException: {u'suite_name': u'Branch Subscription Ajax Load Test', u'result': False, u'starttime': u'2010-10-3T5:8:35.930Z', u'params': {u'xpath': u'//a[@class="sprite add subscribe-self js-action"]', u'validator': u'Subscribe yourself'}, u'debug': u'Looking up xpath //a[@class="sprite add subscribe-self js-action"], failed.', u'output': None, u'endtime': u'2010-10-3T5:8:35.932Z', u'method': u'asserts.assertText
[00:23] <wgrant> lifeless: You got truncated.
[00:23] <lifeless> WindmillTestClientException: {u'suite_name': u'Branch Subscription Ajax Load Test', u'result': False, u'starttime': u'2010-10-3T5:8:35.930Z', u'params': {u'xpath': u'//a[@class="sprite add subscribe-self js-action"]',
[00:23] <lifeless>  u'validator': u'Subscribe yourself'}, u'debug': u'Looking up xpath //a[@class="sprite add subscribe-self js-action"], failed.', u'output': None, u'endtime': u'2010-10-3T5:8:35.932Z', u'method': u'asserts.assertText'}
[00:23] <wgrant> Yeah, that's pretty normal.
[00:23] <spiv> Heh, truncated by two bytes.
[00:23] <wgrant> As in it looks almost like a legit failure.
[00:23] <wgrant> Not like we've been seeing lately!
[00:24] <lifeless> my mentoring branch failed in ec2
[00:24] <lifeless> all the failures are windmill
[00:24] <wgrant> Do they pass locally?
[00:24] <wgrant> I haven't seen a spurious failure like that for months.
[00:24] <lifeless> ok
[00:25] <StevenK> https://hudson.wedontsleep.org/job/devel/lastFailedBuild/#showFailuresLink :-(
[00:25] <lifeless> I'll try later, bootstraping groups first, fighting jetlag all the way.
[00:26] <wgrant> StevenK: Huh.
[00:32] <thumper> lifeless: why aren't we rolling code out to cesium?
[00:36] <lifeless> thumper: https://rt.admin.canonical.com//Ticket/Display.html?id=42207
[00:38] <thumper> lifeless: ta
[01:08]  * thumper sighs
[01:08] <lifeless> thumper: 'sup ?
... gives no bullets
[01:09] <persia> dump CSS and check again?  Then check render context?
[01:10] <thumper> li { list-style:none outside none; } from the stylesheet
[01:12] <persia> Doesn't list-style:none suppress the bullets?
[01:12] <thumper> yep
[01:12] <thumper> found it
[01:13] <thumper> need <ul class="bulleted">
[01:22]  * thumper relocates
[01:32] <spiv> thumper: so when is bzr on codehosting going to be upgraded?  https://bugs.edge.launchpad.net/bzr/+bug/636930
[01:32] <_mup_> Bug #636930: Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' <bazaar> <sru> <upgrade> <verification-done> <Bazaar:Fix Released by spiv> <Bazaar 2.2:Fix Released> <Launchpad Bazaar Integration:Triaged> <bzr (Ubuntu):Fix Released> <bzr (Ubuntu Maverick):Fix Released> <https://launchpad.net/bugs/636930>
[01:32] <lifeless> spiv: you could propose the patch
[01:32] <lifeless> spiv: there aren't any api breaks in the point release are there?
[01:35] <StevenK> thumper: Do you have a conflict of interest to mentor my review of wallyworld's branch, or shall I find another mentor just for that review?
[01:35] <wallyworld> StevenK: perhaps thumper can explain why the diff messed up
[01:36] <StevenK> I added a comment with a theory, but it's only that
[01:44] <wgrant> StevenK, wallyworld: What's the problem with the diff? merge-queue-index was merged, but merge-queues-model is listed as the prereq.
[01:46] <StevenK> Ah ha, perhaps there are two prereqs ...
[01:46] <wgrant> merge-queues-model is (except for one rev) a prefix of merge-queue-index.
[01:47] <spiv> lifeless: no API breaks, no
[01:47] <spiv> lifeless: huh, but looking at NEWS I think I see a fix to another codehosting bug :)
[01:48] <wallyworld> wgrant: the diff in the mp showed rockstar's changes as well as mine, even though i had listed his branch as a prereq
[01:48] <wgrant> wallyworld: But you merged merge-queue-index, which contains more changes than just the merge-queues-model that you set as the prereq.
[01:49] <wallyworld> oh crap. really?
[01:49] <StevenK> Been there, done that.
[01:49] <wallyworld> ffs
[01:49] <wgrant> http://bazaar.launchpad.net/~wallyworld/launchpad/person-mergequeue-listview/revision/9917
[01:49] <lifeless> spiv: so, would love it if you could just commit the tar to the dist cache , update versions.cfg and propose a merge ;)
[01:50] <wallyworld> hmmm. thinking out loud - i did have all the necessary changes locally to build on for my stuff, so i must have merged the right thing at some point
[01:50] <spiv> lifeless: that "just" there presupposes I have familiarity with "the dist cache" and "versions.cfg", not to mention an up-to-date launchpad dev environment.
[01:51] <spiv> (FWIW the other bug is https://bugs.launchpad.net/launchpad-code/+bug/668176)
[01:51] <lifeless> spiv: I have an up to date bzr dev environment :)
[01:52] <StevenK> I think your guilt trip needs work
[01:53] <wallyworld> wgrant: StevenK: yes, it appears my stupid fingers typed the wrong pre req branch when creating the mp :-(
[01:53] <spiv> lifeless: well, if you "just" make the lp dev environment as easy to have as bzr's... ;)
[01:54] <StevenK> wallyworld: Pity the only way to curently fix that is to recreate the MP
[01:54] <lifeless> spiv: for this patch, it is ~ - branch twice,
[01:54] <StevenK> spiv: rocketfuel-setup is easy ?
[01:54] <wallyworld> StevenK: i can easily do that. if fact, i think i should so that the diff is fixed up
[01:54] <wgrant> lifeless: branch $VERY_LARGE_THING.
[01:54] <lifeless> spiv: I do realise that there is overhead
[01:55] <lifeless> spiv: OTOH I think its sensible for bzr devs to have a (even dated) lp dev environment around, because so much of networking will interact with lp
[01:55] <spiv> And I do have a dated lp dev environment around.
[01:55] <StevenK> rf-get ; sleep 3h ?
[01:56] <spiv> But I don't have the familiarity with the current dev processes and policies, for instance... anyway, I'm fairly sure the barriers here are already pretty well understood.
[01:57] <lifeless> spiv: the review policy is unaltered [for you]; I'd be delighted to guide you through any hoops.
[01:58] <lifeless> still, not to worry
[01:58]  * lifeless goes back to perf work
[01:59] <spiv> Well, let's put it this way: the way to get someone hooked on developing for your project is not to say "here do this menial task" :P
[02:00] <lifeless> spiv: I was hoping it was 'here, you can get that thing you want done right now'
[02:00] <lifeless> wgrant: yo
[02:01] <lifeless> wgrant: from what I can see, there is archive-index.pt, archive-macros.pt and a vocabulary all using ArchiveSourcePublications
[02:01] <lifeless> wgrant: archive-index.pt needs newer_source_distributions preloaded
[02:02] <lifeless> the other two don't.
[02:02] <lifeless> wgrant: does that seem plausible ?
[02:06] <wgrant> lifeless: What about archive-packages?
[02:11] <lifeless> wallyworld: do you want a voice call perhaps, as a pseudo pub?
[02:11] <lifeless> wgrant: looking in a bit
[02:11] <wallyworld> lifeless: if versions.cfg already lists bzr 2.2.0 (since mid Aug), what's to change to make codehosting use the correct bzr version?
[02:12] <wallyworld> lifeless: we can have a voice call if you want
[02:13] <lifeless> wgrant: archive-packages uses source-package-list macro
[02:13] <lifeless> wallyworld: do you have skype?
[02:13] <lifeless> wallyworld: 2.2.1 I think
[02:13] <wgrant> lifeless: It doesn't need the prepopulation?
[02:14] <lifeless> wgrant: it doesn't seem to reference newer_source_distributions
[02:14] <lifeless> wgrant: so the tension is - more data, slower page.
[02:14] <wgrant> lifeless: The macro probably does, though?
[02:14] <wallyworld> yes. ian.m.booth at gmail.com is my skype id
[02:14] <lifeless> wgrant: no, the macro doesn't
[02:14] <lifeless> sad moment, removing ian c from my skype list ;(
[02:14] <lifeless> s/;/:/
[02:15] <wgrant> lifeless: greeping for newer_source_distributions shows nothing anywhere.
[02:15] <wgrant> lifeless: What's the actual name?
[02:20] <persia> wgrant, Going through my post-UDS notes, I'm supposed to ask you for details of the put-copyright-in-librarian script so StevenK can run it, and we're one step closer to native-source-sync.
[02:22] <wgrant> persia, StevenK: http://pastebin.ubuntu.com/524798/ is the script. But it probably needs a DBLoopTuner thrown in.
[02:22] <wgrant> And it might need some bitrot repair.
[02:23] <StevenK> wgrant: Are you able to sort both of those?
[02:23] <lifeless> newer_distroseries_version
[02:24] <wgrant> lifeless: archive-packages uses source-package-list uses sourcepackagepublishinghistory-listing-archive-detailed uses newer_distroseries_version
[02:25] <wgrant> StevenK: I probably shouldn't, but I will anyway.
[02:25]  * wgrant fixes.
[02:25] <LPCIBot> Project devel build (178): STILL FAILING in 3 hr 31 min: https://hudson.wedontsleep.org/job/devel/178/
[02:25] <LPCIBot> Launchpad Patch Queue Manager: [r=allenap][ui=none][no-qa] Remove another with_statement.
[02:32]  * wgrant stabs the sampledata in the face.
[03:02] <lifeless> wallyworld: http://sweng.the-davies.net/Home/rustys-api-design-manifesto
[03:06] <wgrant> stub: Hi.
[03:19] <lifeless> wgrant: so
[03:20] <lifeless> wgrant: do we think then that enough things use newer_distroseries_version that we should preload it unconditionally? it would make this patch rather simpler.
[03:20] <wgrant> lifeless: What would preload it?
[03:21] <wgrant> Only those two views should need it.
[03:22] <wgrant> Mmm, I guess +copy-packages and +delete-packages have it too, but that's not really useful.
[03:22] <wgrant> But where you would preload it unconditionally?
[03:24] <lifeless> adapters
[03:24] <lifeless> ArchiveSourcePublications:__iter__
[03:25] <lifeless> this performance problem is a regression - someone added an attribute
[03:25] <lifeless> the ArchiveSourcePublication adapter uses delegates()
[03:25] <lifeless> so it passes through and we get - voila - death by queries.
[03:28] <wgrant> Ah.
[03:30] <wgrant> lifeless: ASP is only used by batched_sources, which is only used in those four views. So go ahead and make it unconditional.
[03:31] <wgrant> StevenK: http://pastebin.ubuntu.com/524818/ seems to work.
[03:31] <wgrant> StevenK: And should be relatively DB-friendly.
[03:32] <persia> wgrant, Thanks a lot for both remembering what I meant regardless of what I said, and fixing that with so little notice.
[03:33] <lifeless> brb
[03:33] <stub> yo
[03:34] <wgrant> stub: With the script I just linked, how would you prefer I handled transactions? One per chunk, or one per SPR?
[03:34] <wgrant> Different TunableLoops seem to do it differently.
[03:35] <stub> wgrant: TunableLoops should commit once per chunk
[03:35] <wgrant> stub: That's what I thought. Thanks.
[03:36] <stub> At least DBTunableLoops should. Let me know which ones if you find one that does differently.
[03:36] <wgrant> I think it was one of the old Translations migration scripts.
[03:36] <stub> Some of them existed before DBTunableLoop
[03:36] <wgrant> Ah.
[03:46] <StevenK> wgrant: I was planning on running it on dogfood, since persia said it only needed one run
[03:47] <persia> The results of the run need to be saved appropriately, mind you.
[03:47] <StevenK> Clearly
[03:48] <wgrant> StevenK: It needs to be run on prod at some point... and running it on dogfood could well DoS it.
[03:48] <wgrant> But perhaps you could run it for a chunk or two.
[03:49] <persia> Since all recent uploads already have the changelogs in the right place, would it be possible to run against somewhere else and then stuff the results into prod, or is that just ugly, bad, and dangerous?
[03:49] <wgrant> Mostly just pointless and possibly more than poor mawson would like to handle.
[03:49] <persia> Ah.  pointlessness is to be avoided.
[03:50] <StevenK> wgrant: So it needs to be checked in, or just run on loganberry?
[03:50] <wgrant> StevenK: Just run on somewhere.
[03:51] <wgrant> Are you going to try it on DF?
[03:51] <LPCIBot> Project db-devel build (113): SUCCESS in 3 hr 55 min: https://hudson.wedontsleep.org/job/db-devel/113/
[03:57] <lifeless>     Hard / Soft  Page ID
[03:57] <lifeless>      279 /    8  Archive:EntryResource:getBuildSummariesForSourceIds
[03:57] <lifeless>      150 /   52  Person:+commentedbugs
[03:57] <lifeless>       90 /    0  MailingListApplication:MailingListAPIView
[03:57] <lifeless>       80 /  238  BugTask:+index
[03:57] <lifeless>       78 /  251  CodeImportSchedulerApplication:CodeImportSchedulerAPI
[03:57] <lifeless>       18 /   86  Archive:+packages
[03:57] <lifeless>       16 /   16  Archive:+copy-packages
[03:57] <lifeless>       14 /    8  ProjectGroup:+milestones
[03:57] <lifeless>       12 /  270  Distribution:+bugs
[03:57] <lifeless>       11 /   13  DistroSeries:+queue
[03:57] <wgrant> lifeless: Those should mostly be 0 tomorrow, right?
[03:57] <lifeless> well
[03:57] <lifeless> we're seeing lower layer things now
[03:59] <lifeless> s/layer/ frequency
[03:59] <lifeless> and some - like Archive:EntryResource:getBuildSummariesForSourceIds just need fixing.
[03:59] <lifeless> spm: reckon you could do the qastaging setup for the p3a thing we were discussing with mbarnett before
[04:43] <rockstar> wallyworld, hi
[04:59] <wallyworld> rockstar: yo
[05:04] <rockstar> wallyworld, your recent branch deletes the branchmergequeue model.
[05:04] <rockstar> Why?
[05:05] <wallyworld> rockstar: the diff is lying. my local copy still has it and a bzr --preview merge still shows it
[05:05] <wallyworld> what could have happened?
[05:05] <rockstar> wallyworld, hm.
[05:05] <rockstar> wallyworld, okay.
[05:05] <wallyworld> i did modify it but not delete it
[05:06] <wallyworld> did you see i made a new mp with the correct pre-req branch this time?
[05:06] <rockstar> wallyworld, the other thing I'd say is that all links to branch merge queue pages need to be hidden behind the feature flag.
[05:06] <wallyworld> i thought i had done that but will double check. i may well have missed something
[05:08] <rockstar> wallyworld, the menu item Links should probably have the enabled flag hinge on the feature flag.
[05:08] <wallyworld> or not even be rendered
[05:09] <wallyworld> that was mmy intention but i may have got distracted and left that bit out
[05:09] <rockstar> wallyworld, if they aren't enabled, they won't be rendered.
[05:10] <wallyworld> cool. i should have remembered that from when i was in that bit of the code a few weeks ago
[05:11] <wallyworld> i'm concerned that the diff is messed up though
[05:11] <rockstar> wallyworld, yeah, you might have some wierd criss crossing going on.
[05:12] <wallyworld> well, as i said a local bzr --preview merge .... looked ok and i double checked everything was pushed
[05:14] <rockstar> wallyworld, yeah, criss cross merges do weird things to the preview diffs on Launchpad though.
[05:14] <rockstar> Although usually they just claim conflicts.
[05:16] <wallyworld> well, i can always grab another copy of that branch of lp and double check that file
[05:16] <StevenK> wgrant: Sorry, was distracted. If you think it's useful to see if it works on dogfood, we can do that
[05:19] <StevenK> lifeless: Do you disagree with the implementation in https://code.launchpad.net/~mars/launchpad/add-profiling-feature-flag/+merge/39179 ?
[05:19] <lifeless> hmm?
[05:20] <StevenK> lifeless: You made a comment, but I'm having trouble comparing the code and your comment
[05:20] <lifeless> the code may have changed
[05:20] <StevenK> Since I agree with your comment
[05:21] <StevenK> It doesn't look to have changed since the 23rd
[05:21] <lifeless> ah yes
[05:22] <lifeless> I think the implementation is changing stuff it shouldn't
[05:22] <wgrant> StevenK: I think that letting it go through a couple of hundred would be a good idea.
[05:22] <lifeless> I gave the comment to provide a clear statement of what to aim for, IMNSHO
[05:22] <wgrant> Shouldn't take long.
[05:23] <StevenK> lifeless: Do you want to Needs Fixing it, then?
[05:24] <lifeless> StevenK: be my guest
[05:24] <lifeless> StevenK: sorry, I can if you want me to, but mars knows
[05:25] <lifeless> StevenK: so there's not really any need to touch it at all, except to move it to 'WIP'
[05:26] <StevenK> Okay, I've done that.
[05:33] <lifeless> wgrant: http://pastebin.com/qgsKkCDR
[05:34] <wgrant> lifeless: Yay.
[05:35] <lifeless> qa-ok ?
[05:36] <wgrant> lifeless: I'd reset the token and run the script it again just to be sure it works on an existing file.
[05:37] <lifeless> spm: pls run again
[05:37] <spm> lifeless: iz done
[05:37] <lifeless> similar output
[05:38] <lifeless> no crashie ?
[05:38] <spm> similar, not identical, no crash
[05:38] <spm> heh, similar in that no 'created' line, just the replaced.
[05:41] <wgrant> Great.
[05:41] <wgrant> qa-ok
[05:45] <spm> wgrant: shouldn't you be studying or somthing?!??!! ;-)
[05:46] <wgrant> Indeed, indeed.
[05:46] <StevenK> Hah
[05:54] <lifeless> StevenK: https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
[05:54] <lifeless> qa please!
[05:55] <lifeless> StevenK: or rather, what rev rolled it back ?
[05:56] <lifeless> StevenK: I seem to recall that you didn't put the metadata in ?
[05:56] <lifeless> spm: qastaging seems stale - it hasn't updated for a while
[05:57] <LPCIBot> Project devel build (179): STILL FAILING in 3 hr 31 min: https://hudson.wedontsleep.org/job/devel/179/
[05:57] <LPCIBot> Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=659171] Improve menu rendering performance
[05:58] <spm> lifeless: yes. according to the log, about 2-3 days worth, which seems... odd. Wed Nov  3 05:48:02 UTC 2010 Current Revno: 11824, New Revno: 11824 - nothing to update
[05:58] <lifeless> spm: this is driven by the thing on sodium
[05:58] <wgrant> stable's out of date...
[05:59] <lifeless> mmm, maybe. checking
[05:59] <wgrant> r11824
[05:59] <lifeless> ah yes
[05:59] <lifeless> spm: never mind
[05:59] <lifeless> buildbot hateness
[06:00] <spm> np; fwiw, sodium side does seem to be working as expected.
[06:02] <lifeless> StevenK: ping ;)
[06:05] <wgrant> I think dogfood might have eaten him alive.
[06:05] <wgrant> (he was attempting to run my script, and DF was resisting)
[06:06] <StevenK> lifeless?
[06:06] <lifeless> StevenK: rev 11820
[06:06] <lifeless> StevenK: your testfix for it didn't include [rollback]
[06:06] <lifeless> so the deploy script is unable to process it
[06:07] <lifeless> StevenK: I need to know what happened
[06:07] <StevenK> Can you give me the commit message?
[06:07] <lifeless> dude!
[06:07] <lifeless> https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
[06:07] <lifeless> or bzr log
[06:07] <StevenK> lifeless: It was 5 days ago, and I was in Orlando!
[06:07] <StevenK> And I'm trying not to swap out what I'm helping wgrant with
[06:07] <lifeless> StevenK: yes, but you've got hte data locally :)
[06:08] <StevenK> lifeless: If this was my testfix for devel, we spoke about it
[06:08] <lifeless> StevenK: not in detail.
[06:08] <StevenK> I did
[06:08] <lifeless> StevenK: please look at the log and let me know
[06:08] <StevenK> I changed the text scripts due to wgrant, and stupidly didn't run the branch through ec2
[06:08] <StevenK> How much more detail do you need?
[06:09] <lifeless> I need to know what revision fixes trunk.
[06:09] <lifeless> which normally wouldbe marked with [rollback=11820] but you didn't put that in, so I have to guess.
[06:09] <lifeless> I don't like guessing, so I'm asking you.
[06:09] <StevenK> lifeless: 11823 fixes 11820
[06:09] <lifeless> thank you
[06:10] <lifeless> StevenK: the other thing is that
[06:10] <lifeless> https://bugs.launchpad.net/soyuz/+bug/440652
[06:10] <_mup_> Bug #440652: Allow creation of PPAs via API <api> <bad-commit-11820> <oem-services> <ppa> <qa-needstesting> <Soyuz:Fix Committed by stevenk> <https://launchpad.net/bugs/440652>
[06:10] <StevenK> stevenk@mawson:~$ uptime
[06:10] <StevenK>  06:09:59 up 24 days, 12:11,  2 users,  load average: 4.06, 3.77, 3.31
[06:10] <StevenK> WGRANT!
[06:10] <lifeless> needs qa
[06:10] <lifeless> StevenK: so we're stalled until you do that.
[06:10] <lifeless> or again, tell me how to.
[06:11] <StevenK> lifeless: As something that's somewhat related, does lplib support qastaging? :-)
[06:11] <lifeless> StevenK: yes, see uhm the token librarian bug
[06:11] <lifeless> digging
[06:11] <wgrant> StevenK: I blame mawson's puny RAM.
[06:11] <wgrant> lifeless: Why should it have a rollback tag if it was a testfix, not a rollback?
[06:11] <StevenK> Apparently 4GiB is puny
[06:12] <lifeless> wgrant: because we don't have a rollforward tag yet
[06:12] <lifeless> wgrant: the semantics are identical from a deploy perspective.
[06:12] <StevenK> It's only 46KiB into swap, so its manging to keep everything in RAM so far
[06:12] <wgrant> StevenK: But it'll be doing that by evicting the cache frequently :(
[06:12] <StevenK> It's just utterly I/O constrained
[06:12] <wgrant> => slow
[06:12] <lifeless> StevenK: oh, it was on the list
[06:13] <wgrant> DF-publisher-slow.
[06:13] <lifeless> StevenK: look at the 'qa help needed' thread I started
[06:13] <StevenK> s/publisher-//
[06:13] <lifeless> kees describes the method
[06:13] <wgrant> StevenK: Well, the publisher is the one bigjools always whinges about :P
[06:13] <StevenK> wgrant: Can haz query that doesn't make mawson cry blood?
[06:14] <wgrant> StevenK: Have you tried the second one I gave? What does a plain EXPLAIN (not ANALYZE) say?
[06:14] <StevenK> Haha
[06:14] <wgrant> That bad?
[06:14] <StevenK> readline can't cope with start-of-line if the query is longer than the terminal length
[06:15] <wgrant> Heh.
[06:15] <spm> np; fwiw, sodium side does seem to be working as expected.rofl
[06:15] <spm> rofl!!! gah.
[06:16] <StevenK> wgrant: http://pastebin.ubuntu.com/524887/
[06:17] <lifeless> StevenK: find the thread?
[06:17] <StevenK> Still looking, trying to do three things at once
[06:19] <StevenK> wgrant: Those row counts are fecking enormous
[06:20] <wgrant> StevenK: They are, yes. (http://paste.ubuntu.com/524888/ has the same two queries with all the extra fields stripped out, so may be less abhorrent to read and handle)
[06:25] <wgrant> I don't see how this could be any worse than the PPA expiration query.
[06:25] <wgrant> Does the work on DF?
[06:25] <wgrant> s/the/that/
[06:32] <StevenK> wgrant: Sorry, got distracted, which do you want me to run?
[06:32] <lifeless> StevenK: by deployment stuff?
[06:32]  * lifeless injects a priority flag there
[06:33] <StevenK> lifeless: Wha? ECONTEXT?
[06:34] <lifeless> the qa
[06:34] <wgrant> StevenK: Neither. Just throwing less insane versions out there in case anyone feels like looking.
[06:36]  * StevenK tries to remember how to check what locales a machine supports
[06:37] <wgrant> StevenK: C should be enough for everyone!
[06:38] <persia> なに？
[06:38] <spm> StevenK: "locale -a" ?
[06:39] <StevenK> Ah, yes
[06:39] <StevenK> Typical, mawson only has en_GB
[06:39] <wgrant> persia: My Japanese is just good enough to understand that :P
[06:40] <spm> 'what'?
[06:42] <persia> It's not actually the correct response, in Japanese, but it translates better than the real way one expresses shocked surprise.
[06:42] <spm> heh
[06:42] <persia> (and, more importantly, fails to render in 'C')
[06:50] <lifeless> StevenK: so, as soon as you get a cycle, lets do this qa
[06:50] <lifeless> StevenK: its literally the most important thing we can do.
[06:50] <StevenK> I'm working on it now
[06:50] <lifeless> StevenK: \o/
[06:51] <lifeless> StevenK: if I can help, I'm here.
[06:51]  * StevenK tries to shake lifeless off his leg
[06:51] <lifeless> oh man, terrible image
[06:51] <StevenK> Haha
[06:51] <StevenK> I was thinking that you have a bite like a pitbull
[06:53] <lifeless> sure sure
[06:53] <lifeless> I rewatched st trinians just before uds
[06:53] <lifeless> *that* image was fresher.
[06:53] <StevenK> I've not seen that
[07:01] <StevenK> Note to self: Don't look up movie references that lifeless makes
[07:05] <lifeless> lol?
[07:07] <StevenK> I'd not heard of St. Trinians
[07:07] <StevenK> But it did introduce me to the actual word 'spiv'
[07:08] <lifeless> the new one or the old one ?
[07:08] <StevenK> I'd not even heard of the books
[07:09] <lifeless> thumper: looks like you didn't change the default series?
[07:11] <spiv> Hah.
[07:18] <spm> spiv is inferior tho. is only sp4, vs spm, which is sp1000. ergo. I win. QED.
[07:23] <spiv> spm: I like to think of it as a rank, not a score ;)
[07:25] <spm> spiv: curious, was the delay there because you were laughing too hard, or more working on a suitable response to kick the pedestal out from underneath me (successfully, as it turns out) ?
[07:25] <spiv> Merely because I wasn't watching IRC :)
[07:25] <spm> pay that. :-)
[07:26] <spm> StevenK: process-death-row on germs. thoughts here. Could that be nice'd (process pri as in) without being unduly "bad" or harmful in your view? or "Good Question" ?
[07:27] <wgrant> p-d-r is misbehaving?
[07:27] <wgrant> It's crap, but it should be crap on the DB, not germanium CPU, I would have thought.
[07:27] <StevenK> spm: Niced up or down? :-)
[07:27] <LPCIBot> Project db-devel build (114): SUCCESS in 3 hr 36 min: https://hudson.wedontsleep.org/job/db-devel/114/
[07:27] <LPCIBot> Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=570506][no-qa] Add an explanitory note
[07:27] <LPCIBot> about list formats.
[07:27] <spm> niced to stop being so evil that I get apache timeout alerts
[07:28] <spm> mind you, somewhat not helped by generate-ppa-htaccess atm, but that's a separate problem.
[07:28] <spm> I've seen these alerts before, so it's not exactly "new".
[07:29] <lifeless> we should have a dedicated script server soon
[07:29] <StevenK> We already have one?
[07:29] <lifeless> I asked charlie and james for one
[07:29] <wgrant> spm: Oh, the fix for that... issue... was as braindead as I suspected it might be?
[07:29] <spm> for soyuz?
[07:29] <wgrant> s/fix/cowboy/
[07:29] <lifeless> spm: for [qa]staging
[07:30] <spm> wgrant: ah, right.
[07:30] <StevenK> Note spm isn't talking about staging, but production
[07:30] <spm> lifeless: this is live on ppa.lp.net
[07:30] <StevenK> spm: Let me think on that
[07:30] <spm> np
[07:31] <spm> hrm. publishing/cron.daily-ppa could possibly do with some ionice'ing as well.
[07:31] <spm> find over the entire ppa tree is never going to be friendly.
[07:31] <wgrant> spm: If by "do with some ionice'ing" you mean "have some naivety beaten out of it", sure.
[07:31] <spm> ha
[07:32] <spm> yes, that too :-)
[07:32] <StevenK> With a stick
[07:32] <wgrant> Same with p-d-r.
[07:32] <wgrant> And g-p-h.
[07:32] <StevenK> We spoke about p-d-r at UDS
[07:32] <StevenK> It's a HARD problem
[07:32] <wgrant> Oh?
[07:32] <wgrant> p-d-r can be done in two queries.
[07:32] <spm> StevenK: so... put it on hold till... oh I dunno... middish december?
[07:33] <StevenK> spm: Sure, if you double the disk space germanium has
[07:33] <spm> easy! rm -rf /srv/ppa* ! SOLVED!
[07:33] <StevenK> spm: p-d-r deletes crap which stops you lot coming after us with bats since the librarian is full
[07:34] <wgrant> StevenK: What's making p-d-r so slow at the moment?
[07:34] <wgrant> It's not doing the hard stuff.
[07:34] <spm> seems pretty heaily cpu based atm
[07:34] <wgrant> That's the dominator.
[07:34] <StevenK> The sheer number of PPAs
[07:34] <wgrant> StevenK: Right, it iterates over every PPA.
[07:34] <wgrant> Rather than querying for those with condemned publications.
[07:34] <StevenK> Right
[07:34] <wgrant> == not terribly hard problem
[07:34] <StevenK> wgrant: Do you think this is patchable?
[07:35] <lifeless> bah
[07:35] <lifeless> so those windmill tests
[07:35] <lifeless> efail
[07:35] <StevenK> I note they keep failing in Hudson too
[07:35] <wgrant> StevenK: The query to reduce the set of candidate archives perfectly is non-trivial. But a slightly over-broad one is simple.
[07:36] <wgrant> And would probably vastly improve performance.
[07:36] <StevenK> wgrant: How much of a win are we talking?
[07:36] <wgrant> StevenK: I don't know how it performs on production.
[07:36] <StevenK> Slowly
[07:36] <wgrant> But we can probably get it to only consider a few hundred archives each time.
[07:36] <spm> I was going for badly, but slowly works.
[07:36] <StevenK> wgrant: A few hundred rather than a few thousand?
[07:37] <wgrant> StevenK: I think there's like 15000, but yeah.
[07:37] <StevenK> A factor of 50 drop is teh awesome
[07:37] <wgrant> If it's still really slow after that, we can look at optimising the remaining queries.
[07:37] <spm> we should shard ppa.lp.net
[07:37] <wgrant> But I think we should try the trivial fix first...
[07:39] <lifeless> wgrant: you asked if the windmill tests were passing locally
[07:39] <lifeless> wgrant: no
[07:39] <lifeless> wgrant: but they don't on trunk either
[07:39] <lifeless> wgrant: for me
[07:40] <wgrant> lifeless: .... that's a bit awkward.
[07:40] <StevenK> Oh, damn it, I think I know what's missing
[07:40] <wgrant> Oh, trunk, not stable?
[07:40] <lifeless> wgrant: the devel rev I branched from
[07:40] <lifeless> wgrant: could you perhaps try
[07:40] <wgrant> Which test?
[07:40] <lifeless> lp.bugs.windmill.tests.test_bug_me_too.TestMeToo.test_me_too from my mentoring branch
[07:41] <wgrant> That failed on Hudson.
[07:41] <wgrant> So it sounds legit.
[07:41] <wgrant> But running locally....
[07:42]  * StevenK grumbles, since he broke dogfood
[07:43]  * wgrant grumbles and prepares to go back to i386.
[07:43] <lifeless> StevenK: so, how did the qa go
[07:43] <StevenK> I'd like to test a hunch, but I need a dogfood for that
[07:44] <lifeless> could a losa help you on qastaging instead ?
[07:44] <StevenK> Can we do cowboys on qastaging?
[07:44] <lifeless> yes
[07:44] <lifeless> its our qa environment
[07:45] <StevenK> Right, let me prepare a proper patch
[07:45] <lifeless> it exists for figuring out if things are good or fucked.
[07:45] <StevenK> With me, it's mostly the latter :-(
[07:48] <wgrant> StevenK: Did you break Hudson too?
[07:48] <wgrant> It just stopped responding to me.
[07:48] <wgrant> Ah, alive again.
[07:48] <wgrant> Or not.
[07:48] <StevenK> It's working for me
[07:49] <wgrant> Yeah, happy again.
[07:49] <StevenK> It tends to not like loading our test results
[07:50] <wgrant> Ah, indeed, that's what I'd just asked it to do.
[07:53] <wgrant> lifeless: I don't know what buildbot thinks is good.
[07:53] <wgrant> lifeless: But the culprit is r11825.
[07:53] <wgrant> Reverting that fixes everything.
[07:54] <lifeless> wgrant: thank you for digging
[07:55] <lifeless> wgrant: please mail the list saying that windmill isn't random :)
[07:55] <lifeless> I'll prep a rollback now
[07:55] <lifeless> for clariry
[07:55] <lifeless>   [r=thumper][ui=none][bug=667586] Improve title and error message of
[07:55] <lifeless>         invalid branch links
[07:55] <lifeless>  ?
[07:57] <wgrant> Right, reverting that one fixed it (after a 'make build'; not sure if that is necessary).
[07:57] <wgrant> Could you try?
[07:57] <wgrant> wallyworld: Any ideas?
[08:01] <wgrant> And reverting the reversion breaks it again.
[08:01] <wgrant> Nothing obvious in the diff.
[08:01] <wgrant> But it's YUI.
[08:01] <wgrant> And I don't know YUI..
[08:01]  * StevenK blinks
[08:02] <wgrant> Hm?
[08:08] <lifeless> wgrant: after make , it still fails for me
[08:08] <thumper> lifeless: ?
[08:08] <lifeless> thumper: the windmill failures look like they may be a bad commit
[08:09] <wgrant> lifeless: You've made build?
[08:09] <lifeless> wgrant: yes, repeating now
[08:10] <thumper> lifeless: I guess roll it back and we'll take a look
[08:10] <lifeless> thumper: trying to confirm
[08:10] <lifeless> thumper: it fails both ways for me
[08:10]  * wgrant is rereverting.
[08:10] <lifeless> thumper: care to run lp.bugs.windmill.tests.test_bug_me_too.TestMeToo.test_me_too in devel
[08:10] <thumper> sure
[08:11] <lifeless> thumper: and then do a 'bzr merge -r 11825..11824 .' to back it out; make build, and run that test again ?
[08:11] <wgrant> And it passes.
[08:12] <lifeless> wgrant: yeah, I'd like one more data point cause its broke both ways for me
[08:13] <wgrant> Certainly.
[08:14]  * thumper is poking
[08:15] <thumper> yep
[08:15] <thumper> back it out
[08:15] <thumper> I can see the error
[08:15] <lifeless> doing so
[08:15] <thumper> a.slice is not a function
[08:15] <thumper> [Break on this error] var b = a.slice(), i = 0, n = -1, item = null;
[08:15] <thumper> collection.js
[08:15] <thumper> which was added in that branch
[08:16] <wallyworld> thumper: just got back from dr appt - my branch break something?
[08:16] <thumper> yep
[08:16] <thumper> see comment just above
[08:16] <thumper> breaks bug js
[08:16] <thumper> and probably others
[08:16] <thumper> I don't know why we are getting this
[08:16] <thumper> but we are
[08:16] <wallyworld> doesn't make sense to me either
[08:17] <thumper> lets look at it tomorrow
[08:17] <wallyworld> the only new thing done was importing collection.js to get the Array.unique() method
[08:18] <thumper> right
[08:18] <thumper> collection.js loading is causing problems
[08:18] <StevenK> lifeless: My cowboy still doesn't fix it :-(
[08:19] <wgrant> StevenK: What have you broken?
[08:19] <StevenK> wgrant: A new method I added
[08:19] <wgrant> createPPA?
[08:19] <wallyworld> hmmm. i'll revert to the version of my js code that didn't rely on Array.unique()
[08:19] <StevenK> Yeah
[08:20] <wallyworld> a bit messy but doesn't need collection.js
[08:20] <lifeless> StevenK: I don't care if it works :)
[08:20] <lifeless> StevenK: I care if we can deploy.
[08:20] <lifeless> StevenK: if we can deploy, qa-ok :)
[08:21] <StevenK> It's incredibly strange. It's returning a dict of, well, me
[08:21] <StevenK> ppa = me.createPPA(name='test2', displayname='Test 2')
[08:21] <StevenK> That should return an IArchive
[08:21] <wgrant> Let's see.
[08:21] <lifeless> StevenK: sounds like its qa-ok
[08:22] <StevenK> I still twitch when you tell me to do so
[08:22] <StevenK> Penalty card for lying, etc
[08:22] <lifeless> StevenK: we need to split out the different angles
[08:22] <lifeless> StevenK: and fortunately, they already are:
[08:22] <lifeless> set to in-progress
[08:22] <lifeless> qa-ok
[08:23] <StevenK> lifeless: I'd also refactored the browser code in that commit, but that works
[08:23] <StevenK> It's the API call that doesn't
[08:24]  * wgrant mauls the WADL generator.
[08:24] <lifeless> StevenK: does it break anything that worked before
[08:25] <StevenK> lifeless: Not that I can see
[08:27] <lifeless> StevenK: so qa-ok it already ;)
[08:27] <lifeless> thumper: separately, you were going to change the trunk series ?
[08:27] <thumper> lifeless: I'll add it to my todo list
[08:28] <lifeless> thanks!
[08:29] <StevenK> lifeless: Commented and done
[08:29] <lifeless> StevenK: thanks
[08:31] <wgrant> StevenK: So, WTF.
[08:31] <StevenK> lifeless: Re: your mail, does that mean Archive:+packages is now roughly 400 queries as opposed to 1100?
[08:31] <lifeless> StevenK: probably 800
[08:31] <StevenK> wgrant: Hm?
[08:31] <lifeless> depends on how much work was hidden behind the thing I've grouped on
[08:32] <wgrant> StevenK: That method.
[08:33] <StevenK> ... is complete crack?
[08:33] <lifeless> StevenK: https://pqm.launchpad.net/ - thats what a fix for a broken rev should look like
[08:33] <wgrant> StevenK: Ahhhhh.
[08:33] <wgrant> StevenK: launchpadlib bug.
[08:34] <wgrant> StevenK: Makes sense if you think about it.
[08:34] <wgrant> StevenK: lp.me.createPPA() results in a POST to /people/+me.
[08:34] <wgrant> StevenK: /people/+me redirects to /~name16.
[08:34] <wgrant> launchpadlib GETs /~name16.
[08:34] <wgrant> Boom.
[08:34] <lifeless> \o/
[08:35] <StevenK> wgrant: However, even after calling that, iterating over me.ppas results in 2, not 3
[08:35] <wgrant> StevenK: WFM :(
[08:35] <wgrant> StevenK: You're not using a slave?
[08:36] <StevenK> In the method? I use IMasterStore
[08:36] <wgrant> I mean in .ppas.
[08:36] <StevenK> wgrant: However, I'm perfectly willing to admit my code is wrong
[08:36] <wgrant> I doubt it.
[08:36] <StevenK> wgrant: I call .createPPA and then iterate over me.ppas
[08:36] <wgrant> (both that you're willing to admit it, and that the code is wrong)
[08:37] <StevenK> wgrant: I meant my QA script :-)
[08:37] <wgrant> Ah.
[08:37] <wgrant> paste paste
[08:37] <StevenK> wgrant: And, keep laughing, I'm reloading
[08:37] <StevenK> wgrant: http://pastebin.ubuntu.com/524936/
[08:38] <wgrant> StevenK: You're still using launchpad.me...
[08:39] <StevenK> Oh, I need to regrab it after .createPPA()?
[08:40] <wgrant> No, *for* createPPA.
[08:40] <StevenK> It's a person, isn't it?
[08:40] <wgrant> It is.
[08:40] <wgrant> But launchpad.me.createPPA() will post to something that redirects.
[08:40] <wgrant> == bad idea.
[08:40] <StevenK> Ah
[08:40] <wgrant> HTTP is awesome.
[08:40] <jml> morning all
[08:41] <wgrant> Evening jml.
[08:41] <lifeless> ola
[08:46] <StevenK> wgrant: So I have a cowboy that adds IMasterStore, do you think that impacts?
[08:47] <wgrant> StevenK: A write operation will always use the maste.r
[08:48] <StevenK> wgrant: I mean this diff: http://pastebin.ubuntu.com/524926/
[08:48] <wgrant> StevenK: Redundant.
[08:48] <StevenK> wgrant: If you think that diff is pointless, then excellent
[08:48] <StevenK> lifeless: It works, my qa script sucked
[08:48] <wgrant> s/my qa script/launchpadlib/
[08:48] <wgrant> s/launchpadlib/HTTP/
[08:49] <StevenK> Haha
[08:49] <wgrant> :( thumper doesn't appreciate Soyuz's acronyms :(
[08:50] <StevenK> wgrant: Hm?
[08:50] <wgrant> StevenK: In lifeless' MP.
[08:51] <adeuring> good miorning
[08:58] <jml> adeuring: good morning
[08:59] <jml> wgrant: it's not clear to a relative newcomer how much complexity in soyuz is inherent and how much could be simplified.
[08:59] <jml> wgrant: indeed, perhaps it's not clear to anyone :)
[09:00] <wgrant> jml: Heh. True.
[09:02] <stub> what is the recommended tool to view .subunit.gz files?
[09:06] <jml> stub: testr, probably.
[09:06] <jml> stub: there's also tribunal-subunit
[09:06] <jml> stub: and the various subunit-*  commands
[09:07] <stub> I was hoping for something that I could make run when I clicked on the attachment.
[09:08] <jml> stub: tribunal-subunit
[09:08] <mrevell> Good morning
[09:09] <jml> mrevell: hello
[09:10] <stub> jml: Is that hiding in a PPA somewhere?
[09:11] <jml> stub: perhaps. I think it's overdue a release, tbh.
[09:11]  * jml pokes around
[09:13] <stub> As far as LP is concerned, it only exists as a branch
[09:13] <jml> stub: yeah, that sounds about right.
[09:14] <jml> stub: I'd suggest hassling poolie
[09:15] <jml> or diy
[09:24] <gmb> Is there any way that we can make PQM Not do this:
[09:24] <gmb> 'Commit message [[rs=gmb][ui=none] The tests that needed to be combined because of\n\ttest isolation issues with feature flags have now been split up again.] does not match commit_re [(?# Strong suggestion: use ``bzr lp-land`` or ``ec2 land``.  Manual submission notes: your submission message needs [ui=...] AND at least one of [r=...] [rs=...] or [release-critical=...] AND at least one of [no-qa] [incr] [rollback=...] [bug=...].)(?is)(?=(\\s*\\[[
[09:24] <gmb> ^\\]]+\\])*\\s*\\[(release-critical=[^\\]]+|rs?=[^\\]]+)\\])(?=(\\s*\\[[^\\]]+\\])*\\s*\\[ui=[^\\]]+\\])(?=(\\s*\\[[^\\]]+\\])*\\s*\\[(incr|no-qa|bugs?=\\d+(,\\s*\\d+)*|rollback=\\d+)\\])]'
[09:24] <gmb> Cos that isn't helpful, at least when formatted that way.
[09:25] <wgrant> That is a nice re.
[09:25] <stub> Its like that to remind you to be thankful you are not a Perl programmer.
[09:26] <jml> gmb: The only options that spring to mind are patching it or switching to a different tool
[09:26]  * jml brb
[09:27] <gmb> stub: Amen.
[09:27] <stub> The regexp could get comments embedded in it perhaps... (?isx)
[09:27] <gmb> jml: Ah, right.
[09:28]  * gmb adds it to his list of things to try patching when he has a minute.
[09:28] <wgrant> Or we could hope that Code finishes merge queues soon, and then switch to Tarmac :)
[09:29] <stub> tribunal-subunit looks like what I'm after. 'setup.py install --user' worked fine for install
[09:40] <jml> stub: cool.
[09:41] <jml> stub: fwiw, I started making daily builds of a whole bunch of testing tools incl. tribunal. I'm still intending to actually make them work.
[09:42] <jml> unfortunately my plane left on time :(
[09:43] <jml> some may be interested in subscribing to https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/670289
[09:43] <_mup_> Bug #670289: Laptop won't shut down with rabbitmq running <amd64> <apport-bug> <maverick> <rabbitmq-server (Ubuntu):New> <https://launchpad.net/bugs/670289>
[09:43] <wgrant> Ah, so it's not just me.
[09:44] <jml> wgrant: you might recall bigjools mentioning this on the list
[09:49] <stub> Does the magic exist to only run previously failed tests (identified by a subunit stream of the previous run)
[09:49] <stub> ?
[09:49] <wgrant> That's what testr is for.
[09:49] <jml> stub: 'testr run --failing'
[09:56] <stub> Hmm.... tribunal-subunit identifies 89 failed tests, testr 91...
[09:59] <stub> Need to generate a failing.list...
[10:01] <wgrant> stub: 'testr load'
[10:03] <stub> That doesn't seem useful for testr run --failing though - it seems to want a list of failed tests rather than extracting them from the testr database
[10:03] <wgrant> Oh.
[10:03] <wgrant> testr failing
[10:03] <stub> "subunit-filter --no-passthrough < ~/Downloads/update-storm-r8330.subunit | subunit-ls" might be the ticket
[10:06] <stub> Output from 'testr failing' seems to be doing something... no output but I've started swapping :)
[10:17] <jml> 'testr failing --list' in trunk
[10:57] <deryck> Morning, all.
[11:00] <wgrant> jelmer: Did you end up ec2ing the branch? I heard nothing from it.
[11:01] <jelmer> wgrant: Yes, but I didn't hear anything about it either.
[11:01] <jelmer> wgrant: I'm working on a high priority thing at the moment, will have a look after that.
[11:01] <jelmer> wgrant: Sorry it's taking this long.
[11:02] <wgrant> Ah, yeah, forgot you were working on that.
[11:26] <LPCIBot> Project devel build (180): STILL FAILING in 3 hr 55 min: https://hudson.wedontsleep.org/job/devel/180/
[12:05]  * jml is being punched in the face by jetlag
[12:30] <mrevell> deryck, Hi, is there a known problem with +manage-official-tags whereby the official tags list displays "{count}" beside some tags, rather than a number? I don't see a bug report, so will file one if it's new to you.
[12:31] <deryck> mrevell, no, not known.  bdmurray did some work with allowing bug supervisors to edit official tags, but I don't think that would have caused that issue.
[12:32] <mrevell> deryck, I'll report a bug
[12:32] <deryck> mrevell, thanks!
[14:10] <leonardr> mars, sorry to bug you about this, but do you have any idea what's going on with these ec2 test failures?
[14:10] <leonardr> http://pastebin.ubuntu.com/525067/
[14:22] <sinzui> leonardr, I have lost my mind. I added a new method to an interface that is a variation of an existing method. I cannot build my branch though: AssertionError: No IEntry adapter found for Interface (web service version: beta).
[14:22] <sinzui> leonardr,  What do I need to register to solve the missing IEntry?
[14:24] <leonardr> sinzui: let me see the diff?
[14:24] <leonardr> i don't think you need to register anything. i think you prevented some generated code from being generated, or something like that
[14:24] <jml> sinzui: perhaps one of the types used in the method sig is not exposed? alternatively, perhaps the circular import resolver isn't being used properly
[14:25] <leonardr> yeah, i'm thinking along the same lines
[14:26] <sinzui> leonardr, http://pastebin.ubuntu.com/525077/
[14:27] <sinzui> jml: leonardr: there are no new objects. You can leave a team, but you cannot remove your team from a team. I added a method to do that ...
[14:28] <leonardr> sinzui: is it possible that the type of ITeamMembership['team'] hasn't been defined at this point? that it's defined in circular_imports?
[14:28] <jml> sinzui: I think you want to close paren after ITeamMembership['team']
[14:30] <sinzui> leonardr, The 3 methods before this method are doing it. http://pastebin.ubuntu.com/525079/
[14:31] <jml> sinzui: your parens are mismatched.
[14:31] <sinzui> :(
[14:31] <sinzui> thanks jml:
[14:31] <jml> sinzui: np.
[14:31]  * sinzui stabs editor
[14:34] <jcsackett> sinzui: i find fire is really the best way to discipline your editor.
[14:38] <mars> leonardr, looking
[14:41] <mars> jml, future of the web sounds a bit like X windows :)
[14:50] <mars> jml, and thank you for writing the synopsis.  I don't have the time to watch the video right now, and it nicely summarizes his argument
[14:55] <mars> leonardr, I would guess your branch failures are because devel was broken yesterday.  My branch failed the same way.  Try merging from the latest devel and use ec2 land.
[14:56] <leonardr> mars, ok
[14:56] <mars> leonardr, actually, you should not have to update from devel, because of the way the ec2 merge works
[14:57] <mars> I'm trying to pull a definitive set of failures
[14:57] <leonardr> mars, kind of an embarrassing question, can you walk me through using ec2 land? (assuming there's anything special to it)? i'm still using pqm-submit manually because i never got over my fear of ec2 land when it was new
[14:57] <mars> leonardr, just a minute
[14:58] <mars> leonardr, no problem.  Does ec2 test work for you?
[14:58] <leonardr> mars: yes, in general
[14:58] <leonardr> (i assume you mean 'do you typically use it', and i do)
[14:59] <mars> right
[14:59] <mars> ok, good
[15:00] <sinzui> leonardr, jml: sorry, I still get the same error after fixing the parens. http://pastebin.ubuntu.com/525096/
[15:01] <jml> sinzui: what happens if you put call_with below operation_parameters?
[15:01]  * sinzui tries
[15:02] <mars> leonardr, ec2 land works just the same as ec2 test, except that it will check the merge proposal for the data it needs to commit
[15:02] <leonardr> mars: so i set the commit message etc. there?
[15:03] <mars> leonardr, to use ec2 land the merge proposal needs to be 'Approved'.  You can set the commit message on the MP, or using "ec2 land -s"
[15:03] <sinzui> jml: same error
[15:03] <leonardr> jml: there are lots of other cases where it's above @operation_paramters
[15:03] <LPCIBot> Yippie, build fixed!
[15:03] <LPCIBot> Project devel build (181): FIXED in 3 hr 36 min: https://hudson.wedontsleep.org/job/devel/181/
[15:03] <LPCIBot> * Launchpad Patch Queue Manager: [r=henninge][ui=none][bug=117460] Adds a help icon link beside the
[15:03] <LPCIBot> "Also affects project" link on the bug page. Also adds a
[15:03] <LPCIBot> modified version of Bryce's suggested explanatory text to the
[15:03] <LPCIBot> +choose-affected-product page.
[15:03] <LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][ui=none][no-qa][incremental] unit tests for
[15:03] <LPCIBot> BugTaskSet.search(): upstream status related filtering,
[15:03] <LPCIBot> filtering by tags, by date_closed, by fulltext search,
[15:03] <LPCIBot> by fast fullext search and by has_no_upstream_bugtask
[15:03] <LPCIBot> * Launchpad Patch Queue Manager: [rs=gmb][ui=none][no-qa] The tests that needed to be combined because
[15:03] <LPCIBot> of test isolation issues with feature flags have now been split
[15:03] <LPCIBot> up again.
[15:03] <LPCIBot> * Launchpad Patch Queue Manager: [r=thumper][ui=none][no-qa][rollback=11825] Backout the cause of windmill failures.
[15:03] <LPCIBot> * Launchpad Patch Queue Manager: [r=jml][ui=none][bug=670081][no-qa] Delete the python component of the removed mentoring feature.
[15:03] <jml> leonardr: not on my screen at the time :)
[15:03] <lifeless> moin
[15:03]  * mars is not accustomed to bot barf in the middle of conversations
[15:04] <lifeless> jml: flacoste: Apologies for the TL meeting; taking Lynne to the airport.
[15:04] <jml> lifeless: np
[15:04] <flacoste> lifeless: no worries
[15:04] <jml> StevenK: where do I file bugs against your IRC bot?
[15:04] <lifeless> jml: launchpad itself.
[15:05] <mars> leonardr, you do not need to add the [r=...] or any tags to the commit message.  ec2 land will do that for you
[15:05]  * sinzui moved method higher in the interface
[15:05] <lifeless> jml: its where we file things for bb after all; I'd assign to StevenK to get his attention.
[15:05] <mars> leonardr, and you may want to set the QA status.  What kind of QA do you anticipate for this change?
[15:05] <lifeless> oh yay, build fixed.
[15:05] <lifeless> and, excellent. We have killed mentoring.
[15:05] <mars> lifeless, ?
[15:05] <leonardr> mars: the normal kind where i try a couple things out with the web browser
[15:07] <lifeless> mars: the feature we removed from the UI is now gone from the code base. \o/.
[15:07] <mars> leonardr, ok, ec2 land will assume 'qa-needstesting' on the linked bugs when you submit your change.  If there are no linked bugs, it will print a nice warning telling you how to set up QA properly.
[15:07] <mars> lifeless, ah, awesome
[15:10] <mars> leonardr, that's it.  Very simple.  You just set the commit message, consider your QA, and go.  It handles the rest.
[15:10] <henninge> rockstar: ping
[15:10] <jelmer> rockstar: hi
[15:10] <henninge> ;-)
[15:11] <shadeslayer> jam: any other news on my qtwebkit bug :D
[15:11] <leonardr> mars, ok, thanks
[15:12] <mars> leonardr, fwiw, the same flags are used for 'bzr lp-land'.  It will do the same as ec2 land, but without the ec2 run.  Since your failures look to be from a broken build, not your own work, you would be safe using that too.
[15:13] <leonardr> mars: ok, two things that make me worry about using bzr lp-land here
[15:13] <leonardr> 1. did i miss my chance to set a commit message on the merge proposal when i created the merge proposal? i don't see any way to add one now
[15:13] <leonardr> 2. similarly, my mp is for merging into db-devel, not devel, because i made the same dumb mistake i always make
[15:14] <leonardr> what do you think?
[15:14] <leonardr> should i just try pqm-submit?
[15:15] <m4n1sh> How do you control spam on Launchpad. Esp when some person/bot starts messing up with the bug reports?
[15:15] <mars> leonardr, for the first one, you can edit the commit message on the MP at any time.
[15:15] <m4n1sh> This is the person who is doing it right now
[15:15] <m4n1sh> https://launchpad.net/~braulioareis
[15:15] <mars> m4n1sh, sinzui can help you with that
[15:15] <m4n1sh> these are the bu g reports he is fidding at http://paste.ubuntu.com/525113/
[15:15] <m4n1sh> sinzui: ^^
[15:16] <leonardr> oh, i see 'set commit message'
[15:16] <leonardr> it's hard for me to use web apps because i subconsciously filter out a lot of things as 'advertising'
[15:16] <sinzui> m4n1sh, ask a question so that the bugs team can investigate https://answers.launchpad.net/malone
[15:16] <mars> leonardr, regarding the second - I don't actually know how to retarget a merge proposal like that.
[15:16] <leonardr> mars: i usually have to delete and re-submit
[15:16] <sinzui> m4n1sh, They can suspend a user and make arrangements to remove the spam from the comments
[15:17] <leonardr> so this time, i'll just use pqm-submit as i usually do
[15:17] <mars> leonardr, do you have to delete first?
[15:17] <leonardr> but now i'm not afraid of ec2 land anymore
[15:17] <mars> leonardr, or just resumit, and rs=mars
[15:17] <leonardr> mars: let me try it
[15:17] <leonardr> mars, it says "Another merge proposal will be created, with the same source, target and prerequisite branch (if any). "
[15:17] <mars> leonardr, try hitting resubmit, send me the link to the MP
[15:17] <leonardr> that's why i've been deleting and resubmitting, i think
[15:18] <leonardr> but let's try it
[15:18] <mars> leonardr, ah, hmm
[15:18] <mars> abentley, ping
[15:18] <leonardr> mars: yeah, it doesn't let me change that
[15:18] <abentley> mars: pong
[15:18] <mars> Hi abentley, leonardr and I have a merge proposal user question for you
[15:18] <sinzui> m4n1sh, the user is not a spammer, he needs a talking too though about etiquette
[15:19] <mars> abentley, leonardr accidentally set db-devel as his submission branch.  He now wants to merge his code to devel.  Unfortunately, the land commands read the original MP for instructions, so they will do the wrong thing.
[15:20] <mars> abentley, resubmission does not work, because it does not let you change the merge target
[15:20] <abentley> mars: he should use pqm-submit, then.
[15:20] <mars> leonardr, ^ ah
[15:20] <mars> abentley, ok, thank you
[15:20] <abentley> mars, I have started a branch to allow changing the merge target with resubmit, but it's not ready yet.
[15:20] <m4n1sh> sinzui: I just used the word spammer as he was changing random bug status without talking to anyone
[15:21] <sinzui> m4n1sh, I suspect the user does not even know that he is generating emails
[15:21] <m4n1sh> Or probably he was playing with Launchpad
[15:21] <m4n1sh> sinzui: probably yes
[15:21] <m4n1sh> atleast important bugs like https://bugs.launchpad.net/ubuntu/+source/libmodule-build-perl/+bug/661901 should be spared
[15:21] <_mup_> Bug #661901: Needs re-promotion to Main <libmodule-build-perl (Ubuntu):New> <https://launchpad.net/bugs/661901>
[15:21] <mars> abentley, nice, sounds like what I was hoping for
[15:22] <lifeless> Ursinha: https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html 404's?
[15:22] <leonardr> mars: so, for real this time, using pqm-submit
[15:22] <mars> leonardr, yes
[15:24] <Ursinha> lifeless, https://devpad.canonical.com/~lpqateam/ 404's, losas are investigating
[15:25] <lifeless> Ursinha: kk thanks
[15:34] <leonardr> sinzui: sorry, coming back to you now
[15:35] <sinzui> leonardr, np. I decided that I wont let this issue block me and set it aside. The answer many be more obvious after a break
[15:36] <leonardr> sinzui: i suggest you put breakpoints in your lazr.restful declarations.py so that you can watch the named operation adapter being constructed
[15:36] <sinzui> okay
[15:45] <gary_poster> Anyone have any idea on what I should do with this? https://bugs.edge.launchpad.net/launchpad/+bug/670347
[15:45] <gary_poster> For reference, Google translate gives the text as
[15:45] <gary_poster> THANKS it youness stager of Fili from Morocco tmsri (mantenence and computer support and resalable I must pronder the operating system ebuntu plzzz
[15:45] <gary_poster> application operating system ebuntu blzz
[15:45] <gary_poster> Options in my head:
[15:46] <gary_poster> - try assigning it to Ubuntu.  I feel kind of bad about doing that to Ubuntu because my other option is...
[15:46] <gary_poster> - Mark it as Won't Fix and suggest that they use the questions application for Ubuntu
[15:47] <gary_poster> and if they are serious they can do that, otherwise they will just disappear
[15:47] <gary_poster> Actually, unless anyone stops me, I'm going to do #2
[15:48] <leonardr> gary: fwiw, i'd give 3 to 2 odds they want ubuntu cds
[15:48] <gary_poster> heh, maybe so leonardr .  I'll give that link too.
[15:55] <lifeless> mrevell: how does one make a blog turn on up the home page? I want to broadly announce that edge is gone[ish]
[15:56] <lifeless> deryck: after you fix text wrapping.... allowing reassign from launchpad to ubuntu would be THE MOST AWESOME CHANGE EVER
[15:56] <jml> lifeless: can't wait for the real thing?
[15:56] <lifeless> jml: coca cola?
[15:57] <jml> lifeless: edge being fully gone
[15:57] <deryck> lifeless, yeah, I agree.  Not sure we'll take that on anytime soon yet, though. :-)
[15:58] <lifeless> -> airport
[15:58] <lifeless> jml: users are confused now.
[15:58] <jml> lifeless: Makes sense. I hadn't noticed.
[15:58] <jml> mrevell: do we have a standard thing that we do for Launchpad jargon?
[15:59] <lifeless> deryck: if we can make it a small change, would you do it ?
[16:00] <deryck> lifeless, heck yeah
[16:00] <deryck> so I assume it's not a small change.  I haven't looked in awhile at it
[16:02] <mrevell> lifeless, Ah, that's superb. Are you on jetlag time at the moment? I was hoping to have a call with you about that sort of thing. For the front page, add the tag front-page to the post.
[16:02] <abentley> rockstar: chat?
[16:02] <mrevell> jml, Kinda. https://help,launchpad.net/Glossary is out of date and should probably go away but we could resurrect it.
[16:02] <rockstar> abentley, sure.
[16:02] <rockstar> abentley, mumble, eh?
[16:02] <abentley> Sure.
[16:02] <jml> mrevell: I meant in-app.
[16:03] <jml> mrevell: but it is good to be reminded about the glossary :)
[16:03] <mrevell> jml, I'm not sure what you mean. Do you have an example?
[16:05] <jml> mrevell: e.g. one of the fields on the recipe creation page is "default distribution series"
[16:05] <jml> mrevell: but what if I don't know what a distribution series is?
[16:06] <rockstar> abentley, I'll be there in a sec.  Unpairing my headset and repairing seems to have confused mumble.
[16:06] <abentley> rockstar: ah.
[16:08] <mrevell> jml, Hmm. I can't think of anything particularly elegant that we can do with what we have now. A question mark icon beside the text linking to a help pop-up is what I'd opt for.
[16:20] <jml> mrevell: ok, thanks.
[16:21] <rockstar> abentley, you slowly faded off and now I can't hear you.
[16:55] <abentley> rockstar: https://code.edge.launchpad.net/~rockstar/launchpad-code/mockups
[16:58]  * jml off IRC for the evening
[16:58] <jml> g'night all
[16:59] <abentley> lifeless: Have you turned off edge redirection before turning on recipes for members of the beta team?
[17:21] <lifeless> abentley: hi; yes edge redirection is off. The edge site still exists.
[17:33] <lifeless> mrevell: hi
[17:33] <mrevell> Hello lifeless
[17:33] <lifeless> mrevell: I'm happy to do a call if you want
[17:34] <mrevell> lifeless, I'm tied up for the remaining 30 mins of my day. Do you want to publish your post and then I'll email you if I have any questions. I want to mail beta testers, update the help wiki, etc, in response to the removal of edge.
[17:34] <mrevell> I wasn't quite sure on the details but I reckon your post will clear that up.
[17:35] <lifeless> mrevell: I'm not sure mailing beta users is a good idea.
[17:35] <lifeless> mrevell: I agree that we should update the wiki and docs and so forth.
[17:35] <mrevell> lifeless, No? I thought it would be a courtesy to explain the removal of the redirect.
[17:35] <lifeless> mrevell: We change many things without directly contacting affected users.
[17:36] <lifeless> What makes this change special enough to warrant a particular call-out ?
[17:36] <LPCIBot> Project db-devel build (115): SUCCESS in 3 hr 55 min: https://hudson.wedontsleep.org/job/db-devel/115/
[17:36] <mrevell> lifeless, True but we've always done things a little differently with the beta team and, when we moderated the team at least, we emailed each new member to explain that receiving infrequent email updates would be part of the deal.
[17:37] <mrevell> Anyway, the blog and the wiki are my priorities so I'll wait on your blog post.
[17:37] <lifeless> mrevell: so, I think many beta users were told 'join this group because XXX' rather than being really committed beta testers
[17:38] <lifeless> mrevell: there are 2000 members.
[17:38] <lifeless> mrevell: also there is a typo on the launchpad-beta-users team description
[17:39] <mrevell> lifeless, I'm not sure that makes a difference but, certainly in the first two or three years of the team's existence, we advertised the team as being specifically for redirects to a beta version (initially for the new UI and then to get specific features that we emailed each team member about).
[17:39] <mrevell> I'll fix the type.
[17:39] <mrevell> heh
[17:39] <mrevell> typo
[17:39] <lifeless> lol
[17:39] <lifeless> right, we advertised it for that
[17:40] <lifeless> I think we should message this clearly
[17:40] <lifeless> but the consistent feedback I've seen on email communications about our product is that less is more.
[17:40] <lifeless> That is, that its better for us to make things smooth and painless, than to email.
[17:41] <lifeless> YMMV
[17:43] <mrevell> Yeah, no doubt, but I don't see how that ties up here. We have sent many emails to the beta team ... none in the past year, or so, admittedly. I recall no complaints. Either way, I don't want to get stuck in tangental conversation around this :) I'll drop you a mail/ping you when I've read your post ... thanks for writing that, btw.
[17:44] <lifeless> mrevell: no probs
[17:57] <lifeless> gary_poster: hi
[17:57] <lifeless> gary_poster: how would you feel about making the deploy-latency graph high? I think its one of our key inner loops in a LEAN sense.
[17:58] <lifeless> gary_poster: and thus worth measuring [and focusing on]
[17:58]  * gary_poster tries to context switch
[17:58] <lifeless> :) - sorry
[17:59] <gary_poster> bug 668149
[17:59] <_mup_> Bug #668149: graph deploy latency <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/668149>
[17:59] <lifeless> yeah
[18:04] <gary_poster> lifeless, as part of providing metrics for showing SMM, we will be gathering the amount of time it takes to go from an accepted MP to landing on stable (script is written now for review).  The amount of time going from an accepted MP to deployed is a similar measurement--and similar to what you have requested.
[18:04] <gary_poster> Maris and Diogo have a lot of related measurements in mind for this kind of thing.
[18:04] <gary_poster> I'm cool with saying "we'll work on some graphing of this stuff in December" and hammering out the details then.  We can even say that this equates to "High" :-)
[18:05] <lifeless> gary_poster: what I'm specifically interested in is 'qaable to deployed'
[18:06] <lifeless> gary_poster: which is deployed-on-qastaging through to deployed-on-prod
[18:06] <gary_poster> yes, lifeless, by adding "when deployed" to our existing measurements, we would then have that.
[18:06] <lifeless> ok
[18:06] <lifeless> thank you
[18:07] <gary_poster> np, will add summary to bug
[18:18] <gary_poster> lifeless, re bug 670013, I currently believe that what Leonard decribed in comment 5 and I elaborated on in comment 6 is the best way forward identified so far.  It involves some dev work.  The only resource I have that might be available for this in Nov is stub, who would probably be very appropriate for it, and might have another idea on an approach.
[18:18] <_mup_> Bug #670013: preflight check for removing edge cluster <Launchpad Foundations:Triaged by leonardr> <https://launchpad.net/bugs/670013>
[18:19] <abentley> lifeless: You have effectively disabled recipes for people.  Do you plan to re-enable them?
[18:20] <gary_poster> Didn't see your reply on the bug, lifeless; so, my comment # 7 is the elaboration.  That approach is not your client transfer, but sending the edge vhost to the production cluster, and having the application know how to handle it transparently.
[18:22] <lifeless> abentley: how so?
[18:22]  * gary_poster needs late lunch.  will be back in a while
[18:22] <abentley> lifeless: they won't see it unless they specifically go to edge, which is a change in behaviour.  It even caught rockstar by surprise.
[18:23] <lifeless> abentley: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/666538
[18:23] <_mup_> Bug #666538: add team: feature scope selector <feature-flags> <Launchpad Foundations:Triaged by mbp> <https://launchpad.net/bugs/666538>
[18:23] <lifeless> abentley: thats about top of my todo now, which will allow us to do gradual exposure on prod
[18:24] <abentley> lifeless: I am glad that it's at the top, but I assumed it was a blocker for stopping edge redirection.
[18:25] <lifeless> abentley: I assumed that folk already knew it only worked on edge
[18:26] <lifeless> abentley: the bug is definitely a blocker for disabling or removing edge.. perhaps it should have been a blocker for removing the redirect
[18:26] <abentley> lifeless: until now, I've always typed production urls and let it redirect me to edge.
[18:27] <abentley> lifeless: for example, rockstar punched in a URL for one of his branches, then got worried because there was no "recipe" link.
[18:28] <lifeless> abentley: I understand. This does speak positively towards consolidating on one UI with team (or other settings) controlled disclosure
[18:28] <abentley> lifeless: I happened to navigate to an "edge" url, and then we argued about whether the link was gone for a minute until we figured it out.
[18:28] <lifeless> abentley: we may have sequenced it wrongly. Rolling back will be tricky.
[18:29] <lifeless> so, I'll whip up a team scope post haste.
[18:30] <abentley> lifeless: Cool.  I wonder if we should post about this on the identica feed.
[18:30] <lifeless> I'll do that
[18:31] <abentley> lifeless: Great.  Thanks.
[18:31] <abentley> lifeless: I don't understand "This does speak positively towards consolidating on one UI with team (or other settings) controlled disclosure".
[18:32] <abentley> lifeless: you're talking about one UI with features optionally enabled depending on team (or other)?
[18:32] <lifeless> yes
[18:34] <abentley> lifeless: Yes, I think conditional feature flags are going to be very useful.  I can imagine more features being launched "in beta" like recipes.
[18:35] <lifeless> gary_poster: I had replied on the bug before seeing your irc comment
[18:35] <lifeless> gary_poster: we can stay on the bug, or irc, or both as you choose ;)
[18:35] <lifeless> gary_poster: leonardr: I appreciate your rapid analysis of this.
[18:35] <leonardr> np
[18:37] <LPCIBot> Project devel build (182): SUCCESS in 3 hr 34 min: https://hudson.wedontsleep.org/job/devel/182/
[18:37] <LPCIBot> * Launchpad Patch Queue Manager: [r=bac][ui=none][no-qa] Update cronscripts/expire-bugtasks to add
[18:37] <LPCIBot> --ubuntu and --limit options,
[18:37] <LPCIBot> which will allow batch runs of only a few Ubuntu bugtasks as we begin
[18:37] <LPCIBot> to test run expiry.
[18:37] <LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=657109] Do not snapshot PersonLocation.
[18:38] <lifeless> StevenK: could you set the 'spam while failing or first success' rather than 'spam on completion' flag ?
[18:40] <lifeless> flacoste: hey
[18:41] <lifeless> flacoste: so, automatic releases. I really disagree. Vehemently
[18:41] <flacoste> lifeless: that's a mistake in the notes
[18:41] <flacoste> lifeless: what we talked about was actually not having to push the deployment from our side
[18:41] <flacoste> lifeless: a kind of "manual" automatic deployement
[18:42] <flacoste> lifeless: and the discussion actually needs to involve losa
[18:42] <flacoste> i suggested something like having a schedule roll-out window where LOSA deploys regularly whatever deployment-stable says is ready for deployment
[18:43] <lifeless> flacoste: I'd like to get devs more involved here rather than less.
[18:43] <lifeless> flacoste: there will always be subtleties
[18:44] <lifeless> flacoste: we should be deploying up to 10 revs a day tue-friday(am,nz-friday), and 30 on monday.
[18:45] <flacoste> lifeless: care to justify the necessity of the dev / losa hands off here?
[18:46] <flacoste> what are the subtleties that makes this necessary
[18:46] <lifeless> flacoste: some angles:
[18:46] <lifeless>  - 'devops' - its not a handoff, its a collaboration.
[18:47] <lifeless>  - long term goal: realtime deployments, if something goes wrong the dev responsible is there to help.
[18:48] <lifeless>  - accountability - its our job to ensure stuff gets deployed
[18:49] <lifeless> flacoste: I realise we disagree here; I'd like to shelve this - and leave it shelved - until we've achieved the common elements:
[18:49] <lifeless>  - high volume short duration low failure rate deploys
[18:50] <lifeless>  - massive automation around the process [so that it is pushbutton for both dev+ops (its only pushbutton for ops today)]
[18:50] <lifeless> flacoste: at which point we can do an assessment about the ongoing value of dev interaction there.
[18:51] <lifeless> flacoste: right now, for instance, the last deploy, 3 back, and the next one all have bad metadata about broken revisions, so the process would stall if it was automated.
[18:51] <lifeless> flacoste: by having dev accountability, theres no temptation to leave-it-to-the-robots
[18:53] <flacoste> lifeless: i'm convinced about the value of on-demand deployments, i'm not advocating "leave-it-to-the-robot" roll-out anymore
[18:54] <lifeless> flacoste: there may be a nuance I'm misunderstanding ;)
[18:54] <flacoste> lifeless: what i'm not sure about is the value of why we need a different 'ask-a-losa-to-deploy' step that is different than the QA step which steps 'this-is-ready-to-deploy'
[18:54] <flacoste> s/which steps/which says/
[18:54] <flacoste> or actually says
[18:54] <lifeless> flacoste: oh, right
[18:54] <lifeless> flacoste: so, mthaddon doesn't want the losas overwhelmed with single-revision deployments
[18:55] <lifeless> we need to iterate up to that.
[18:55] <flacoste> right, i agree
[18:55] <lifeless> devs can assess the importantance of a deploy. E.g. 'urgent' -> single rev is ok.
[18:55] <lifeless> or routine - wait for a days worth.
[18:55] <flacoste> that's why i'm proposing let's schedule one or two regular roll-out window, where losa deploys wathever 'new' is
[18:55] <flacoste> so there is no request, but it's still run by a human
[18:56] <flacoste> i agree that, it could be seen as less accountability from dev there
[18:56] <flacoste> but it seems tenuous
[18:56] <lifeless> flacoste: I suspect that Tom would rather a request, than be required to go look
[18:56] <flacoste> i can also buy "assess the importance of a deploy"
[18:57] <lifeless> flacoste: but I'm guessing there.
[18:57] <flacoste> right, that's why the action was really 'Francis to discuss with LOSA and lifeless about this'
[18:57] <flacoste> so I have your opinion, i'll discuss with IS in the next infrastructure meeting :-)
[18:58] <lifeless> flacoste: ahh :)
[18:58] <lifeless> flacoste: another angle is that I want to ratchet the frequency up as fast as we can sort toolchain issues.
[18:59] <lifeless> flacoste: so I'd like to suggest that if we do make this a pull action from the losa side, that we do bug 668149 first
[18:59] <_mup_> Bug #668149: graph deploy latency <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/668149>
[19:02] <flacoste> lifeless: makes sense
[19:25] <lifeless> its been so long since bb was happy
[19:25] <lifeless> I'm worried we've landed *another* broken commit since 11825
[19:27] <mars> lifeless, you can always run 'ec2 test -t', it will check devel for you
[19:27] <lifeless> mars: the problem is bisecting, not how-to-do-it
[19:32] <gary_poster> I thought https://launchpad.net/me/+reviewaccount would resolve.  Can someone remind me what the generic "go to your logged in account" URL is?
[19:33]  * gary_poster tries help.launchpad.net
[19:33] <gary_poster> it is /people/+me I think
[19:33] <gary_poster> yup
[19:48] <lifeless> OOPS-1768F2005 - thumper
[19:48] <lifeless> https://code.launchpad.net/launchpad
[19:48] <lifeless> looks like __traceback_info__: (<RevisionAuthor at 0x153770d0>, 'person') is triggering DB access
[19:52] <lifeless> ok, back in a couple hours; time for my allergy injection
[19:58] <leonardr> matsubara, do you have some time to talk about your use of launchpadlib? gary says you're having some problems that fit in with the work we're trying to do
[19:59] <gary_poster> matsubara, I was thinking of the XXX you had where you wanted to get certain bugs/revisions/somethings in that stats script you were just working on
[19:59] <gary_poster> and instead you had to iterate through all somethings
[20:00] <matsubara> leonardr, gary_poster: right, it's the getMergeProposals() method which doesn't accept a date parameter
[20:00] <gary_poster> I think it is bug 626680 or something similar
[20:00] <_mup_> Bug #626680: iteration in LP API's is O(N^2) due to batching <api> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/626680>
[20:01]  * gary_poster will get out of way now :-)
[20:01] <leonardr> matsubara: so the problem is the lack of a specific filter on a given dataset, right?
[20:02] <matsubara> leonardr, yep. it's similar to a bug recently fixed in the Bugs API. let me search that one
[20:03] <matsubara> leonardr, https://bugs.launchpad.net/malone/+bug/327688
[20:03] <_mup_> Bug #327688: It should be possible to search bugs given a range of date_created using the API <api> <qa-ok> <ubuntu-qa> <Launchpad Bugs:Fix Committed by brian-murray> <https://launchpad.net/bugs/327688>
[20:04] <matsubara> leonardr, the script I recently worked on is using the getMergeProposals() method but it's not possible to filter the set by a date range or something. so I end up with all the set and have to filter in python by iteration over everything
[20:07] <leonardr> matsubara: thanks
[20:10] <leonardr> gary: although i agree with all the things you want to do on this project, i don't see think streamlining the web service will make this kind of performance improvement drop out. we'd still have to do work to make it possible to filter a set of merge proposals by a range for date_created (or whatever)
[20:10] <leonardr> and then the question is, if our overriding priority is performance, why not just add that to the existing named operations?
[20:11] <leonardr> i think the answer is "because that would make the web service incomprehensible and random, we need to have a plan"
[20:11] <leonardr> and the streamlining gives us a plan
[20:12] <gary_poster> exactly, leonardr
[20:12] <leonardr> ok, then we're in agreement
[20:20] <thumper> lifeless: that oops isn't found
[20:20] <thumper> lifeless: what's it all about?
[20:22] <jml> benji: *hugs*
[20:23] <thumper> james_w: ping
[20:24] <benji> :)
[20:24] <james_w> hi thumper
[20:24] <thumper> james_w: I have a couple of questions about your email re blueprints
[20:24] <thumper> james_w: what do you mean by "read only view"
[20:24] <thumper> ?
[20:25] <james_w> thumper, can I edit e.g. the status of blueprints in the view
[20:25] <thumper> do you think you should be able to?
[20:25] <james_w> if it's a page for team leads to see workload, can they manage that workload from the same place?
[20:25]  * benji is assuming bug 539070 is the source of aformentioned hugs.  If not, he may not want to know. ;)
[20:25] <_mup_> Bug #539070: Unhelpful error on badly declared API export <Launchpad Foundations:In Progress by benji> <https://launchpad.net/bugs/539070>
[20:26] <thumper> james_w: I think first cut it will be read only
[20:26] <thumper> james_w: the blueprint code needs some more yak shaving to allow api exporting
[20:26] <james_w> thumper, I do, but editing in list views is not a pervasive pattern in LP unfortunately, so I don't know how feasible it is
[20:26] <thumper> james_w: which is what we'd really need for editing the status of the blueprints from there
[20:27] <thumper> james_w: it is feasible (I think) if we have the api supported properly
[20:27] <james_w> thumper, I'm intimately acquainted with that tak
[20:27] <james_w> yak
[20:27] <thumper> james_w: however I'm not entirely sure and the scalability of the widgets there
[20:27] <thumper> james_w: I have started shaving the herd of yaks called blueprints
[20:28] <james_w> thumper, you're working on the required model changes?
[20:28] <james_w> (to export)
[20:28] <thumper> james_w: I will be
[20:28] <thumper> but this lep isn't about the api exporting
[20:28] <thumper> that should just come from some of the yak shaving
[20:29] <thumper> I think that we won't be able to filter by series/milestone if just looking on ~team page
[20:29] <thumper> however that should be there when drilled down into pillar or series
[20:31] <james_w> perhaps there could be a date filter at that level?
[20:31] <james_w> based on the dates on the milestones etc?
[20:34] <thumper> hmm...
[20:34] <thumper> that seems like it is trying to be tricky
[20:34]  * thumper wonders if we are going to rename Blueprints back to Specifications at some stage
[20:35]  * thumper quietly ignores the plans to kill blueprints altogether
[20:35] <james_w> it's just that I don't want to have to consult 5 pages and mash them together in my head to work out how much load is on my team in the next N months
[20:44] <thumper> james_w: I think this idea is worth exploring, but we'd have to nut out how to filter effectively across all blueprints
[20:45] <james_w> thumper, indeed, but I'm playing the role of a customer with demanding requirements :-)
[20:45] <thumper> james_w: good, I'm happy with that
[20:45] <thumper> james_w: an interesting question is how to ignore certain blueprints
[20:46] <thumper> james_w: I'm sure flacoste doesn't care about my wikkid blueprints, even if they overlap in time
[20:46] <thumper> james_w: I was wondering if project associations might solve part of that problem in a better way
[20:46] <james_w> thumper, that's true
[20:46] <thumper> james_w: but that still leaves you open to missing something
[20:46] <thumper> as in not seeing a blueprint on a project you haven't currently marked as interesting
[20:47] <thumper> sinzui: we now have a compelling reason for project associations
[20:47] <sinzui> linaro had a pretty strong argument at UDS
[20:48] <thumper> sinzui: do it!
[20:48] <thumper> sinzui: I'd even be prepared to chip in
[20:49] <sinzui> I will just before I delete projectgroups...and make everyone who working on converting projects to project groups weep at the wasted effort
[20:49] <thumper> james_w: I'll be making some mockups for the pages anyway
[20:49] <thumper> james_w: so we'll have something to discuss
[20:49] <james_w> thumper, great, thanks for your work on this
[20:50] <thumper> sinzui: we don't want to delete project groups, just change how they work
[20:50] <thumper> sinzui: as you've said before they are for "control"
[20:51] <sinzui> thumper, I think I want to. I think nested projects solve OEMs 500 skus. It also lets me have bugs and questions on the top level thing (/launchpad for example)
[20:52] <thumper> ah...
[20:52] <thumper> nested projects could be interesting...
[20:53] <thumper> interesting in a way where queries are a PITA
[20:53] <sinzui> I think making OEMs job easier will make Canonical more money and give me job security
[20:54] <leonardr> matsubara, for the record, what kind of object are you calling getMergeProposals on?
[21:05] <thumper> hah
[21:05] <thumper> I just found something really useful in quassel
[21:05] <thumper> if I double click in the chat monitor window, it changes me to that channel
[21:08] <jcsackett> thumper: were you just trying to contact registry in mumble, or was that a mistake?
[21:08] <thumper> jcsackett: I was checking that my mic and sound was working
[21:08] <thumper> jcsackett: did it work?
[21:08] <jcsackett> thumper: it did; i was in the other room and rushed back but you had already moved to code.
[21:08] <sinzui> were you checking for heavy breathing?
[21:08] <thumper> seems to be working now
[21:09] <jcsackett> people always message me when i'm making coffee... :-P
[21:38] <cr3> leonardr, rockstar: regarding the web_link that will be added toDataStructure in the lazr.restful EntryResource, I suppose, shouldn't it be named web_url to avoid using the _link suffix which has a special meaning?
[21:39] <leonardr> cr3: i think it partakes of the same special meaning as _link (it's the web version of self_link). do you think it will actually cause problems?
[21:40] <james_w> would accessing obj.web is launchpadlib cause it to attempt to get a resource from that url?
[21:42] <cr3> leonardr: I don't quite see how web_url is special though, other than it being generated automatically, because _link attributes are used for resolving objects or collections thereof wherewas web_link (or web_url) is just a string with no such resolving
[21:42] <leonardr> cr3: seems like GET would resolve it pretty well
[21:43] <cr3> leonardr: touche, works for me then :)
[21:46] <wallyworld> abentley: rockstar: so you guys will tell me if you need anything done?
[21:46] <abentley> wallyworld: Sure, but probably rockstar or thumper will do more of that than me.
[21:47] <thumper> wallyworld: I'll look over the bugs and we can chat later
[21:47] <wallyworld> abentley: np. just wanted to make sure :-)
[21:47] <wallyworld> ok
[21:47] <rockstar> wallyworld, yeah, we can find some stuff.
[21:47] <wallyworld> you only have 16 days left
[21:47] <rockstar> wallyworld, me?
[21:47] <wallyworld> no i mean you only have 16 days before thumper gets rid of me
[21:48] <cr3> leonardr: I have to admit that one of my concerns was that naming the attribute web_link would require changes to lazr.restfulclient and even client.js, but that's not a real concern, more laziness :)
[21:48] <leonardr> cr3: james_w has a point. we do need to see if it causes problems, and if so either change the client or change the name
[21:48] <leonardr> i don't think we'd need to change client.js, but can you see what happens with lazr.restfulclient?
[21:50] <cr3> leonardr: yes, and it took a moment for me to grasp what james_w meant by obj.web, where the _link suffix gets stripped and treated specially
[21:52] <cr3> leonardr: in that respect, I don't think there's much value in GETing a web_link. as far as api goes, I think that attribute is most likely to be used as a string than a link to be gotten
[21:54] <leonardr> cr3: i don't feel strongly about this. rockstar might have some wisdom from his attempt, and i'd also like benji to weigh in
[21:55]  * benji reads
[21:57] <cr3> leonardr: i don't feel strongly either, mostly sharing gut feeling. I'll be attempting to add web_* myself during my personal time, so I'll share my finding with rockstar if I find a reasonable solution
[21:58] <leonardr> cr3: my gut feeling is siding towards you, but i think it would be nice if it were clear that self_link and web_link were two halves of the same coin
[22:00] <benji> and it'd be nice if accessing .web generated an AttibuteError just as .doesnotexist would, but I don't think that's possible with the current mechanisms
[22:01] <cr3> leonardr: if web_link == re.sub(r"/api/[^/]+/", "/", self_link), I would agree but I can't conceive it web_link being different from self_link in that respect
[22:02] <leonardr> another possibility, which i'm not seriously suggesting, is that .web could actually get you the web page
[22:03] <leonardr> in a mechanize Browser object or something
[22:03] <leonardr> (again, this is just on a conceptual level,. *not* suggesting it, though it might be cool)
[22:08] <cr3> leonardr: personally, I wouldn't be inclined to do that, but I wouldn't be surprised of people using that feature in ways I could not imagine :)
[22:09] <leonardr> cr3, yeah, my point is, urls are urls, there's no fundamental reason why we can't have a tool that dereferences web service urls and non-web-service urls
[22:10] <LPCIBot> Project devel build (183): SUCCESS in 3 hr 32 min: https://hudson.wedontsleep.org/job/devel/183/
[22:10] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=654639,
[22:10] <LPCIBot> 667883] Remove some Python 2.5 compatibility code. Fold edge database
[22:10] <LPCIBot> stats into lpnet database stats.
[22:10] <LPCIBot> * Launchpad Patch Queue Manager: [r=rockstar][ui=none][bug=667342] Bug filing form link will now fill
[22:10] <LPCIBot> in summary and description for Trac external bug trackers.
[22:20] <wgrant> Is buildbot happy after 11825's reversion?
[22:21] <mars> checking
[22:22] <mars> yes, lp db_lp are green
[22:22] <wgrant> Excellent.
[22:23] <wgrant> And Hudson is too.
[22:57] <thumper> I find myself wanting bugs.launchpad.net/~person/project to go to a listing of bugs assigned to person for the project
[22:58] <thumper> rockstar: ping
[22:59] <persia> thumper, Could we also have /project/~person/ ?  That's how I always want to type it.
[22:59] <thumper> persia: no
[22:59] <thumper> at least I won't do that one
[23:00] <persia> Heh, OK :)
[23:05] <rockstar> thumper, pong
[23:06] <thumper> rockstar: these bugs for recipes, are you doing them all in one branch?
[23:06] <thumper> rockstar: if so please add one task to the kanban board for them
[23:06] <rockstar> thumper, yes, because they are all small.
[23:06] <rockstar> thumper, ah, yeah, kanban...
[23:06] <thumper> :)
[23:47] <rockstar> Huh. So, running ec2 land --attached doesn't actually land anything...
[23:47] <rockstar> Also, it doesn't actually send any email.