[00:01] <wgrant> So, I think that non-ML team subscriptions are a bug.
[00:02] <wgrant_> Hah.
[00:05] <sinzui> wgrant: what to you mean by "non-ML team subscriptions"? mailing list subscriptions for teams that one had a mailing list?
[00:05] <thumper> w00t
[00:05]  * thumper does a little dance
[00:06] <thumper> now to just edit the other 200 odd references to LP.client methods in the LP tree
[00:07] <StevenK> wgrant: I saw you discussing my traversal change with Julian. Revert it or keep it?
[00:10]  * StevenK nails wgrant to the channel
[00:12] <StevenK> sinzui: If you look at lib/lp/soyuz/templates/packagepublishing-details.pt, a lot of the status information is in <strong> tags
[00:15]  * thumper does another little dance
[00:16] <sinzui> StevenK: yes. I think that is defeating the purpose of the list.
[00:17] <StevenK> I know that the statuses have been strong for as long as I remember
[00:17] <StevenK> So I'm little nervous changing them
[00:27] <wgrant> They have been strong forever.
[00:27] <wgrant> So there is no reason to keep them.
[00:28] <wgrant> cody-somerville: Is there a reason you can't set a /dev/null email address on ~pmteam?
[00:29] <wgrant> Yellow will be sorting out subscription muting soon, I believe.
[00:29] <StevenK> wgrant: So I should remove all of the strong?
[00:29] <wgrant> And we will be sorting out project permissions a little less soon.
[00:29] <wgrant> StevenK: Except maybe the "pending publication" bit next to builds, yes.
[00:30] <wgrant> StevenK: Someone decided in 2005 that it should be strong, and nobody ever looked at it again.
[00:30] <cody-somerville> wgrant, Is there a bug or blueprint for this change regarding the owner no longer being endowed permissions associated with teams owned?
[00:30] <StevenK> wgrant: I just have this feeling that bigjools will like that change even less
[00:31] <wgrant> cody-somerville: Bug #227494
[00:31] <_mup_> Bug #227494: Do not special case the owner in IPerson.inTeam() <disclosure> <lp-registry> <Launchpad itself:Triaged> < https://launchpad.net/bugs/227494 >
[00:31] <lifeless> is bug 181401 fixed?
[00:31] <_mup_> Bug #181401: push to lp:project or lp:project/series should to set the development focus and/or create the series <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/181401 >
[00:32] <wgrant> lifeless: I've seen breakage which suggests that it is.
[00:34] <lifeless> wgrant: sinzui: also bug 191870
[00:34] <_mup_> Bug #191870: Participation in a team as the owner is non-obvious <lp-registry> <registry> <Launchpad itself:Triaged> < https://launchpad.net/bugs/191870 >
[00:34] <lifeless> bug 206058
[00:34] <_mup_> Bug #206058: Team Administrators cannot change their membership expiration date <lp-registry> <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/206058 >
[00:34] <lifeless> bug 409241
[00:34] <_mup_> Bug #409241: Team member listings show "Owner" as "Administrator" <lp-registry> <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/409241 >
[00:34] <lifeless> bug 539903
[00:34] <_mup_> Bug #539903: Team Owner seems to show ownership, should show leadership - or options <lp-registry> <needs-decision> <team-roles> <teams> <Launchpad itself:Triaged> <loco-directory:Fix Released by chrisjohnston> < https://launchpad.net/bugs/539903 >
[00:34] <wgrant> I had all of those open somewhere, but tooooo many tabs :/
[00:35] <wgrant> Bug #409241 should be fixed by allowing administrators to bless people as administrators, I think.
[00:35] <_mup_> Bug #409241: Team member listings show "Owner" as "Administrator" <lp-registry> <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/409241 >
[00:36] <lifeless> also https://bugs.launchpad.net/launchpad/+bug/669643/comments/2 was relevant to this discussion
[00:36] <_mup_> Bug #669643: Avoid extra queries by making inTeam() accept an ID <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/669643 >
[00:38] <wgrant> Admins separate is a good idea, but requires reworking TeamMembership (in a good way... but it's a bit of work)
[00:38] <StevenK> wgrant: I'd appreciate a second pair of eyes: http://pastebin.ubuntu.com/570855/
[00:39] <StevenK> wallyworld_: BAH! Why do you have four things in QA-Landing and QA-In process?
[00:41] <wallyworld_> StevenK: some of the qa in progress things can be moved across. the qa was done this morning and/or last night. i haven't got it moving the cards yet
[00:41] <wgrant> StevenK: Well, that appears to be a lie.
[00:41] <StevenK> wgrant: Exactly. :-(
[00:41] <wallyworld_> StevenK: the landing stuff is waiting on ec2 and/or buildbot
[00:42] <StevenK> wallyworld_: There's nine cards there, and I have a card in Coding-Review that I'd to move.
[00:42]  * wallyworld_ looks
[00:42] <StevenK> Sorry, eight
[00:42] <StevenK> wgrant: Even 'print expected_contents in contents
[00:42] <StevenK> ' gives False :-(
[00:44] <wallyworld_> StevenK: i've moved 2 cards from QA to deployment ready. the board was only a few hours out of date.
[00:45] <StevenK> wallyworld_: Thanks
[00:46] <wallyworld_> StevenK: np. sorry for the delay. the 2 cards in progress are being done in the one branch. if only ec2/bb didn;t take 8 hours end-end stuff wouldn't have to langusih in the Landing section for so long
[00:47] <StevenK> wallyworld_: It would be okay if you didn't have four things going at once. :-)
[00:48] <wallyworld_> StevenK: what i do is, i push stuff to ec2, start a new branch, get that done, ask for a review, and while waiting for that, start a new branch etc. so it's all pipelined...
[00:49] <wallyworld_> StevenK: and if ec2 takes a while and/or you're waiting for a particular person to review of whatever, you may as well start a new branch
[00:50] <StevenK> It's been ending up that I've been tossing branches at ec2 and then EODing
[00:50] <lifeless> StevenK: your mp commit message is naffed
[00:50] <StevenK> lifeless: Which one?
[00:50] <lifeless> just got the mail on the chnage
[00:51] <lifeless> is now just [r=][bug=]
[00:51] <lifeless> deleted the message already
[00:51] <StevenK> lp-land, you fail
[00:52] <StevenK> Commit message [[r=stub][bug=713518] SourcePackageRecipe.description is now optional.]
[00:52] <StevenK> However, we're in testfix anyway
[00:53] <StevenK> test_404 and test_oldurl failed again
[00:53] <wgrant> I still have not managed to reproduce those locally.
[00:58] <StevenK> wgrant: Can you have another look at https://code.launchpad.net/~stevenk/launchpad/link-recipe-on-ppa-page/+merge/50694 ?
[00:58] <StevenK> wgrant: I've addressed all of your concerns, removed the strong like sinzui suggested
[00:59] <wgrant> StevenK: Looking.
[00:59] <StevenK> PQM, you fail.
[00:59] <wgrant> What has it done now?
[01:00] <StevenK> wgrant: If we're in testfix the body of the mail says:
[01:00] <StevenK> Command failed!
[01:00] <StevenK> running 0 tests...
[01:00] <wgrant> Yes,
[01:00] <wgrant> but the attachments say more.
[01:00] <StevenK> And then you need to read the two gzip'd attachments
[01:00] <StevenK> And Thunderbird hates gzip
[01:00] <StevenK> :-(
[01:02] <wgrant> StevenK: Could you put some linebreaks in that TAL?
[01:02] <wgrant> Also that span is redundant.
[01:02] <wgrant> Put tal:content="sprb/recipe/name" on the a.
[01:02] <wgrant> Same with the other one.
[01:03] <StevenK> wgrant: <a tal:attributes="href sprb/recipe/fmt:url" tal:content="sprb/recipe/name" /></a> ?
[01:04] <wgrant> StevenK: That. You may also be able to self-close the a.
[01:04] <StevenK> I already have />, so maybe that is sufficent.
[01:05] <StevenK> Vim disagrees.
[01:06] <wgrant> Ah, so you do.
[01:06] <wgrant> You can't have both that and the </a>, obviously.
[01:12] <StevenK> wgrant: Linebreaking the tal makes me sad, since it makes my naive string matching break.
[01:12] <wgrant> StevenK: Whitespace normalisation is cool.
[01:13] <StevenK> Which I can't figure out how to do with a string
[01:13] <wgrant> Matchers don't have such a facility?
[01:14] <StevenK> I have no idea
[01:18] <lifeless> StevenK: DocTestMatcher(...doctest.ELLIPSIS)
[01:18] <lifeless> and in your reference, use '...'
[01:18] <lifeless> -or-
[01:18] <lifeless> use soupmatchers
[01:19] <wgrant> Doctests have whitespace normalisation, not just ellipsis... does DocTestMatcher not do that?
[01:19] <lifeless> it doesn't set any flags by defailt
[01:20] <lifeless> just set the flag you want
[01:20] <wgrant> Ah, handy.
[01:21] <wgrant> cody-somerville: Still around?
[01:21] <lifeless> so matcher=DocTestMatches('foo bar', NORMALIZE_WHITESPACE)
[01:22] <lifeless> StevenK: ^
[01:25] <StevenK> lifeless: Which gives AttributeError: 'str' object has no attribute 'match'
[01:25] <StevenK> lifeless: Since what I'm comparing to is just a string
[01:27] <lifeless> StevenK: self.assertThat(yourstring, DocTestMatches('foo bar', doctest.NORMALIZE_WHITESPACE)
[01:27] <lifeless> )
[01:28] <lifeless> StevenK: or paste your code so that I'm not making random guesses ;)
[01:29] <StevenK> lifeless: http://pastebin.ubuntu.com/570869/
[01:30] <lifeless> StevenK: so a small style thing that made me wtf when I read this
[01:30] <lifeless> StevenK: a matcher isn't static, its an active object
[01:31] <lifeless> so calling one expected_contents is mind wrenching
[01:31] <StevenK> lifeless: A small note: I've never used matchers before
[01:32] <lifeless> I would probably create the string separately
[01:32] <StevenK> lifeless: Renamed to recipe_matcher
[01:32] <lifeless> expected_contents = '...'
[01:32] <lifeless> browser =
[01:32] <lifeless> self.assertThat(browser.contents, DocTestMatches(expected_contents, NORMALIZE_WHITESPACE))
[01:32] <lifeless> or rename it as you have, that fine too
[01:33] <lifeless> ok, and is it still giving you this error ?
[01:33] <StevenK> Yes, because the newlines aren't ignored
[01:33] <lifeless> it might be clearer to read if you put the doctest.NORMALIZE_WHITESPACE left alighted with the '<a href'
[01:34] <lifeless> http://docs.python.org/library/doctest.html#doctest.NORMALIZE_WHITESPACE
[01:34] <lifeless> StevenK: you said it was giving you a str has not attribute error
[01:34] <lifeless> is that resolved?
[01:35] <wgrant> jam: Around?
[01:35] <StevenK> Yes, if the string is first in assertThat, it's fine
[01:35] <lifeless> >>> print DocTestMatches('foo\nbar').match('foo bar')
[01:35] <lifeless> <testtools.matchers.Mismatch object at 169b950 attributes={'matcher': <testtools.matchers.DocTestMatches object at 0x7f3b8471fd50>, 'with_nl': 'foo bar\n'}>
[01:35] <lifeless> >>> print DocTestMatches('foo\nbar', NORMALIZE_WHITESPACE).match('foo bar')
[01:35] <lifeless> None
[01:36] <lifeless> StevenK: ^ works for me
[01:36] <lifeless> StevenK: paste the error you get
[01:37] <StevenK> Oh, sure, let me just edit the tal to inclue 'foo bar' and all my problems will be solved. :-P
[01:37] <lifeless> StevenK: oh, and a tiny tweak - s/recipe_matcher/recipe_matches/
[01:37] <lifeless> the intent is to be able to read the assertion as a sentence
[01:37] <StevenK> lifeless: http://pastebin.ubuntu.com/570870/
[01:38] <lifeless> StevenK: you're comparing totally different things
[01:39] <lifeless> the matchee is the entire portlet
[01:39] <lifeless> the thing you're matching against is a tiny fragment of that
[01:39] <StevenK> Now I guess, that the matcher is expecting the content to be exactly what I want, but I only care that the string is in browser.contents
[01:39] <lifeless> right
[01:39] <lifeless> so for that, you need ELLIPSIS
[01:39] <lifeless> -or- to use soupmatches, which is structured and much better for this sort of thing
[01:39] <lifeless> anyhow
[01:39] <lifeless> add
[01:40] <lifeless> ... at the start and end of your expected text
[01:40] <lifeless> and add | ELLIPSIS
[01:40] <lifeless> to the flags
[01:41] <StevenK> lifeless: My issue with soupmatchers was I wasn't sure how to add the free-form text into the mix, such as 'by recipe'
[01:41] <lifeless> james_w: ^
[01:43] <wgrant> lifeless: Could you please mentor https://code.launchpad.net/~stevenk/launchpad/less-lazr-security/+merge/50824?
[01:43] <lifeless> looking at it already
[01:43] <lifeless> if I get a test timeout in ec2
[01:43] <lifeless> but no other errors
[01:43] <lifeless> does that suggest my changes are ok ?
[01:43] <wgrant> lifeless: Windmill layers tend to run late in the suite.
[01:43] <wgrant> But not necessarily right at the end.
[01:44] <wgrant> It suggests that are OK, but does not prove anything.
[01:44] <wgrant> I would retest.
[01:44] <wgrant> Unless the changes are really simple.
[01:44] <lifeless> ttps://code.launchpad.net/~lifeless/launchpad/bug-717394-3/+merge/50546
[01:45] <wgrant> Eeeh. I'd retest.
[01:45]  * StevenK switches back to soupmatchers
[01:45] <wgrant> You never know what bad things people are doing.
[01:45] <lifeless> StevenK: so the ... and ELLIPISIS at the start and end will work
[01:46] <lifeless> StevenK: if soupmatchers isn't easy to approach, just do the ... for now
[01:46] <StevenK> But they didn't ...
[01:46] <lifeless> pastebin
[01:46] <lifeless> both your new code
[01:46] <lifeless> and the new error
[01:46] <StevenK> Too late was the cry as the ship went down?
[01:47] <StevenK> lifeless: I had the soupmatchers code in my undo history, so I've switched back to it
[01:47] <lifeless> StevenK: the doctest matcher is in your pastebin
[01:47] <lifeless> ;)
[01:48] <StevenK> Yes, I'm fixing it without your help :-P
[01:48] <StevenK> And fixed!
[01:48] <lifeless> cool
[01:48] <lifeless> what does it look like with soupmatchers?
[01:48] <StevenK> I'd like to also check that the strings 'by recipe' and 'for' appear in the right place, but I don't know how to put them in
[01:49] <StevenK> lifeless: http://pastebin.ubuntu.com/570872/
[01:50] <StevenK> lifeless: Sadly, I agree with your less-lazr-security comment.
[01:51] <StevenK> thumper: Ping
[01:51] <lifeless> HTMLContains
[01:52] <lifeless> StevenK: ^ looks like what you need to get the by recipe and for bits evaluated
[01:52] <lifeless> HTMLContains(Equals('by recipe'))
[01:52] <StevenK> Equals is from testtools.matchers?
[01:52] <lifeless> yes
[01:52] <StevenK> And where did you see that pattern?
[01:53] <lifeless> I read the pydoc for soupmatches
[01:53] <lifeless> and am guessing
[01:53]  * StevenK tries it
[01:53] <lifeless> http://bazaar.launchpad.net/~soupmatchers-dev/soupmatchers/trunk/annotate/head:/README
[01:54] <StevenK> Actually, Equals() might just do it by itself
[01:54] <StevenK> Since it has a .match() attribute
[01:54] <StevenK> Er, method
[01:54] <lifeless> yes, Equals is a matcher
[01:54] <lifeless> as is Not
[01:54] <lifeless> RaisesException
[01:54] <lifeless> and so on
[01:54] <lifeless> StevenK: actuall
[01:55] <lifeless> the readme suggests
[01:55] <lifeless> Tag("...", text="built for") or some such
[01:55] <lifeless> might want to wrap your entire bit in a span or something. I suggest reading the readme
[01:56] <StevenK> I have, twice
[01:56] <lifeless> does text= not meet your needs?
[01:56] <StevenK> I haven't tried it
[01:56] <lifeless> ok
[01:57] <StevenK> Oh, no tagname or attrs, just text=''
[01:58] <StevenK> soupmatchers.Tag('first text', text='by recipe'),
[01:58] <StevenK> TypeError: __init__() takes at least 3 non-keyword arguments (2 given)
[02:02] <StevenK> lifeless: I've just read the README again and couldn't distill any clues about matching plain text
[02:02] <lifeless> StevenK: well its not entirely plain i sit? its embedded in an html structure
[02:02] <lifeless> so you need to match the containing span
[02:03] <lifeless> or try equals
[02:03] <lifeless> or do the doctestmatches thing - personally I'd do that simply to get unstuck and moving
[02:03] <StevenK> Equals() didn't work and neither did HTMLContains(Equals())
[02:04] <StevenK> lifeless: I can just not check for the text and the test passes. I'd just like to actually check it
[02:04] <huwshimi> lifeless: When you've got a chance I'd like to figure out how to land my Loggerhead changes.
[02:05] <StevenK> lifeless: Oh, further to your shipit comment: That will turn up during the test suite?
[02:05] <wgrant> StevenK: It will, and it won't break.
[02:06] <lifeless> ec2 land will run the shipit tests
[02:06] <wgrant> ShipIt doesn't use those bits.
[02:08] <lifeless> wgrant: any idea how we can qa Bug 720826 ?
[02:08] <_mup_> Bug #720826: Add subscription description header for bug notifications <qa-needstesting> <story-better-bug-notification> <Launchpad itself:In Progress by danilo> < https://launchpad.net/bugs/720826 >
[02:09] <lifeless> \o/ bug down down by 70 queries on prod
[02:09] <lifeless> vs prod I mean
[02:10] <lifeless> 4.42 seconds hot on staging!
[02:10] <lifeless> booyha
[02:14] <thumper> StevenK: pong
[02:17] <wgrant> Why does strucsub live in Bugs now? :/
[02:18] <lifeless> because it was started as a bugs project
[02:18] <lifeless> before the desiloisation of teams
[02:18] <wgrant> Yes.
[02:18] <wgrant> But it lived in Registry.
[02:18] <wgrant> Then was moved to Bugs post-desiloisation.
[02:18] <lifeless> by folk already fixed in the bugs silo - its only future work I really expect this to change
[02:19] <lifeless> anyhow, registry is equally wrong ;) <domain> is wrong :)
[02:19] <StevenK> thumper: Are you fine with me landing a branch that pulls in lazr.restful 0.17.1?
[02:20] <thumper> there is a 0.17.1?
[02:20] <StevenK> thumper: IE: It won't break anything, or I should wait until your work lands?
[02:20] <thumper> StevenK: it makes no difference AFAIK if you land it now
[02:20] <thumper> StevenK: mine just builds on new features
[02:21] <thumper> StevenK: what is the update in 0.17.1?
[02:21] <StevenK> thumper: It adds a test, that's it.
[02:21] <StevenK> So I can remove it from the Launchpad tree.
[02:22] <thumper> ah...
[02:22] <thumper> that's fine with me
[02:22] <thumper> land it
[02:22] <StevenK> Doing so
[02:22] <thumper> I'll deal with the merge conflicts
[02:22] <StevenK> thumper: My recipe description DROP NOT NULL fix should have hit db-devel, too
[02:23] <wgrant> lifeless: That's qa-ok. The UI really sucks, but it works.
[02:23] <wgrant> And it's not linked.
[02:25] <wgrant> Which means we only need that pofilestats thing.
[02:25] <wgrant> And I think we can probably OK that, since apparently it's broken on production anyway and no more broken now.
[02:28] <thumper> how can I quickly record a screen cast?
[02:29] <thumper> StevenK: did you test the UI?
[02:29] <thumper> StevenK: do you know if required defaults to True, or False ?
[02:30] <thumper> StevenK: I have a feeling it defaults to True
[02:30] <huwshimi> thumper: I've used 'gtk-recordmydesktop' in the past with success
[02:33] <thumper> huwshimi: ta
[02:35] <huwshimi> thumper: It's worth noting that it will record sound out of your mic unless you uncheck the sound option (great if you want to narrate it, not so great if you are talking to yourself).
[02:35] <thumper> huwshimi: hmm... where did it save it?
[02:36] <huwshimi> thumper: Home folder?
[02:37] <lifeless> huwshimi: hi
[02:37] <thumper> yep
[02:37] <huwshimi> lifeless: Hello.
[02:37] <lifeless> huwshimi: uhm, propose them, get them reviewed, and land manually if its on trunk
[02:37] <lifeless> running the test suite, of course
[02:38] <thumper> Behold the magic! http://people.canonical.com/~tim/js-update.ogv
[02:38] <huwshimi> lifeless: OK, so should I just try to get my changes landed directly to trunk?
[02:38] <thumper> And the code: http://pastebin.ubuntu.com/570890/
[02:38] <thumper> \o/
[02:38] <wgrant> thumper: Yay, that fixes two bugs I filed.
[02:38]  * thumper takes a bow
[02:38] <wgrant> That is awesome.
[02:38] <wgrant> And needs to be applied everywhere.
[02:39] <thumper> wgrant: yes. yes it does
[02:39] <thumper> I'll be emailing the list
[02:39] <thumper> wgrant: which two bugs?
[02:39] <lifeless> huwshimi: that was the conclusion from my discussions with poolie and jml: that we'll go with one theme for loggerhead upstream & lp, make it nice for standalone or lp users
[02:39] <thumper> wgrant: check out the underlying code :)
[02:39] <lifeless> huwshimi: for things that we need to be lp specific we'll need to add callbacks inside loggerhead that can call into the launchpad_loggerhead stuff
[02:39] <lifeless> wgrant: Bug 722568 needs a losa doesn't it ?
[02:39] <_mup_> Bug #722568: Empty TranslationMessages confuse stats <qa-needstesting> <Launchpad itself:Fix Committed by jtv> < https://launchpad.net/bugs/722568 >
[02:40] <wgrant> thumper: Ah, I put both in one. Bug #721064.
[02:40] <_mup_> Bug #721064: Inline recipe text editor doesn't update the "Debian version" field on the page <recipe> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/721064 >
[02:40] <StevenK> thumper: That's awesome
[02:40] <huwshimi> lifeless: OK. I have one change that is LP specific. What should I do with it? Remove it for now?
[02:40] <lifeless> huwshimi: what is it
[02:40] <StevenK> wgrant: Can you look at link-recipe-on-ppa-page again?
[02:40] <wgrant> lifeless: Yes, but it's already broken on production.
[02:40] <thumper> StevenK: which one?
[02:41] <thumper> StevenK: link
[02:41] <thumper> ?
[02:41] <lifeless> wgrant: well it runs with incorrect results sometimes
[02:41] <lifeless> wgrant: thats not totally broken, and the change might totally break it in theory
[02:41] <lifeless> wgrant: so I think wait for losa
[02:41] <huwshimi> lifeless: it's a backlink to the branch summary page in Launchpad, and labelled specifically so.
[02:41] <wgrant> lifeless: No, it crashes.
[02:41] <StevenK> thumper: The screencast looks awesome
[02:41] <lifeless> wgrant: orly? I thought that was staging only that crashes
[02:42] <wgrant> lifeless: That's what we thought too.
[02:42] <wgrant> lifeless: But check carob:/srv/launchpad.net-logs/scripts/loganberry/rosetta/pofile-stats.log-20110217
[02:42] <wgrant> People became aware of this after we were both asleep, I believe.
[02:42] <wgrant> thumper: How many requests does it need?
[02:43] <thumper> wgrant: there is only one patch request
[02:43] <wgrant> thumper: Or does it request all the relevant representations?
[02:43] <wgrant> Nice.
[02:43] <thumper> wgrant: lazr.restful was updated to return the full entry info + html
[02:43] <wgrant> thumper: The duplication sort of sucks, though.
[02:43] <thumper> wgrant: I'm fixing the duplication
[02:43] <lifeless> huwshimi: you should make that configurable in some way (we can talk about how to do that separately); land it with it configured to not show, and change launchpad_loggerhead in the launchpad tree to make it show when we deploy
[02:44] <wgrant> thumper: Great.
[02:44] <wgrant> thumper: So, one line per field for dynamic updates? That is fantastic.
[02:44] <lifeless> huwshimi: we want to end up running a stock loggerhead with (conceptual) plugins to it, rather than a patched loggerhead, to reduce engineering overheads
[02:44] <wgrant> I like AJAX that is not fucking painful to code.
[02:45] <lifeless> thumper: this lazr.restful change
[02:45] <lifeless> thumper: its optional, right ?
[02:45] <thumper> lifeless: optional in which way?
[02:45] <lifeless> server side generation of the html
[02:45] <lifeless> thumper: I mean, launchpadlib api requests shouldn't trigger it
[02:45] <thumper> not unless they ask for it
[02:45] <wgrant> I presume the client can pass multiple Accepts.
[02:45] <thumper> actually...
[02:45] <lifeless> because its fantastically slow by comparison to just a json dict
[02:45] <lifeless> *fantastically slow*
[02:45] <thumper> no I don't think launchpadlib gets it
[02:46] <lifeless> cool
[02:46] <lifeless> nice work
[02:46] <thumper> you have to specify Accept: application/json;include=lp_html
[02:46] <huwshimi> lifeless: OK great. So, how to make it configurable?
[02:46] <wgrant> Excellent.
[02:46] <lifeless> huwshimi: How does it work?
[02:46] <wgrant> thumper: It might be nice if you could specify particular fields.
[02:46] <wgrant> But this shouldn't be too bad.
[02:47] <thumper> wgrant: we specifically only do one event for the change to avoid race conditions
[02:47] <lifeless> wheeee
[02:47] <wgrant> thumper: btw, do you know what's up with the empty grid cell on recipe pages?
[02:47] <lifeless> 11 seconds python time - wtf
[02:47] <thumper> wgrant: each page could break it apart more easily
[02:47] <lifeless> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1880QS43
[02:47] <wgrant> Above "Debian version"
[02:47] <thumper> wgrant: yes
[02:47] <thumper> wgrant: it has to do with the yui grid flow
[02:48] <wgrant> thumper: Easily fixable?
[02:48] <thumper> wgrant: if the height of the top left is greater than the height of the top right, then the next one is below right
[02:48] <wgrant> Ah :/
[02:48] <thumper> yui grid layout is deprecated
[02:48] <thumper> huwshimi will fix :)
[02:48] <wgrant> Hopefully before they are out of beta.
[02:48] <wgrant> They want to look awesome before they are pushed out to everyone.
[02:49] <wgrant> lifeless: Wow. I hope that's just asuka being crap.
[02:49] <huwshimi> thumper: I'll do what now? If it's to do with positioning I'm not help you :)
[02:51] <lifeless> wgrant: look at query 20
[02:51] <wgrant> lifeless: You are blocking QA now :P
[02:51] <wgrant> Awesome.
[02:51] <wgrant> That is really awesome.
[02:51] <lifeless> wgrant: not at all, I've been qaing it
[02:52] <wgrant> Also, WTF.
[02:52] <wgrant> thumper: No inline name editing :(
[02:53] <thumper> wgrant: it is coming
[02:53] <wgrant> !
[02:53] <wgrant> No inline series editing :(
[02:53] <thumper> wgrant: I wanted my fix for the auto-url change
[02:53] <thumper> wgrant: series editing needs more work
[02:53] <wgrant> :(
[02:53] <huwshimi> lifeless: In the templates there are links (in a few templates). That's pretty much it. E.g. lines 19-25 of http://bazaar.launchpad.net/~huwshimi/loggerhead/launchpad-theme/view/head:/loggerhead/templates/changelog.pt
[02:53] <thumper> as we don't have any reasonable selectors
[02:53] <wgrant> thumper: Oh?
[02:53] <wgrant> thumper: Can't it just be a form like the build request one?
[02:54] <lifeless> huwshimi: how are you calculating the link
[02:54] <huwshimi> lifeless: The link already existed.
[02:54] <lifeless> huwshimi: you have a condition there already
[02:55] <huwshimi> lifeless: We already had a backlink, but now it's more obvious
[02:55] <lifeless> huwshimi: I suggest running it up standalone and seeing if the links already hide themselves automatically
[02:55] <huwshimi> lifeless: They do
[02:55] <lifeless> huwshimi: so that seems fine for trunk
[02:55] <lifeless> its data driven
[02:56] <lifeless> and $otherdeployment of loggerhead can inject their own branch_link attribute
[02:57] <huwshimi> lifeless: Ok, well I'll put together an MP then. Thanks
[02:59] <thumper> wgrant: probably, but that makes it not a simple patch selector...
[02:59] <thumper> wgrant: I'll look at it
[02:59] <thumper> wgrant: it'd be good to be able to change everything
[02:59] <lifeless> ok, 37 /  407  POFile:+translate wasn't librarian, its up again
[02:59] <lifeless> 16 /   11  Archive:+copy-packages
[02:59] <lifeless> etc
[02:59] <lifeless> I'll go bug filing spree
[03:00] <lifeless> I think a lot are GIL issues, we'll see when the ppr refreshes in a few hours
[03:00] <wgrant> thumper: That page is just so close to being a perfect model for everything else.
[03:00] <wgrant> thumper: It seems sad to leave one thing un-AJAXed.
[03:01] <wgrant> +copy-packages already has a bug.
[03:01] <lifeless> wgrant: I know
[03:02] <lifeless> but first, stuff
[03:02] <thumper> rockstar: check this out: http://people.canonical.com/~tim/js-update.ogv
[03:02]  * thumper sighs
[03:02] <thumper> rockstar: should have been in the other channel, but my client can be dumb
[03:19] <StevenK> wgrant: O hai? You missed my prod?
[03:19] <wgrant> StevenK: Got distracted, looked a couple of minutes ago. Just one more formatting issue that I am looking for pretty solutions to.
[03:20] <StevenK> wgrant: And there's the issue of the traversal.  Leave it.
[03:22] <StevenK> I don't think I can land it with his "Needs Fixing"
[03:22] <lifeless> sure you can
[03:23] <StevenK> Fair enough.
[03:24] <wgrant> Most side reviewers do not rescind their Needs Fixing.
[03:24] <wgrant> StevenK: Reviewed.
[03:26] <StevenK> wgrant: Your diff is wrong, it's sprb.requester, and that pushes it over the length limit
[03:26] <wgrant> StevenK: Look a few lines earlier.
[03:27] <StevenK> Bleh
[03:28] <StevenK> wgrant: Then why is text still sprb.requester.displayname? :-)
[03:28] <wgrant> StevenK: Because I didn't notice that one because its formatting didn't suck!
[03:28] <wgrant> pls fix
[03:28] <StevenK> wgrant: As you keep saying to me: SILENCE!
[03:28] <wgrant> That's the one.
[03:29] <StevenK> wgrant: http://pastebin.ubuntu.com/570905/
[03:29] <StevenK> Er, ignore the lack of context at the end of the diff, my mouse ate it
[03:30] <lifeless> StevenK: how many instances can you reliabilty bring up in jenkins on our test cloud
[03:30] <wgrant> Looks good.
[03:30] <wgrant> Thanks.
[03:30] <StevenK> lifeless: I have no idea. Why?
[03:30] <lifeless> thinking about parallel testing
[03:30] <StevenK> Er?
[03:31] <lifeless> we can trivially multi machine parallel test on jenkins
[03:31] <wgrant> So we disable Windmill, move to Jenkins, and have things in stable in 30 minutes? :)
[03:31] <StevenK> lifeless: Parallel test what, exactly?
[03:31] <StevenK> I'm still confused.
[03:32] <lifeless> lp
[03:33] <lifeless> if we provide a fractional filter to run 1/M tests
[03:33] <lifeless> and start up M machines
[03:36] <StevenK> lifeless: 1: We can't use the UEC if we move to Jenkins to prod usage. 2: I'm not certain how many instances I can run in parallel
[03:36] <lifeless> we can't ?
[03:37] <StevenK> No
[03:37] <StevenK> elmo forbids it.
[03:37] <lifeless> oh
[03:37] <lifeless> did he say why?
[03:38] <StevenK> Yes. It's used by everyone who has an account, and there are no resource limits available on our UEC currently, which means we can get 'locked out'
[03:41] <StevenK> lifeless: When you get undistracted, can has another look at https://code.launchpad.net/~stevenk/launchpad/link-recipe-on-ppa-page/+merge/50694 ?
[03:44] <lifeless> isn't it requestor ?
[03:45] <wgrant> It varies.
[03:46] <wgrant> I've seen both, and I don't think one is particularly American :(
[03:47] <lifeless> small style thing
[03:47] <lifeless> optionak
[03:47] <lifeless> bt I'd indent the <a ... lines in tal
[03:47] <lifeless> if you look at the other <li> regions that is done there
[03:48] <huwshimi> lifeless: For the loggerhead review it will be a Launchpad dev who does it, right? So should I just ask here?
[03:49] <lifeless> huwshimi: yes, normal process - request on the project, ask the OCR here
[03:49] <lifeless> huwshimi: that applies for *everything* listed on launchpad.net/launchpad-project
[03:50] <huwshimi> lifeless: Right, got it. Thanks
[03:50] <StevenK> lifeless: Done locally, anything else?
[03:50] <wgrant> I suppose I should take an OCR slot.
[03:50]  * wgrant takes an OCR slot.
[03:50] <StevenK> \o/
[03:50] <lifeless> StevenK: i commect on the mp
[03:51] <huwshimi> StevenK: A review if you can: https://code.launchpad.net/~huwshimi/loggerhead/launchpad-theme/+merge/50863
[03:52] <StevenK> lifeless: So, file a bug saying IPerson.getPPAByName() has to die or be fixed?
[03:53] <StevenK> huwshimi: You know we have a branch limit of 800 lines, right? :-)
[03:53] <StevenK> But, uh, lots of CSS
[03:53] <StevenK> huwshimi: Can has screenshot?
[03:54] <huwshimi> StevenK: Oh I did not. I'm not even sure I know what you mean by that.
[03:54] <StevenK> Diff against target: 1415 lines (+606/-636) 10 files modified
[03:54] <StevenK> We prefer that 1415 to be under 800
[03:54] <StevenK> But it is a preference
[03:54] <huwshimi> StevenK: Right
[03:55] <huwshimi> StevenK: Would you like me to do something about that?
[03:55] <StevenK> huwshimi: No, it's fine. As you say, it's a massive CSS cleanup.
[03:56] <huwshimi> StevenK: Screenshot coming up. Actually how do I (can I?) push to people/~huwshimi
[03:57] <StevenK> huwshimi: scp to people.canonical.com:public_html
[03:57] <huwshimi> StevenK: Great thanks
[03:57] <lifeless> StevenK: it will depend on what the fix for 'ppas are only for ubuntu' is
[03:57] <StevenK> huwshimi: As an employee, you ought to have access.
[03:57] <StevenK> lifeless: I suspect derived distributions will also grow PPAs
[03:57] <lifeless> StevenK: for instance, we could say that a ppa called 'testtools' can *either* be for Ubuntu
[03:57] <lifeless> *or* for Linaro
[03:57] <lifeless> which would leave that API completely safe to use.
[03:58] <lifeless> or we could say that the various suites in a PPA can extend across any support distro in LP
[03:58] <lifeless> or we could support multiple ppas with the same name on a person, and different distros.
[03:58] <StevenK> My thought is that if the distribution is not in the URL, it's Ubuntu, and if it is, it's that.
[03:58] <lifeless> I think its prejudging it to decide that that API is a problem.
[03:59] <wgrant> One thing we need to say is that this is going to be the last solution.
[03:59] <wgrant> Because every previous one has been designed ignoring everything except the immediate issue.
[03:59] <StevenK> huwshimi: You *might* need to ssh into people.canonical.com first and 'mkdir public_html'
[04:00] <StevenK> wgrant: Then you file a bug? :-)
[04:08] <StevenK> wgrant: Did you file a bug, or shall I?
[04:10] <wgrant> StevenK: I didn't. I'm not sure it needs one.
[04:10] <StevenK> lifeless seems to think so.
[04:11] <lifeless> erm
[04:11] <lifeless> 16:59 < lifeless> I think its prejudging it to decide that that API is a problem.
[04:11] <lifeless> did that get through ?
[04:11] <StevenK> Yes
[04:11] <wgrant> I think it should be left to the design work next week.
[04:11] <lifeless> You *can* file a bug if you agree with julian that that api is a problem.
[04:11] <wgrant> The issue is going to be clear as soon as someone goes near multi-distro PPAs.
[04:11] <wgrant> So a bug does not add very much at all.
[04:11] <wgrant> Particularly as it cannot recommend a solution, nor indeed clearly identify the problem.
[04:12] <lifeless> there's at least 4 different answers to the question 'what should ppas interaction with linaro be'
[04:12] <lifeless> the api isn't a problem today
[04:12] <lifeless> it might be a problem in the future
[04:13] <StevenK> It, and others *will* be when we want to add PPAs for distributions that aren't Ubuntu.
[04:14] <StevenK> Significant parts of Soyuz are coded in such way to blithely believe that the only thing we ever build for and publish for is Ubuntu.
[04:15] <lifeless> hang on
[04:15] <lifeless> those are unrelated assertions
[04:15] <wgrant> StevenK: No, they actually aren't, but anyway.
[04:15] <lifeless> StevenK: nothing says one PPA can't be for both linaro and ubuntu
[04:16] <lifeless> StevenK: similarly, nothing says we have to permit a PPA name to be shared across distros
[04:16] <lifeless> which would equally leave that API safe
[04:17] <StevenK> Right, I'll land it, and won't file a bug. wgrant, Julian and I are aware of the issues surrounding multi-distro PPAs
[04:19] <wgrant> And anybody who tries to do multi-distro PPAs will become aware very rapidly.
[04:28] <wgrant> :( KDE's bugzilla lies.
[04:28] <wgrant> It says it uses P1 through P5 as priorities.
[04:28] <wgrant> But some of the bugs have priority 'NOR'...
[04:31] <lifeless> jml: https://dev.launchpad.net/LEP/ParallelTesting
[04:31] <lifeless> wgrant: fun
[04:47] <StevenK> thumper: Can has review of my review: https://code.launchpad.net/~huwshimi/loggerhead/launchpad-theme/+merge/50863
[04:50] <lifeless> huwshimi: nice
[04:50] <StevenK> I think it looks brilliant
[04:52] <StevenK> lifeless: Did Launchpad lose it's picture?
[04:52] <StevenK> In the top left corner of https://launchpad.net/launchpad , that is
[04:53] <huwshimi> lifeless: It's a start. Just need someone to make it part of Launchpad proper now :)
[04:54] <lifeless> huwshimi: it has an ajax api
[04:54] <wgrant> That's a nice start.
[04:54] <lifeless> huwshimi: I don't think we want to fold the code into LP; we do want it to be better integrated
[04:54] <lifeless> less of a box-of-bits feeling to ut.
[04:54] <lifeless> *it*
[04:54] <lifeless> StevenK: no, its there for me.
[04:54] <huwshimi> lifeless: Yeah, agreed
[04:55] <lifeless> one think I'd like to do is folk the loggerhead api into the main website urlspace
[04:55] <lifeless> so that we can use it without cross domain stuff
[04:55] <lifeless> s/folk/fold
[04:56] <StevenK> lifeless: You're using Chrome, and I'm using Firefox. This may be related.
[04:57] <wgrant> StevenK: Works OK for me in both.
[04:57] <lifeless> StevenK: there for me in ff too
[04:57] <wgrant> Firefox 4b11, though.
[04:57] <lifeless> 3.6.13 for me
[04:57] <wgrant> StevenK: What was it showing?
[04:57] <wgrant> mizuho may be being crap again.
[04:57] <wgrant> It is very good at that.
[04:58] <StevenK> wgrant: Nothing
[04:58] <wgrant> StevenK: What did Firebug say about the image load?
[05:01] <lifeless> wgrant: thanks for prepping the deploy
[05:02] <wgrant> lifeless: I just couldn't let you do two in a row.
[05:02] <wgrant> Or my inbox was crying.
[05:02] <StevenK> Haha
[05:02] <wgrant> One of those.
[05:02] <lifeless> 5.4 million pages yesterday (+ opstats/haproxy)
[05:02] <StevenK> wgrant: How can I tell?
[05:02] <StevenK> I've found the logo <img> in firebug
[05:02] <wgrant> StevenK: There should be a Network tab or something.
[05:02] <wgrant> You don't want the DOM browser.
[05:04] <lifeless> 3M api.*
[05:04] <lifeless> so thats what 60% just on launchpadlib :(
[05:04] <wgrant> lifeless: Do we log users?
[05:05] <lifeless> its determinable somehow
[05:05] <wgrant> I wonder if anyone will notice/complain if I move the security deploy stuff to the bottom of the page in a trivial edit...
[05:05] <lifeless> wgrant: I think that would be fine
[05:06] <StevenK> wgrant: Content-Typetext/html
[05:06] <wgrant> I might also precede it with a \0 to indicate how much I love it.
[05:06] <wgrant> StevenK: Oh dear.
[05:06] <wgrant> StevenK: Which frontend?
[05:06] <wgrant> And which request URL?
[05:07] <wgrant> Length: 2050 (2.0K) [text/html]
[05:07] <wgrant> :(
[05:07] <StevenK> GET /50084288/launchpad-logo HTTP/1.1
[05:07] <StevenK> Host: launchpadlibrarian.net
[05:07] <wgrant> Bypassing the cache gets an octet-stream as expected.
[05:07] <StevenK> wgrant: Looks like bananananana
[05:09] <StevenK> launchpad_dogfood=> SELECT mimetype from libraryfilealias where id = 50084288;
[05:09] <StevenK> application/octet-stream
[05:09] <wgrant> It is both :(
[05:09]  * StevenK facepalms
[05:09] <wgrant> Both somehow got text/html.
[05:09] <wgrant> Squid-log-diving time, I guess...
[05:10] <StevenK> Orsum
[05:13] <lifeless> relatedly
[05:13] <lifeless> there is a bug open
[05:13] <lifeless> about the librarian and mimetypes - and comments in the code too
[05:13] <lifeless> the idea is that we honour the mimetype and stop guessing
[05:13] <lifeless> and then the librarian server *only ever* hands out what the mimetype says it should be
[05:14] <StevenK> Can we force it be image/png, then?
[05:14] <lifeless>  if you update the LFA yes
[05:14] <lifeless> thats the point, the LFA has crap in it
[05:15] <lifeless> a) garbo hourly task to fix those
[05:15] <lifeless> b) migrate librarian to use that data
[05:15] <lifeless> c) win
[05:15] <wgrant> application/octet-stream is not optimal, but also OK.
[05:16] <LPCIBot> Project devel build (465): FAILURE in 5 hr 24 min: https://hudson.wedontsleep.org/job/devel/465/
[05:16] <LPCIBot> * Launchpad Patch Queue Manager: [r=benji][bug=134063] Updates DateTime widget to kick back formats it
[05:16] <LPCIBot> can't possibly cope with.
[05:16] <LPCIBot> * Launchpad Patch Queue Manager: [r=sinzui][ui=sinzui][bug=687379] Changes alignment of diff overlay
[05:16] <LPCIBot> popup to align on the diff popup link, rather than on the viewport,
[05:16] <StevenK> Right, but image/png let's the browser plan a little better
[05:16] <LPCIBot> so the diff won't expand above the top of the page.
[05:16] <LPCIBot> * Launchpad Patch Queue Manager: [r=jml][ui=none][bug=723003] Make the Sphinx doc build process not
[05:16] <LPCIBot> try to connect to the Internet.
[05:17] <StevenK> test_404 and test_oldurl again
[05:18] <StevenK> ANNOYANCE
[05:18] <wgrant> Yes.
[05:18] <wgrant> Hmm.
[05:18] <wgrant> I wonder if we should catch that exception, cause the test suite to hang in an unkillable way, and spam people to look at the instance.
[05:19] <StevenK> In an Hudson run? There's one person that has keys to the builders
[05:19] <wgrant> Or buildbot.
[05:19] <wgrant> Or ec2, although that is far less frequent.
[05:21] <StevenK> No signs of OOM killage
[05:23] <StevenK> I wish I knew what was going on
[05:26] <wallyworld_> bollocks. if i've already created a mp, there's no way to go back and set a dependent branch?
[05:26] <lifeless> resubmit
[05:26] <lifeless> and then set the dependent branch during that step
[05:26]  * wallyworld_ shakes fist at stupid mp page :-(
[05:26] <StevenK> resubmitting doesn't allow you to do that?
[05:26] <lifeless> this is a bit suboptimal
[05:26] <wgrant> StevenK: I think that changed recently.
[05:26] <StevenK> Bout time
[05:27]  * wallyworld_ takes it all back. it's actually quite easy
[05:28] <wallyworld_> i had thought i would have to start again, but i forgot all this stuff was enhanced at some point
[05:28] <wgrant> Yay, I crashed KDE bugzilla.
[05:28] <StevenK> No big loss
[05:28] <mwhudson> wgrant: that makes feature equivalence between KDE and gnome now?
[05:29] <wgrant> Heh.
[05:44] <wgrant> Ahaaaa
[06:20] <wgrant> :(
[06:20] <wgrant> We have two separate Bugzilla status maps.
[06:22] <lifeless> \o/
[06:22] <wgrant> Here I was wondering why this test wasn't failing when someone broke status mapping a couple of months ago...
[06:29] <lifeless> hmm
[06:29] <lifeless> 7:30 at night
[06:30] <lifeless> I might finally get to write some code
[06:30] <wgrant> Heh.
[06:31] <lifeless> ta is a balancing act ;)
[06:33] <wallyworld_> anyone seen this windmill error on ec2? 'BugsYUIUnitTestCase' object has no attribute 'client'
[06:33] <wallyworld_> that's not even related to my changes
[06:33] <wgrant> That's a new one to me.
[06:33] <wgrant> But probably still spurious.
[06:33] <wallyworld_> 2nd time it's happened :-(
[06:33] <wallyworld_> got a bunch of them
[06:33] <lifeless> race condition?
[06:33] <wallyworld_>   lp.app.windmill.tests.test_yuitests.AppYUIUnitTestCase.runTest
[06:33] <wallyworld_>   lp.bugs.windmill.tests.test_yuitests.BugsYUIUnitTestCase.runTest
[06:33] <wallyworld_>   lp.bugs.windmill.tests.test_yuitests.BugsYUIUnitTestCase.runTest
[06:33] <wallyworld_>   lp.bugs.windmill.tests.test_yuitests.BugsYUIUnitTestCase.runTest
[06:33] <wallyworld_>   lp.code.windmill.tests.test_yuitests.CodeYUIUnitTestCase.runTest
[06:33] <wallyworld_>   lp.registry.windmill.tests.test_yuitests.RegistryYUIUnitTestCase.runTest
[06:33] <wallyworld_>   lp.registry.windmill.tests.test_yuitests.RegistryYUIUnitTestCase.runTest
[06:33] <wallyworld_>   lp.soyuz.windmill.tests.test_yuitests.SoyuzYUIUnitTestCase.runTest
[06:33] <wallyworld_>   lp.soyuz.windmill.tests.test_yuitests.SoyuzYUIUnitTestCase.runTest
[06:33]  * wallyworld_ is disliking windmill a lot today
[06:34] <wallyworld_> lifeless:  could be a race condition. but you'd think an error like "has no attribute" would be quite deterministic
[06:34]  * wallyworld_ will have to look a little deeper.....
[06:35] <wallyworld_> just had to get it all off my chest. nothing like venting a little to relieve the stress
[06:45] <lifeless> still, another branch landed. \o/
[06:58] <lifeless> wgrant: why closed duplicate -> invalid ?
[06:59] <lifeless> wgrant: shouldn't we dereference to the target ?
[06:59] <wgrant> lifeless: Yes, we should. Bug #56644
[06:59] <_mup_> Bug #56644: Remote bugs that are duplicates are shown as "Invalid" <bugwatch> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/56644 >
[06:59] <wgrant> But this is reverting to the old behaviour that was lost in r11434
[06:59] <lifeless> by accident?
[06:59] <wgrant> Yes.
[07:00] <wgrant> All unknown CLOSED/RESOLVED/VERIFIED statuses used to map to Invalid.
[07:00] <wgrant> But that rev listed a few known ones, mapped them to Invalid, and mapped the rest to Unknown.
[07:01] <wgrant> s/mapped them to Invalid/mapped them to appropriate statuses/
[07:01] <lifeless> ah
[07:01] <lifeless> and the map to unknown was bong
[07:01] <wgrant> It was explicit, so nothing got logged.
[07:01] <wgrant> Invalid isn't a great mapping, but it's better than Unknown.
[07:03] <wgrant> Thanks.
[07:10] <wgrant> jtv: Hi.
[07:14] <lifeless> ok, I can make bug search 40 times faster
[07:14] <lifeless> for the ubuntu homepage query
[07:15] <wgrant> :(
[07:17] <lifeless> see my comments on https://bugs.launchpad.net/launchpad/+bug/618406
[07:17] <_mup_> Bug #618406: Distribution:+bugs-index timing out in ~2% of requests <lp-bugs> <pg83> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/618406 >
[07:17] <lifeless> wgrant: trivial fix
[07:18] <wgrant> lifeless: Well, it makes it non-deterministic.
[07:19] <lifeless> in a fashion noone should care an iota about
[07:19] <stub> very non-deterministic, since IIRC we only have 4 levels of heat
[07:19] <lifeless> 5
[07:19] <wgrant> 5 flames.
[07:20] <wgrant> But they are buckets.
[07:20] <lifeless> 4 flames
[07:20] <lifeless> 0,1,2,3,4
[07:20] <wgrant> 5 levels of flame.
[07:20] <wgrant> Right.
[07:21] <lifeless> anyhow
[07:21] <lifeless> we can change the index
[07:21] <lifeless> (heat desc, id)
[07:21] <lifeless> or (heat desc, importance desc)
[07:21] <lifeless> or (heat desc, importance desc, id) - all on bug
[07:21] <lifeless> however
[07:21] <stub> ordering by heat, bug.id, bugtask.id might be better
[07:21] <lifeless> stub: nope
[07:21] <lifeless> stub: forces materialisation
[07:21] <lifeless> stub: see the plan - its doing a sort() - i tried with heat desc, bug.id - still did the sort
[07:21] <lifeless> however, and this is important
[07:22] <lifeless> this is for this hot bugs list
[07:22] <lifeless> *that* list has solid heat variation
[07:22] <stub> It won't - you are retrieving 40 items and there are only 5 buckets
[07:23] <lifeless> the buckets are not evenly populated
[07:23] <lifeless> its a decay function
[07:23] <lifeless> (the bucket allocator is a decay function)
[07:23] <lifeless> the actual heat value is unconstrainted
[07:24] <lifeless> and does not have buckets
[07:24] <stub> The index we seem to want to use here is (heat, last_updated), so ORDER BY Bug.heat DESC, Bug.last_updated DESC LIMIT 40 should hit the index and be deterministic enough
[07:24] <lifeless> (check the data)
[07:24] <stub> ok
[07:25] <lifeless>  Limit  (cost=6957590.92..6957591.02 rows=40 width=1017) (actual time=2761.605..2761.621 rows=40 loops=1)
[07:25] <lifeless>    ->  Sort  (cost=6957590.92..6958004.71 rows=165515 width=1017) (actual time=2761.603..2761.613 rows=40 loops=1)
[07:25] <lifeless>          Sort Key: bug.heat, bug.date_last_updated
[07:25] <lifeless> causes materialisation
[07:25] <lifeless>          Sort Method:  top-N heapsort  Memory: 92kB
[07:25] <lifeless> I'm totally fine with us changing the index.
[07:25] <lifeless> but I think we'll have very deterministic results for ubuntu as a whole with just heat.
[07:25] <stub> oh... that is the heat_last_updated index not the (heat, last_updated) :-(
[07:26] <lifeless>  Limit  (cost=6957590.92..6957591.02 rows=40 width=1017) (actual time=2649.104..2649.119 rows=40 loops=1)
[07:26] <lifeless>    ->  Sort  (cost=6957590.92..6958004.71 rows=165515 width=1017) (actual time=2649.101..2649.106 rows=40 loops=1)
[07:26] <lifeless>          Sort Key: bug.heat, bug.heat_last_updated
[07:26] <lifeless> not to mention, but the hot bugs list is broken anyway
[07:26] <lifeless>          Sort Method:  top-N heapsort  Memory: 92kB
[07:26] <lifeless> its not including series bugs
[07:27] <stub> So yeah, it seems deterministic enough for production. Tests might have difficulties though as you mentioned.
[07:28] <stub> Yeah - I skimmed the indexes too quickly. We don't have a suitable multicolumn index at the moment for guaranteeing determinism and remain fast. We could add one if we want but that is always annoying to add indexes only to keep the test suite happy.
[07:29] <lifeless> right
[07:29] <lifeless> the top 40 bugs by heat in ubuntu are deterministic
[07:29] <lifeless> based on staging data
[07:32] <lifeless> possibly the last 2 will jump around a little, because there is a quantisation effect due to the algorithm.
[07:34] <lifeless> stub: https://bugs.launchpad.net/launchpad/+bug/618406/comments/4
[07:34] <_mup_> Bug #618406: Distribution:+bugs-index timing out in ~2% of requests <lp-bugs> <pg83> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/618406 >
[07:34] <lifeless> stub: make sense?
[07:35] <stub> Apart from importance, which we don't have on Bug.
[07:35] <lifeless> stub: grah, yes.
[07:36] <lifeless> we could push heat down to the tasks - denorm is
[07:36] <lifeless> or rather, make it context specific
[07:36] <lifeless> which might give better results
[07:36] <stub> We just create an index on (heat, id) and ORDER BY heat DESC, id DESC
[07:43] <stub> That will give the same sort of determinism we have at the moment, and be nearly as fast as the heat only lookup
[07:43] <lifeless> sure
[07:43] <lifeless> wasn't sure if it was worth the index
[07:43] <lifeless> I wonder if the heat index is being used at all at the moment
[07:43] <stub> I suspect better an index than denormalizing :)
[07:43] <stub> I think it is - it wasn't in the unused indexes lists I was looking at the other day. Probably being combined with other indexes.
[07:51] <lifeless> stub: denormalisation isn't that bad. How big would this new index be?
[07:51] <stub> double the size of the existing heat index...
[07:51]  * stub forgets how wide timestamps are
[07:51] <stub> oh.. its another int. double.
[07:51] <lifeless> 60MB
[07:51] <lifeless> lets do it
[08:05] <lifeless> stub: I can't find any uses of bugtask.heat_rank
[08:05] <lifeless> stub: am I missing something
[08:05] <stub> lifeless: That column isn't used. I don't know if this was a column for a feature never implemented, or a column that should have been dropped.
[08:05] <stub> We need to ask a bugger.
[08:05] <wgrant> Doctest you suck and I hate you.
[08:05] <wgrant> Yes, let's define the logging level in a file in another directory... what could possibly go wrong.
[08:05] <lifeless> stub: I think just drop, it won't have valid data if its not being update
[08:05] <lifeless> stub: can always add it if/when someone actually works up a feature for it
[08:05] <stub> The only value in the production db is 0
[08:05] <lifeless> exactly
[08:32] <lifeless> grrr
[08:32] <lifeless> public branches linked to private bugs -> boom
[08:32] <wgrant> Hm? Works fine, modulo a leak or two.
[08:32] <lifeless> https://code.launchpad.net/~oops-tools-dev/wsgi-oops/trunk
[08:33] <wgrant> Oh, that one.
[08:33] <wgrant> New bug.
[08:33] <lifeless> Module lp.app.browser.tales, line 1529, in _link_summary_values
[08:33] <lifeless> return {'id': str(self._context.id), 'title': self._context.title}
[08:33] <lifeless> Unauthorized: (<Bug at 0x17001050>, 'title', 'launchpad.View')<br />
[08:33] <wgrant> Right, it's trying to show the bug linked to the MP.
[08:34] <wgrant> A bug was filed a week or so ago... trying to find it.
[08:37] <wgrant> lifeless: Bug 719901
[08:37] <_mup_> Bug #719901: Cannot view branch with revisions fixing private bugs <bug-branch-links> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/719901 >
[08:53] <adeuring> good morning
[09:19] <mrevell> Hello
[09:19] <stub> Any opinions on where an ICleanup interface should live (for declaring adapters for arbitrary objects to a cleanup method)
[09:20] <lifeless> stub: outside the lp tree? :P
[09:21] <lifeless> stub: whats this for - do fixtures or context managers meet your needs already
[09:21] <stub> I want to make the loop tuner call a cleanup method on the loop instance, if it is defined.
[09:22] <stub> Nicer to use adaption rather than sniff for a well known name. And __del__ is fragile and IMO should never be used.
[09:22] <lifeless> I'd make the loops a Fixture
[09:22] <lifeless> add that into the base class
[09:22] <lifeless> call setUp before using the loop
[09:23] <lifeless> cleanUp at the end of the loop
[09:23] <stub> The loops implement an interface - they don't subclass from any particular root.
[09:23] <stub> there is no base class.
[09:24] <lifeless> mmm
[09:24] <lifeless> well you could interface this up
[09:24] <lifeless> personally I'd just make them all subclass from fixture
[09:24] <lifeless> the cleanup facilities in it are mature and useful
[09:25] <stub> There doesn't seem to be any sane location in lp.* for such an interface :-P (nor a load of the other stuff still in canonical.*, as I'm sure jml is finding)
[09:25] <lifeless> I'd be quite happy to have a zope interface for fixture in the fixtures tree
[09:25] <lifeless> if that woul dhelp
[09:25] <stub> Where is the fixtures tree?
[09:27] <lifeless> https://launchpad.net/python-fixtures
[09:27] <lifeless> is the upstream
[09:27] <lifeless> its widely useful beyond unit testing, so ignore that bit of the blurb
[09:28] <danilos> lifeless, fwiw, bug 720826 was already qad yesterday (before I added special rollout requirements for that), but since it was only [incr] change, I didn't consider it a big deal to mark the bug as such (i.e. it wouldn't block the rollout, wouldn't it?)
[09:28] <_mup_> Bug #720826: Add subscription description header for bug notifications <qa-ok> <story-better-bug-notification> <Launchpad itself:In Progress by danilo> < https://launchpad.net/bugs/720826 >
[09:29] <lifeless> danilos: --incr seems to be broken in some corner cases
[09:29] <lifeless> danilos: I touched it because it showed up in the deployment-stable rpeort
[09:30] <danilos> lifeless, ah, ok then, sorry for causing more work for others then (I did put it properly through QA on the kanban board, but unfortunately, that's still not linked to LP)
[09:30] <wgrant> Is that the one where the [incr] was at the start, separated from the rest by a space?
[09:30] <lifeless> danilos: no worries
[09:30] <stub> lifeless: Not sure I want the 'exceptions are swallowed' bit.
[09:31] <lifeless> wgrant: --incr combine with something or other results and doesn't send the right thing to pqm IIRC
[09:31] <lifeless> stub: they aren't anymore
[09:31] <lifeless> stub: thats stale - where did you see that ?
[09:31] <stub> lifeless: ic. The docstring for addCleanup says they are swallowed.
[09:31] <lifeless> stub: I shall fix that
[09:32] <lifeless> stub: if multiple excpetions are raised (one per cleanup, say), then one exception is raised, with its args being the individual exceptions that got raised
[09:32] <lifeless> stub: if only one is raised, it is reraised asis
[09:34] <lifeless> right, those docstrings are really stale. naughty lifeless
[09:35] <stub> So declaring an IFixture interface seems overkill, as the sanest way to use this would be to just subclass Fixture and then isinstance is fine (which isn't the component architecture way, but that is often a good thing ;) )
[09:37] <stub> jtv: Any objection to the loop tuner runner sniffing for isinstance(Fixture), and invoking the setUp and cleanUp methods?
[09:38] <stub> Or perhaps that is better left for the garbo
[09:38] <jtv> stub: otp for a minute more… what is it you actually want to do?
[09:38] <stub> Tell a loop tuner instance 'you were aborted so clean up now'
[09:39] <lifeless> stub: personally, I'd just subclass Fixture on all our loops
[09:39] <lifeless> stub: and then not even worry about the isinstance sniff. Seems simpler.
[09:39] <stub> Without adding a new method to ILoopTuner, and without making all the existing loops inherit from a subclass
[09:39]  * jtv reads backscroll
[09:40] <lifeless> stub: I've pushed rev 22 explaining things better
[09:41] <jtv> Are we supposed to use fixtures in production code?  I thought they were just for tests.
[09:41] <stub> We have dozens of implementations and this is the first time we have wanted cleanup. Adding setup, cleanup, reset (addsetup etc.) to everything seems overkill.
[09:42] <stub> jtv: Its generic code, not test specific, but alot of it makes no sense for this use case.
[09:42] <jtv> Yes… maybe we should just have an extra method in the ITunableLoop, with an empty default implementation.
[09:42] <lifeless> jtv: the inspiration was a specific set of testing problems; they are much more general than that.
[09:43] <jtv> By the way stub, are you using the DBLoopTuner or the plain LoopTuner?
[09:43] <stub> jtv: dblooptuner
[09:44] <jtv> Cool.
[09:45] <jtv> Anyway, in the spirit of duck typing, why not def cleanUp(self) to the tunable-loop API, guarantee that it gets called at least once by the loop tuner, and provide a blank default?
[09:45] <jtv> I agree that a full fixture interface seems a bit much.
[09:45] <jtv> After all, all we really want here is a *cough* *cough*destructor*cough* *cough*
[09:46] <lifeless> jtv: the 'full fixture interface' is just: call setUp before doing stuff with it, and cleanUp afterwards.
[09:46] <lifeless> jtv: so if we do the duck typing thing, its nearly no extra overhead to use the full fixture interface
[09:47] <lifeless> I don't really mind whats done here, just throwing my 20c in the ring
[09:47] <jtv> But then what does setUp _mean_?  It's still a method too many.
[09:47] <lifeless> jtv: from that argument, cleanUp is unneeded to - the inner loops just need a finally
[09:48] <jtv> I don't see how that works—the whole point is that this spans the interface between looptuner and tunableloop.
[09:49] <jtv> So we're talking about how the tunable loop tells the looptuner, "I need you to promise that you'll call this cleanup method at the end, no matter what happens."
[09:50] <jtv> One way we could do it is to make the caller use either "with" or a fixture (from my point of view they do the same thing, just with static/dynamic lifetime) but that burdens the call site with the needs of the type.
[09:50] <stub> jtv: I started with ICleanup(loop) to do that. More complex than duck typing, but catches typos when you declare a 'cleanup' method instead of a 'cleanUp' method.
[09:51] <jtv> Clever.
[09:51] <stub> But I guess this is Python
[09:52] <jtv> I wouldn't worry about it _too_ much, no.
[09:53] <jtv> I guess it's easier to get the adapter wrong than to get the method name wrong.
[09:54] <stub> I'll add cleanUp() to ITunableLoop as an optional method, which will be compatible with loops inheriting from Fixture.
[09:55] <jtv> Yes, that's nice.  Do we have any of those?
[09:57] <stub> No, but we might if this becomes a more common problem.
[09:58]  * stub wonders if  we have any loops that don't inherit from TunableLoop, and we could just use inheritance
[10:02] <lifeless> stub: I didn't see any when I was last looking at the code - thats why I suggested adding Fixture to the TuneableLoop base class
[10:03] <wgrant> jtv: Could I throw a review your way?
[10:04] <wgrant> Oh.
[10:04] <wgrant> lifeless already did.
[10:04] <wgrant> Sneaky lifeless
[10:04] <jtv> wgrant: yes, but otp now
[10:12] <stub> there are a few in translations
[10:36] <StevenK> OMGWTFBBQ
[10:36] <wgrant> ?
[10:37] <StevenK> We need to QA and deploy r12433 *right* *now*
[10:38] <jml> StevenK: patience.
[10:38] <StevenK> That bug has been annoying me for *weeks8.
[10:38] <StevenK> s/8/*/
[10:38] <wgrant> Is that the MP diff thing?
[10:38] <StevenK> wgrant: Yes
[10:38] <wgrant> Heh.
[10:39] <wgrant> We could QA and deploy that in 5 minutes if you really want to.
[10:41] <StevenK> We could, yes ...
[10:43] <LPCIBot> Yippie, build fixed!
[10:43] <LPCIBot> Project devel build (466): FIXED in 5 hr 27 min: https://hudson.wedontsleep.org/job/devel/466/
[10:43] <LPCIBot> Launchpad Patch Queue Manager: [r=leonardr][no-qa] add an API to get all of the subscriptions for a
[10:43] <LPCIBot> set of bugtasks.
[10:44] <jml> that reminds me
[10:44] <jml> sometime this week, I'd like Ursinha & matsubara to get a chance to orchestrate a nodowntime rollout
[10:44] <wgrant> There's not that much orchestration to do, which is nice.
[10:45] <jml> yeah. I get that impression.
[10:45] <wgrant> Although if they were doing them I think they would make it even more trivial.
[10:45] <jml> yeah, that's also my thinking :)
[10:46] <wgrant> The largest task (apart from sorting out QA stragglers) is turning the deployment report into a list of bugs to put on the wiki.
[10:46] <jml> plus, we really need to figure out this QA vs not-abysmal-to-deploy thing
[10:47]  * jml goes to get food.
[11:02] <wgrant> Out of order bug notifications make me sad.
[11:10] <bigjools> jml: when using the logger in the poppy daemon, everything seems to get swallowed. I vaguely recall some weird trick you need to do to get it working?
[11:20] <jml> bigjools: which logger? poppy uses two.
[11:21] <bigjools> jml: gah
[11:21] <jml> bigjools: or rather, there's Python logging and Twisted logging.
[11:21] <bigjools> jml: logging.getLogger("poppy-sftp")
[11:21] <bigjools> so the former
[11:21] <jml> right.
[11:21] <bigjools> presumably they need to be connected?
[11:21] <jml> bigjools: you need to add a handler to it, I think.
[11:22] <bigjools> twisted.... always needs something different :)
[11:22] <jml> bigjools: umm... I guess they should be.
[11:22] <jml> bigjools: historical reasons, when Twisted was first written, Python didn't have logging.
[11:23] <bigjools> jml: ah I can copy what the buildd-manager does
[11:23] <jml> bigjools: that sounds like a great plan.
[11:26] <bigjools> sorted
[11:44] <wgrant> jml: Hah, I just got hit by that LockWarner thing for the first time.
[11:44] <jml> wgrant: yay, now we can be partners in hatred
[11:45] <jml> wgrant: https://bugs.launchpad.net/launchpad/+bug/721166
[11:45] <_mup_> Bug #721166: Tests sometimes fail on EC2 due to _LockWarner garbage <build-infrastructure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/721166 >
[11:49] <wgrant> jml: The prime target of my hatred at the moment is Zopeless.
[11:49] <wgrant> It has almost perished.
[11:49] <jml> wgrant: I'm glad to hear it.
[11:49] <wgrant> Afterwards it may be redirected to this garbage.
[11:49] <jml> heh.
[11:50] <jml> wgrant: there are three separate spurious test failures that bit me last week. I think I'll try to tackle one of them on my next hacking day.
[11:58] <bigjools> jml: so, the idea for waiting on the log file output works a treat.  Except for the isolation tests :)
[11:59] <jml> bigjools: you mean, ones that call code in-process?
[11:59] <bigjools> jml: no, the simultaneous upload
[12:00] <bigjools> I need to wait for multiple occurrences of the magic string
[12:00] <jml> right.
[12:00] <jml> a parameter to waitForClose() perhaps?
[12:00] <bigjools> something like that yeah
[12:03] <bigjools> I freaking love Python today
[12:04] <deryck> Morning, all.
[12:05] <bigjools> hi deryck
[12:07] <jml> bigjools: yay
[12:08] <bigjools> jml: string.count() FTW
[12:09] <jml> bigjools: ahh yeah.
[12:10] <jml> bigjools: you know you can do that directly off a string, no need to import string
[12:10] <bigjools> I didn't
[12:11] <jml> 'abba'.count('b') => 2
[12:24] <jml> I want to spend all of today programming.
[12:24] <jml> But I am going to have meetings and read specs instead.
[12:29] <bigjools> jml: heh, doing this fix has highlighted a bug in the hooks.  If the uploads happen *really* close to each other then the path containing the timestamp overlaps
[12:29] <jml> bigjools: yay finding bugs. that sounds like a fairly shallow one, which is even better :)
[12:30] <bigjools> jml: not entirely sure how to fix it minds
[12:30] <jml> bigjools: won't the targetcount uniquify them already?
[12:30] <bigjools> yeah I just saw that
[12:30] <bigjools> wtf
[12:31] <jml> or are there separate "Hooks" instances?
[12:31] <bigjools> urgh, that'll be it
[12:31] <bigjools> nicely spotted
[12:31] <bigjools> the cheap fix is to make targetcount static :)
[12:32] <jml> yeah. the slightly less cheap but oh-such-good-value-for-money thing is to put the count on an object with a longer lifetime, such as an object that represents the server
[12:33] <wgrant> For everything else, there's mktmp
[12:34]  * bigjools spots tumbleweed rolling past
[12:35] <bigjools> unfortunately the shell can't see the server it seems
[12:35] <jtv> bigjools: since you're just tumbleweed-spotting, maybe you could review https://code.launchpad.net/~jtv/launchpad/bug-181368-ami/+merge/50910
[12:36] <bigjools> jtv: self-review such a small change
[12:36] <jtv> It's not the size, it's that I don't know if I did it right.  :)
[12:36] <jtv> Also, there's a useful bash tip in the MP.
[12:36] <bigjools> you'll find out when you try and use it :)
[12:37] <jtv> Yeah I guess.
[12:37] <bigjools> that is a useful tip - I've seen it before, never got around to setting it up
[12:38] <jtv> For all those oh-sh*eep moments when you wish you'd remembered to echo $*
[12:38] <jtv> Sorry, $?
[12:39] <jtv> Why do we hard-code a geographical location into our choice of AMI?  I'm tempted to self-review a change to the Singapore one.  :)
[12:41] <jtv> Or is there something in our script that picks the nearest?
[12:42] <jml> jtv: approved.
[12:42] <jtv> thanks jml, a sanity check is always welcome
[12:42] <jtv> I find them more reliable than sheep entrails lately
[12:43] <jml> jtv: find a better augur.
[12:43] <jtv> Well I thought I did, after Arthur Andersen went down.
[12:43] <jtv> Oh, au_gur_…
[12:43] <jml> jtv: re geographical location, don't know. Maybe the ec2 api docs have something.
[12:45] <jtv> It could probably help a lot to pick the right location… to illustrate, apparently we'd get more bandwidth to the US through a proxy running in EC2 Singapore than we do directly.
[12:45] <bigjools> the bandwidth that counts is between the ec2 instance and the DC
[12:54] <jtv> bigjools: so we should all be using the one near the DC?
[12:54] <bigjools> jtv: well I would have thought so, no idea where that is though
[12:55] <bigjools> but the b/w between the US and London is immense anyway
[12:55] <jtv> lucky bastards
[13:01] <jtv> bigjools, was that you who had trouble with the LC_TIME setting going into the image that the image can't deal with?
[13:02] <bigjools> jtv: yes
[13:02] <bigjools> I mentioned it in the wiki
[13:02] <bigjools> it expects en_US
[13:02] <jtv> that's why I'm asking… turns out the script code removes LC_ALL from the env.  It could just do the same for LC_TIME I suppose.
[13:02] <jtv> Oh, food gong
[13:03] <bigjools> jtv-eat: ah yes that'd be better
[13:03]  * bigjools away lunch
[13:13] <danilos> forgot about that bit :)
[13:20] <gary_poster> ugh, staging down for code update again. :-(  Hopefully this one does not become another marathon outage.
[13:21] <gary_poster> anyone happen to know if this one has lasted awhile?  (this is staging, not qastaging)
[13:21] <jml> hmm.
[13:21] <jml> ec2 is sometimes sending emails that are 33,557,808 bytes long.
[13:21] <gary_poster> that seems excessive
[13:22] <jml> yes.
[13:22]  * jml finds out whether a partial base64 string can be decoded
[13:28] <jml> not by standard python tools, is the answer.
[13:31] <benji> jml: if this is a one-off, this thing appears to handle truncated base64 strings: http://www.motobit.com/util/base64-decoder-encoder.asp
[13:34] <jml> benji: thanks. it doesn't seem to work for me. I'll try to bump up the limits on my mail server and hope for the best.
[13:37] <danilos> jml, well, you can always make it in 4 tries at most
[13:38] <jml> danilos: not sure what you mean.
[13:38] <danilos> jml, you just try with round_to_4(string), round_to_4(string[1:]), round_to_4(string[2:]) and round_to_4(string[3:]) where round_to_4 rounds the length to zero modulus 4
[13:39] <jml> danilos: oh, you're using an actual knowledge of what's going on. that's cheating.
[13:39] <danilos> jml, base64 decodes each 4 characters into 3 bytes
[13:39] <danilos> jml, heh, ok then :)
[13:44] <jml> hmm. just looks like a data file. can't recognize the format.
[13:54] <jml> deryck: we're really using YUI 3.3 on prod now, right?
[13:56] <deryck> jml, indeed we are
[13:56] <jml> deryck: sweet. thanks.
[13:56] <deryck> np
[13:56]  * jml adds a hacking task.
[13:58] <allenap> jtv, danilos: Do either of you have time to review https://code.launchpad.net/~allenap/launchpad/async-person-merge-162510/+merge/50919?
[13:58] <danilos> allenap, I'll take it :)
[13:59] <allenap> danilos: Cheers :)
[13:59] <danilos> allenap, I am very happy to see this happening, btw! :)
[13:59] <allenap> danilos: Awesome!
[13:59] <danilos> (talking about bug 162510, fwiw)
[13:59] <_mup_> Bug #162510: Person:+delete timeouts : Person merging needs to be done asynchronously <canonical-losa-lp> <chr> <feature> <lp-registry> <merge-deactivate> <tech-debt> <timeout> <Launchpad itself:Triaged by allenap> < https://launchpad.net/bugs/162510 >
[14:07] <danilos> allenap, line 195 of the diff: "nor is it not guaranteed" sounds kinda weird
[14:07] <danilos> allenap, but, first things first: this is going to be backed up by a DB patch for is_pending_merge as well?
[14:07] <danilos> allenap, s/is_pending_merge/is_merge_pending/
[14:08] <allenap> danilos: No, it doesn't need a patch.
[14:08] <danilos> allenap, how's it going to protect against race conditions?
[14:09] <allenap> danilos: Do you mean against a merge being requested twice?
[14:09] <danilos> allenap, yeah, possibly even to a different person
[14:10] <abentley> henninge: would you be free to mumble soon?
[14:10] <allenap> danilos: I haven't actually checked if it'll break in that case. I assume PersonSet.merge() will break, but perhaps I ought to add a specific check.
[14:11] <allenap> danilos: My intention with Person.is_merge_pending is to use it to either display a message on Person:+index, or to disable all mutations from that page.
[14:12] <danilos> allenap, right, but you can do it only inside the session if it's not persistent
[14:12] <allenap> danilos: It's derived from the database.
[14:12] <danilos> allenap, i.e. if somebody reloads the page, they won't see a warning and they'll be able to change stuff
[14:12] <danilos> allenap, it is? oh
[14:13] <danilos> allenap, right, I only got to that point now
[14:13] <allenap> danilos: Adding notifications via the request object is session-bound, or something like that, but I wasn't planning on using that.
[14:14] <danilos> allenap, yep, I see how you get it, the presence of a merge job indicates that the merge is pending, all good :)
[14:16] <allenap> danilos: I've fixed the docstring, thanks for spotting that.
[14:21] <danilos> allenap, I suppose framework to run PersonTransferJobs is already there? (or membership notifications wouldn't even go off :)
[14:22] <allenap> danilos: Yeah, it'll get run with: cronscripts/process-job-source-groups.py MAIN
[14:24] <danilos> allenap, cool, so the only other thing that I can ask you to do is to make sure DB privileges for that script are suitable for whatever the merging needs (it probably needs a lot more than what it used to); if you want to add a minimal test that runs the script in appropriate environment, I wouldn't mind
[14:24] <allenap> danilos: Good idea :)
[14:25] <danilos> allenap, it'd also be nice to get rid of the web server DB user privileges that are not going to be used, but I am sure that's very hard to figure out and very easy to get wrong, so if you feel like it's worth it, just file a bug
[14:26] <allenap> danilos: I think that'll be a case of trial and error. Lots of error. I also suspect that I may end removing nothing.
[14:26] <danilos> allenap, and it's a very nice branch, btw, I like it :) r=me
[14:26] <allenap> danilos: Cheers, thank you!
[14:29] <henninge> abentley: let's do it in 30 min if that's ok.
[14:29] <abentley> henninge: sure.
[14:36] <jcsackett> abentley: do you know how one gets full mp diffs available on qastaging? i need to qa a bug about diff-overlays.
[14:36] <abentley> jcsackett: You need to run the merge-proposal-jobs script.
[14:36] <abentley> jcsackett: though if your code has landed on staging, it's easier to qa there because the scripts already run.
[14:37] <jcsackett> abentley: i'll see if it's there; thanks. if it's not, i assume i have to bug losas for the script?
[14:37] <abentley> jcsackett: yes, you'd have to bug the losas.
[14:38] <jcsackett> abentley: thanks.
[14:39] <abentley> jcsackett: also, I think you'll need to run scan-branches before running the merge-proposal-jobs script.
[14:39] <jcsackett> abentley: dig.
[14:45] <bigjools> jml: your suggestion does not work
[14:47] <abentley> jkakar: That issue I was having turns out to be a known bug that References don't know they're associated with ClassAliases.  Bug #682989
[14:48] <jtv> bigjools, could you do something for me?  →
[14:48] <jtv> echo $LC_TIME
[14:48] <jml> bigjools: it does.
[14:49] <bigjools> jtv: en_GB.utf8
[14:49] <jtv> thanks
[14:50] <jkakar> abentley: Ah, interesting, thanks for letting me know.
[14:50] <bigjools> jml: pebkac :(
[14:51] <abentley> jkakar: no worries.
[15:10] <leonardr> lifeless: apropos our conversation of last week, https://bugs.edge.launchpad.net/lazr.restful/+bug/723753
[15:10] <_mup_> Bug #723753: Continuous deployment makes web service mistakes much more dangerous <lazr.restful:New> < https://launchpad.net/bugs/723753 >
[15:18] <henninge> abentley: let's chat! ;-)
[15:37] <danilos> allenap, hi, do you know if BugNotificationRecipientReason gets used anyhow? should BugNotificationRecipientSet instead use it?
[15:37] <allenap> danilos: Not off the top of my head. I'll have a look.
[15:37] <danilos> allenap, thanks
[15:38] <allenap> danilos: What's BugNotificationRecipientSet?
[15:38] <danilos> allenap, s/Set/s/ :)
[15:39] <allenap> Ah ha :)
[15:44] <allenap> danilos: Yes, I guess it was meant to be used by BugNotificationRecipients, but that looks like it would just complicate things now.
[15:44] <allenap> danilos: It's dead code, may as well remove it. I wonder if the reason+header generation in BugNotificationRecipients is tested?
[15:45] <allenap> I'm almost certain it is, but I can't remember where.
[15:46] <danilos> allenap, what's interesting is that BugNotificationRecipientReason is well tested in lib/lp/bugs/mail/tests/test_bugnotificationrecipients.py
[15:46] <abentley> danilos or jtv: could you please review https://code.launchpad.net/~abentley/launchpad/class-alias-mergable/+merge/50940 ?
[15:46] <allenap> danilos: Yeah, odd isn't it. I guess it was never plumbed in.
[15:46] <jtv> abentley: coming
[15:47] <danilos> abentley, ok, I am letting jtv have it
[15:47] <jtv> he's so generous
[15:47] <abentley> jtv, danilos: thanks.
[15:47] <abentley> jtv: still in the Netherlands?
[15:48] <jtv> Yes
[15:48] <danilos> abentley, fwiw, I remember writing a complex query with ClassAlias, but perhaps you need to explicitely add it to the store.using() list (at least I think it used to work)
[15:49] <abentley> danilos: The issue was that I was using a Reference, and the Reference thought it was part of the class, not the ClassAlias.
[15:49] <abentley> danilos: So I switched to the column property instead, which worked properly.
[15:50] <danilos> abentley, ah, ok
[15:51] <jtv> abentley: done
[15:51] <jtv> ClassAliases are pretty shallow AIUI
[15:51] <abentley> jtv, thanks.
[15:52] <jtv> abentley: by the way, care to review a similarly small branch for me as well?  https://code.launchpad.net/~jtv/launchpad/bug-723733/+merge/50935
[15:56] <abentley> jtv: the set_trace_if function seems a bit weird to me.  Is its main purpose is to reduce the number of lint warnings?
[15:57] <jtv> abentley: yes, though I do also see those as a hint that this needs encapsulating.  If we're doing something weird, repeatedly, then it might as well have a name.
[16:00] <abentley> jtv: I see what you're saying.  I think I might have written it into EC2Command.run instead, but this is fine.
[16:01] <jtv> thanks… TBH I was a bit lazy because I didn't want it to overshadow the main change
[16:01] <jtv> (And didn't want to spend much time on it)
[16:01] <abentley> jtv: r=me
[16:01] <jtv> thanks
[16:03] <jtv> danilos, henninge: the approval page is no longer timing out… I just dealt with a few of the remaining oldest entries.
[16:04] <LPCIBot> Project db-devel build (390): FAILURE in 5 hr 50 min: https://hudson.wedontsleep.org/job/db-devel/390/
[16:07] <jcsackett> jtv: any chance you might be able to help me figure out why a user can't save any tranlations for the loco-teams directory?
[16:08] <jtv> jcsackett: "can't save" any translations?
[16:08] <jcsackett> she puts in some strings, tries
[16:08] <danilos> jtv, cool
[16:08] <jcsackett> tries to save them, and gets the "try again in a few minutes" message.
[16:08] <jtv> jcsackett: sounds like a timeout… got an oops number?
[16:10] <jcsackett> jtv: no, just the "Try again in a few minutes, if it persists ask someone in #launchpad" message.
[16:11] <jcsackett> jtv: full details are in #launchpad now, if you're interested in hopping in--i'm well into my zone of ignorance on just about anything translation related.
[16:11] <jtv> jcsackett: I'll have a look
[16:12] <abentley> henninge: Does this look reasonable to you? http://pastebin.ubuntu.com/571203/
[16:13] <abentley> henninge: I was getting ForbiddenAttribute, and switching security policies doesn't fix that.
[16:13] <jcsackett> jtv: ok, thanks.
[16:14] <abentley> henninge: But once an attribute is writable by *someone*, then scripts can write to it.
[16:14] <henninge> abentley: yes, looks reasonable. ;)
[16:16] <henninge> abentley: The reason may be that these attributes are marked as "readonly" in the interfaces.
[16:17] <henninge> I was wondering why the "set_schema" config  does not suffice.
[16:18] <henninge> so "set_attribute" seems to override the "readonly" flag on the attribute.
[16:20] <abentley> henninge: Yes, for TranslationMessage, setting it readonly=False makes set_schema provide it.
[16:20] <abentley> TranslationTemplateItem doesn't use set_schema.
[16:21] <henninge> interesting
[16:23] <henninge> abentley: I was wondering how setSequence updates the sequence without a set_schema.
[16:24] <henninge> abentley: Looking at it, it gets its TransalationTemplateItem instance from a database call, so I guess that returns naked objects.
[16:25] <abentley> henninge: looks correct to me.
[16:33] <bigjools> I find it really satisfying that when I want to force a package upload with a bad signature, the dput options are -fu
[16:36] <jml> :)
[16:36] <abentley> danilos or jtv: Could you please review https://code.launchpad.net/~abentley/launchpad/translation-splitting/+merge/50949 ?
[16:37] <jtv> abentley: bit busy atm, and may get called away.  I'm afraid I'll have to bow out soon.
[16:38] <abentley> jtv: understood.
[16:40] <danilos> otp
[16:49] <lifeless> jml: for Ursinha / matsubara to do a deploy - I'd be delighted to walk them through it whenever
[16:50] <jml> lifeless: thanks.
[16:50] <jml> lifeless: I think the key thing is getting wgrant to *not* do one
[16:51] <lifeless> jml: why?
[16:52] <jml> lifeless: because there are rarely revisions to deploy when Brazil wakes up
[16:52] <lifeless> there are 5 revs queued up already since last nights deploy
[16:52] <Ursinha> lifeless, thanks, I'd love to do that
[16:52] <jml> then I am misinformed :)
[16:52] <Ursinha> (before wgrant :P)
[16:53] <lifeless> jml: there are rarely revisions ready to go when wgrant and I get up as well - its proactive qa of revs in the queue that gets it ready for a deploy
[16:54] <lifeless> right now for instance, a patch from jc is blocking the qa pieline, there are 2 more ready after that, and then the 4th blocked on a patch from me.
[16:54] <lifeless> Ursinha: well, lets do one after the team lead call ?
[16:54] <Ursinha> lifeless, yes!
[16:58] <lifeless> \o/ 74 queries/external actions issued in 4.15 seconds for a bug search on qastaging / ubuntu
[17:01] <jml> lifeless: down from...?
[17:02] <lifeless> jml: last week it was timeouts :)
[17:15] <danilos> abentley, sorry, I am wrapping up for the day, and your branch is not on the small scale (though, I am intrigued by it, since this is something we've been missing for general message-sharing as well :)
[17:27] <thumper> deryck: I want to chat with you some time later about some yui / windmill tests, but when I'm more awake and caffeinated
[17:27] <deryck> thumper, sure.
[17:28] <lifeless> Ursinha: would you like to schedule a deploy ?
[17:28] <Ursinha> lifeless, yes.
[17:28] <lifeless> Ursinha: how would you like to do this - irc, voice, ?
[17:28] <Ursinha> lifeless, I'll have a call with jml and then I'll be ready
[17:28] <lifeless> kk
[17:28] <Ursinha> works for you?
[17:28] <lifeless> I'll go grab breakfast
[17:31] <Ursinha> argh
[17:56] <Ursinha> lifeless, I'm back
[17:57] <lifeless> cool
[17:57] <lifeless> so
[17:57] <lifeless> Ursinha: how would you like to do this - irc, voice, ?
[18:01] <Ursinha> lifeless, I'm fine with anything, do you think we need voice?
[18:01] <Ursinha> as in too much information to type
[18:01] <lifeless> dunno :)
[18:01] <lifeless> ok
[18:01] <lifeless> so - lets start
[18:02] <lifeless> first thing is to assess whether there is enough to deploy - we don't want to overload the losas.
[18:02] <lifeless> deploys take about an hour of wallclock time
[18:02] <Ursinha> right
[18:02] <lifeless> and a losa needs to spend ~ 5-10 minutes during that period kicking parts of it off
[18:04] <lifeless> we do 10 commits a day, so 5 commits is a reasonable number to deploy (assuming nothing really urgent - if there was urgent stuff we wouldn't wait for 5:)
[18:04] <lifeless> https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
[18:04] <lifeless> shows that we have nothing ready to deploy
[18:04] <Ursinha> I see
[18:05] <Ursinha> I'm pretty familiar with that report at least :P
[18:05] <lifeless> but, if we check to ensure the first commit is safe to deploy
[18:05] <lifeless> then we will have 5 revisions ready to go
[18:05] <lifeless> so lets do that
[18:05] <Ursinha> yep
[18:05] <Ursinha> so do you ask the landing owner to qa that or you do that yourself?
[18:05] <lifeless> if they are around, you might ask.
[18:06] <lifeless> as it happens jcsackett is trying to get it qa'd now, but the losas will be gone.
[18:06] <jcsackett> lifeless: :-P
[18:07] <lifeless> Ursinha: one of the htings I look for is whether it can possibly be worse
[18:07] <lifeless> Ursinha: if it can't be, then deploying it is ok :)
[18:07] <lifeless> Ursinha: so, I'd visit https://bugs.launchpad.net/launchpad/+bug/687379 - the linked bug
[18:07] <Ursinha> hehe
[18:07] <_mup_> Bug #687379: Merge proposal diff overlay is bigger than the screen and can't be closed <confusing-ui> <javascript> <lp-bugs> <qa-needstesting> <regression> <Launchpad itself:Fix Committed by jcsackett> < https://launchpad.net/bugs/687379 >
[18:07] <lifeless> Ursinha: click through to the merge proposal
[18:08] <lifeless> and read whats changed, what the reviewer etc said, and consider the existing behaviour
[18:08]  * jml is off
[18:08] <Ursinha> bye jml
[18:08] <Ursinha> lifeless, right
[18:09] <lifeless> and in this case, it looks like:
[18:09] <lifeless>  - the old behaviour is unusable
[18:09] <lifeless>  - the change is tiny and can't break other things - its isolated the branchmergeproposal javascript
[18:09] <lifeless> Ursinha: so I would mark this qa-ok immediately
[18:10] <Ursinha>   hm, right
[18:10] <Ursinha> we should consider the qa-deployable or something that just says the branch is deployable
[18:10] <lifeless> (if losas were around doing a more thorough test like jcsackett tried to, would be awesome. This is a risk balance thing)
[18:10] <Ursinha> right
[18:10] <lifeless> Ursinha: yes, exactly
[18:10] <lifeless> Ursinha: so, go ahead and qa-untestable or qa-ok the bug
[18:11]  * Ursinha marks the bug qa-untestable
[18:12] <lifeless> now we switch back to the -stable report
[18:13] <Ursinha> lifeless, I'll poke the script to generate that now
[18:13] <lifeless> I typically repeat this for all the bugs - qaing any that can be, assessing others for deployability
[18:13] <lifeless> I talk to the engineers / team leads where it seems doubtful
[18:13] <Ursinha> ok
[18:13] <lifeless> e.g. distro mirror probing script changes are very hard to qa at all
[18:14] <lifeless> then, yes - the script taking a long time to update is a real concern :)
[18:14] <lifeless> you're privileged
[18:15] <lifeless> Ursinha: then, once it updates, rev 12437 will be deployable
[18:15] <lifeless> Ursinha: so stage two - prepare a deployment request on LaunchpadProductionStatus
[18:16] <lifeless> Ursinha: what I do is:
[18:16] <lifeless>  - open the page, click edit, use ctrl-f and search for 'requested stable depl' - that gets me to the right section
[18:17] <lifeless>  - and we can see that last nights deploy didn't get moved correctly when it was done, the losas generally do that.
[18:17] <lifeless> there is a big table higher up the page that contains the recently complete deployments
[18:17] <lifeless> so we should move last nights deploy up to that table
[18:18] <Ursinha> ok, looking
[18:20] <Ursinha> lifeless, deployment is already in the big table
[18:21] <Ursinha> requested stable deployments is empty
[18:21] <Ursinha> ok, now
[18:21] <lifeless> ah cool
[18:21] <lifeless> my copy of the page was stale I guess
[18:21] <lifeless> so, now, we edit the requested stable deployments section
[18:21] <lifeless> this is very mechanical
[18:22] <lifeless> we take the revno from the stable report
[18:22] <lifeless> the 'can be deployed to production' one - second row at the top
[18:23] <lifeless> for the bug #'s column
[18:24] <lifeless> we go through each row in the deployment report and copy the Bug 12345 text
[18:24] <_mup_> Bug #12345: isdn does not work, fritz avm (pnp?) <isdnutils (Ubuntu):Fix Released by doko> < https://launchpad.net/bugs/12345 >
[18:24] <lifeless> change it to Bug:1234
[18:24] <lifeless> which makes it a wiki ling
[18:24] <lifeless> *link*
[18:25] <lifeless> for requested by put your own name
[18:25] <lifeless> for approved by 'qatagger'
[18:25] <Ursinha> right, I took last one as example
[18:25] <lifeless> for roll out to, put 'nodowntime'
[18:26] <lifeless> and for comments put any special things that the revisions being deployed need
[18:26] <Ursinha> right
[18:27] <lifeless> I figure that out by reading all the revisions one at a time in the stable list, clicking through to the bug etc depending on how familiar I am with it
[18:27] <lifeless> for instance, some things need a new feature flag added *before* the deploy starts
[18:27] <lifeless> engineers will often arrange for that
[18:27] <lifeless> or code so that it doesn't need to happen at the same time
[18:27] <lifeless> but its not always like that, so a small check is good
[18:27] <lifeless> save the page
[18:27] <lifeless> ping a losa
[18:27] <Ursinha> right
[18:28] <lifeless> <wait an hour>
[18:28] <lifeless> then click on all the bug links you put in the wiki page to open the bugs
[18:28] <lifeless> for each one, if its fixed by a nodowntime deploy, toggle it to fix released
[18:28] <lifeless> if it needs other actions
[18:28] <lifeless> or if its a incremental branch
[18:29] <lifeless> toggle it back to in progress
[18:29] <Ursinha> ok. right
[18:29] <lifeless> (or leave at fix committed if the remaining work is e.g. a deploy to germanium)
[18:29] <lifeless> -done-
[18:31] <lifeless> there are bugs open on qatagger for all the pain points :)
[18:32] <Ursinha> ah, I know!
[18:32] <Ursinha> about not being able to run it on demand, don't you have access to lpqateam user on devpad?
[18:32] <lifeless> I tried to sudo to it the other day
[18:33] <lifeless> didn't work
[18:33] <lifeless> will try and sort that out when the losas aren't sprinting
[18:33] <Ursinha> hm
[18:36] <Ursinha> lifeless, file an RT asking for your user to be added to lpqateam on devpad
[18:36] <lifeless> yeah, had done
[18:36] <Ursinha> that should be enough
[18:36] <Ursinha> ah, cool
[18:36] <lifeless> late last year
[18:36] <lifeless> need to find it, talk to is etc
[18:36] <lifeless> next week :)
[18:36] <lifeless> Ursinha: I'd love it if this were documented well enough that losas can operate it easil
[18:36] <lifeless> y
[18:37] <Ursinha> access to lpqateam?
[18:37] <Ursinha> I can arrange that
[18:37] <lifeless> access + instructions
[18:37] <lifeless> how to deploy
[18:37] <lifeless> how to do an on-demand run
[18:37] <lifeless> where it logs
[18:38] <Ursinha> I'll do that
[18:38] <lifeless> \o/ thanks
[18:38] <Ursinha> as you gave me such detailed information, it's half written already :)
[18:38] <Ursinha> thanks for your time lifeless
[18:39] <lifeless> Ursinha: oh, perhaps we've confused each other - I was talking about qatagger operation - I expect deployment requests to come from devs always.
[18:39] <Ursinha> ah
[18:39] <Ursinha> sure :)
[18:39] <lifeless> Ursinha: although I'm happy if you're writing up the deployment request stuff too.
[18:39] <lifeless> I thought it was already on the wiki, let me have a look
[18:40] <lifeless> huh, no its not
[18:41] <lifeless> downtime deploys are, but a bit sketchily
[18:45] <Ursinha> lifeless, where?
[18:46] <lifeless> mergeworkflow page
[20:07] <jcsackett> is there a compelling reason to not move canonical.launchpad.validators to lp.services.validators or similar?
[20:24] <thumper> jcsackett: no
[20:24] <thumper> no reason at all
[20:24] <thumper> jcsackett: they could though go to lp.app.validators
[20:24] <thumper> which I think would be more fitting
[20:25] <thumper> they are more a core part of the app than a service
[20:25] <jcsackett> thumper: agreed, that's a much better place.
[20:37] <thumper> leonardr: want to chat on mumble about the series work?
[20:38] <leonardr> thumper, sure
[20:38] <leonardr> let me push what i have
[20:39] <leonardr> lp:~leonardr/launchpad/publish-distro-series-for-recipe
[20:49] <lifeless> sinzui: around ?
[20:49] <lifeless> sinzui: I've been thinking about your javascriptified batch navigator
[20:50] <leonardr> https://bugs.launchpad.net/lazr.restful/+bug/723753
[20:50] <_mup_> Bug #723753: defaulting to exporting new web service methods on all web service versions makes web service mistakes dangerous <lazr.restful:Triaged> < https://launchpad.net/bugs/723753 >
[20:51] <leonardr> thumper:
[20:51] <leonardr> you can say whether or not a field is published in the very first version
[20:51] <leonardr> with exported(field, exported=False)
[20:51] <leonardr> or exported(field, exported=True)
[20:52] <leonardr> we could change it so that the value was the first version in which it's exported
[20:52] <leonardr> or exported(field, exported="devel")
[20:52] <leonardr> or add a new argument exported_as_of
[20:52] <sinzui> lifeless: I just got back from picking up my children
[20:52] <sinzui> I can talk
[20:52] <lifeless> sinzui: cool
[20:52] <lifeless> sinzui: I'm wondering about two things
[20:52] <lifeless> admist eathquakes
[20:53] <lifeless> sinzui: should we teach batchnavigator to handle sparse batches
[20:53] <lifeless> (the first, last 40 thing that bugs do)
[20:54] <lifeless> sinzui: and how much work would javascriptifying the batch navigator be
[20:55] <sinzui> lifeless: I do not know if there is a lot of gain for that. We talked a little about that with google page results, but did not pursue it since google does not promise there really will be another batch
[20:55] <sinzui> I am strongly in favor of ajaxing the batch navigator.
[20:55] <lifeless> thirdly (monty python count to 2 :P)
[20:56] <lifeless> there is this thing about 'only show the comment form if the user has read relevant messages'
[20:56] <lifeless> where a proxy metric for relevant messages is pretty poor at the moment
[20:56] <sinzui> That seems like a difficult assertion to make on a user
[20:56] <lifeless> indeed
[20:57] <lifeless> but thats why it doesn't show always
[20:57] <sinzui> oh?
[20:57] <lifeless> yeah
[20:57] <lifeless> its so nice that bug one renders now
[20:57] <lifeless> https://bugs.launchpad.net/ubuntu/+bug/1
[20:57] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
[20:58] <lifeless> note that there is no comment form at the bottom of the page
[20:58] <sinzui> I surmised.
[20:58] <lifeless> if you click add a comment, it tries to load every comment
[20:58] <sinzui> I worked on a site once that put a timer on the submit button to encourage users to read what was above it
[20:58] <lifeless> but its nonsense to argue that this stops poor comments, because if there are 200 comments, what inexperienced user will read them all
[20:58] <lifeless> let alone 400, or 1000
[20:59] <lifeless> so I think I'm thinking alone these lines:
[20:59] <lifeless>  - short term and long term
[20:59] <lifeless> short term:
[21:00] <lifeless>  - stop showing first 40, last 40, instead show first 100 in a standard batch navigator
[21:00] <lifeless>  - if we're on the last batch, show the comment widget
[21:00] <lifeless> medium term:
[21:00] <lifeless>  - ajaxify the navigator, and unhide the comment widget at the end of the batch
[21:00] <lifeless> long term:
[21:01] <lifeless>  - some mechanism for really relevant / important comments (e.g. 'do not comment on this bug. File a new one if you have battery problems, no matter how similar you think it is') so that they are more visible/likely to be read.
[21:01] <lifeless> [this may imply nested conversations, a voting system, or some other stuff]
[21:02] <sinzui> Does someone really need to see the beginning  or middle of a conversation started 6 years ago. epic bugs needs a summary of the story so far, the current batch of comments (the last page I suppose) and provide a link to see the hirstorical record
[21:03] <lifeless> sinzui: I don't know. Certainly we could start on the last page not the first and let people walk back
[21:03] <lifeless> sinzui: for summary of story so far, folk should edit the description
[21:03] <lifeless> sinzui: the historical record should be done via batching/incremental display - its just to big to do quickly in one request.
[21:04] <sinzui> lifeless: yes that is why we can edit the description
[21:04] <lifeless> sinzui: sounds like we're in agreement
[21:07] <sinzui> lifeless: I think so. would like short term should start on the last page, but I think that could be medium term if it is costly to know we have more than a reasonable number of messages
[21:07] <sinzui> That is a bad edit
[21:07] <lifeless> we can do last page equally easily
[21:08] <lifeless> I was showing a preconception by suggesting first 100 rather than last 100
[21:18] <StevenK> lifeless: So staging is still broken?
[21:18] <thumper> StevenK: mumble?
[21:19] <StevenK> th	Aye, sec
[21:28] <LPCIBot> Project db-devel build (391): STILL FAILING in 5 hr 24 min: https://hudson.wedontsleep.org/job/db-devel/391/
[21:28] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12436,
[21:28] <LPCIBot> 12437 included.
[21:33] <thumper> https://bugs.launchpad.net/launchpad/+bug/682516
[21:33] <_mup_> Bug #682516: No link to recipes for packages <lp-code> <recipe> <Launchpad itself:Triaged> < https://launchpad.net/bugs/682516 >
[21:36] <huwshimi> Morning
[21:36] <leonardr> thumper: https://bugs.edge.launchpad.net/lazr.restful/+bug/723959
[21:36] <_mup_> Bug #723959: Separate the floating "latest" version from the latest version-in-progress <lazr.restful:New> < https://launchpad.net/bugs/723959 >
[21:36] <StevenK> Moaning
[22:02] <wgrant> lifeless: yes, but heat updating is insane, but it's not *that* insane. Copies only update the head of the bugs that they close, then calculate the max heat of the source package.
[22:03] <lifeless> wgrant: well
[22:03] <lifeless> you might think so
[22:03] <wgrant> It's still thoroughly ridiculous.
[22:03] <lifeless> but it would be a lie
[22:03] <lifeless> this is what they calculate:
[22:03] <wgrant> But not utterly ridiculous.
[22:03] <lifeless> Max(Bug.heat), Sum(Bug.heat), Count(Bug.id))
[22:04] <wgrant> Right, but it's not recalculating each bug's heat.
[22:04] <lifeless> no, but its querying it
[22:04] <lifeless> this pages every distro series source package bug in the context in
[22:04] <wgrant> Right.
[22:05] <lifeless> this is that insane.
[22:05] <lifeless> reading in 400000 bugs is not a good idea.
[22:06] <lifeless> [yes its filtered to open status, but it may still be doing a seq scan. I'll need to check]
[22:08] <wgrant> I'm of the opinion that bug heat in general is insane, and this is not significantly less sane than the rest of it.
[22:08] <lifeless> bug heat has lots of room for improvement, thats true.
[22:13] <jml> build is broken.
[22:17] <lifeless> jml: windmill timeout
[22:18] <lifeless> build forced
[22:19] <jml> lifeless: thanks.
[22:23] <lifeless> meepe
[22:23] <lifeless> bugs with 300 attachments
[22:33] <sinzui> wgrant: mumble?
[22:38] <lifeless> reference = 'Making output directory...\n'
[22:38] <lifeless> actual = "Making output directory...\nException IndexError: IndexError('list index out of range',) in <bound method _LockWarner.__del__ of <bzrlib.lockable_files._LockWarner object at 0x1378e290>> ignored\n"
[22:39] <lifeless> forced
[22:39] <StevenK> lifeless: Latest build failure looked like Sphinx to me?
[22:39] <StevenK> Ah
[22:42] <jcsackett> wgrant: bug 723274; set it fix committed/released whatevs as appropriate. it's been assigned to you.
[22:42] <_mup_> Bug #723274: Bug status changes to unknown when upstream status changes to dupe <bugwatch> <trivial> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/723274 >
[22:44] <wgrant> jcsackett: Thanks.
[22:44] <StevenK> wgrant: I can't see a recent landing from you that enabled logging commits?
[22:45] <lifeless> 4.8 seocnds in structural subscriptions
[22:45] <wgrant> StevenK: It was a side-effect of the ZTM refactor that I thought might affect a lot. But the test suite suggested that only a couple of tests didn't already pass a transaction in. Which might mean that we have an isolation issue.
[22:47] <wgrant> StevenK: See the lib/canonical/launchpad/webapp/adapter.py diff in r12418
[22:47] <StevenK> wgrant: I'm concerned that I tossed 2 branches at ec2 yesterday, with roughly 2 hours between them -- 1 passed completly and 1 failed
[22:48] <wgrant> StevenK: You've seen this error on ec2?
[22:49] <lifeless> gary_poster: hi
[22:49] <StevenK> wgrant: Yes, it failed for one of the branches, but also fails locally
[22:49] <lifeless> gary_poster: heads up on a bug that may be a side effect of, or related to your current project
[22:49] <lifeless> https://bugs.launchpad.net/launchpad/+bug/723999
[22:49] <_mup_> Bug #723999: structural subscriptions taking 4.8 seconds during nomination editing POST <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/723999 >
[22:50] <wgrant> StevenK: Was the test order different between the success and the failure?
[22:52] <lifeless> wgrant: do you have a branch working on bugtask:+index person late evaluation ?
[22:53] <StevenK> wgrant: Yes
[22:54] <wgrant> lifeless: I have a fix for the one-person-query-per-visible-comment one.
[22:54] <wgrant> I was going to put more in there. But maybe I should just land it.
[22:54] <wgrant> StevenK: What changed? Everything?
[22:54] <lifeless> wgrant: just land it, or I'll be colliding with you
[22:55] <StevenK> wgrant: "Some". I'm checking with a naive diff, and that has 400 lines different
[22:55] <wgrant> lifeless: If you have a related branch, you might as well take my 6 character fix.
[22:55] <lifeless> wgrant: paste it somewhere then
[22:55] <lifeless> or push o rwhatever
[22:55] <lifeless> bbiab, lunch breaking
[22:56] <wgrant> lifeless: http://paste.ubuntu.com/571411/
[23:20] <gary_poster> lifeless, ack, thanks for heads up.  It is certainly related one way or another, and I'll add the bug to the story and to the kanban board.
[23:22] <lifeless> gary_poster: thanks
[23:22] <thumper> ec2 error ?!?! ImportError: No module named pqm.pqm_submit
[23:23] <thumper> anyone know what is going on?
[23:23] <jcsackett> thumper: oh thank goodness it's not just me.
[23:23] <jcsackett> no idea what's going on, but i finally just threw a branch to ec2 test b/c ec2 land was failing with that msg.
[23:24] <thumper> hmm...
[23:24]  * thumper does ec2 test
[23:24] <wgrant> Do you have bzr-pqm installed?
[23:25] <wgrant> There was a launchpad-dependencies update last night which may have gone fairly wrong.
[23:26] <thumper> wgrant: I do
[23:26] <jcsackett> me too.
[23:26] <thumper> wgrant: it is the ec2 image
[23:27] <StevenK> thumper: Which number did it use?
[23:27]  * thumper looks
[23:27] <thumper> Using machine image version 508
[23:27] <wgrant> Oh, in the image?
[23:27] <wgrant> There was a new one of those last night too.
[23:28] <StevenK> My two landings yesterday used 507. Hmmm, perhaps 508 is busted
[23:28] <wgrant> Remove jtv's ID from the list, I guess.
[23:28] <jml> ok. now I'm really gone for the day
[23:29] <lifeless> ciao
[23:29] <jml> have a super wednesday
[23:29] <wgrant> Night jml.
[23:29] <jml> please fix all of the critical bugs.
[23:29] <lifeless> I Can Has Fix ?
[23:29] <jml> Thursday, I mean.
[23:29] <lifeless> wgrant: -lol-
[23:30] <wgrant> lifeless: Yes.
[23:30] <wgrant> lifeless: Terribly difficult.
[23:31] <lifeless> wgrant: did you spot load_people
[23:32] <StevenK> Bad server!
[23:35] <wgrant> lifeless: I didn't.
[23:38] <lifeless> wgrant: I suspect we're going to be coming back to it
[23:40] <lifeless> wgrant: so this 6 character fix is easy
[23:40] <lifeless> I wonder how many others are like this
[23:44] <lifeless> this hsould drop bug 1 with all comments down to 200 queries.
[23:44] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
[23:44] <lifeless> theres some poor python scaling in there
[23:46] <wgrant> lifeless: Huh? It's at like 490 for only 40 comments.
[23:46] <wgrant> This will take it down to 450 for 40.
[23:48] <wgrant> lifeless: Could you mentor https://code.launchpad.net/~jameinel/launchpad/loggerhead-disconnect-701329/+merge/48665?
[23:49] <StevenK> wgrant: So, in regards to test_source_query_counts, I should re-ec2?
[23:50] <lifeless> wgrant: there https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1880N2148
[23:50] <lifeless> wgrant: 309 reps of j-i-t person lookup on comments=all
[23:50] <lifeless> wgrant: thats 80 comments in your metric, not 40.
[23:51] <wgrant> StevenK: Could you send me both subunit logs?
[23:51] <wgrant> lifeless: Fair point.
[23:51] <wgrant> 40 on each end.
[23:51] <lifeless> if the commenters are distinct, 80 less
[23:51] <lifeless> but they aren't
[23:51] <wgrant> lifeless: Note that lots of those people are not comment lookups, I suspect.
[23:52] <StevenK> wgrant: wget http://people.canonical.com/~stevenk/{less-lazr-security-r12400.subunit.gz,link-recipe-on-ppa-page-r12407.subunit.gz}
[23:52] <lifeless> wgrant: select count(distinct message.owner) from bugmessage,message where bug=1 and bugmessage.message=message.id;
[23:52] <lifeless>  count
[23:52] <lifeless> -------
[23:53] <lifeless>    535
[23:53] <wgrant> Hmm. That's odd.
[23:54] <wgrant> No manual entry for subunit-diff
[23:54] <wgrant> Gr.
[23:54] <StevenK> steven@liquified:~% subunit-diff --help
[23:54] <StevenK> steven@liquified:~%
[23:55] <wgrant> Yes.
[23:55] <lifeless> thats jelmers perl special
[23:55] <StevenK> And lifeless doesn't believe me when I tell him the subunit tools are as user-friendly as git
[23:55] <lifeless> I would like it to be done in python
[23:55] <lifeless> jelmer: ^ confusion ftw
[23:55] <lifeless> however its better to have it than not
[23:56] <wgrant> True.
[23:56] <wgrant> Didn't do exactly what I wanted, but was still handy.
[23:56] <jelmer> lifeless: I might redo it in python at some point
[23:56] <StevenK> jelmer: Or write some help!
[23:56] <StevenK> Or some *roff!
[23:58] <jelmer> I am looking forward to the day I can write more *roff