[00:01] <wallyworld> sinzui: stupid mic
[00:02] <sinzui> wallyworld: I had to toggle mute on Sound Preferences > Input. Even though it said it was on, the live check clear said it was not
[00:03]  * wallyworld tries that
[00:05] <wallyworld> sinzui: here but mic still broken
[00:08]  * sinzui is now deafened
[00:18] <lifeless> we should do a ndt today
[00:22] <wgrant> lifeless: I plan to, once I attack staging.
[00:22] <wgrant> importds need QA.
[00:22] <lifeless>  oh cool
[00:22] <wgrant> Then I need to remerge db-stable.
[00:26] <StevenK> WebCat sounds like a fun project
[00:32] <StevenK> utilities/shhh.py bin/sprite-util create-css
[00:32] <StevenK> Traceback (most recent call last):
[00:32] <StevenK> ...
[00:32] <StevenK> KeyError: u'../images/mute.png'
[00:32]  * StevenK pouts.
[00:35] <jcsackett> wallyworld: so, what's the bit that needs dealing with picker wise?
[00:35] <wallyworld> jcsackett: sent you an email :-)
[00:35] <jcsackett> ah, fantastic.
[00:35] <wallyworld> just move a coupl eof line sof js
[00:36]  * jcsackett wades through codeimport emails to find the relevant one.
[00:36] <wallyworld> jcsackett: i have code impor temails go to /dev/nul :-)
[00:38] <wgrant> StevenK: rm ./lib/canonical/launchpad/icing/icon-sprites.positioning
[00:39] <jcsackett> wallyworld: that definitely fits within the scope of what i'm working on now. i'll incorporate it into my personpicker-fixes branch.
[00:39] <wallyworld> jcsackett: thanks :-)
[00:39] <jcsackett> wallyworld: you're welcome.
[00:40] <StevenK> wgrant: Thanks
[01:02] <StevenK> And another 113 code import mails :-(
[01:20] <huwshimi> StevenK: That's what mail filters are for
[01:21] <StevenK> Yes, I just fixed sieve
[01:21] <StevenK> I think it's working, too.
[01:40] <wgrant> jelmer: Still around?
[01:40] <jelmer> wgrant: barely
[01:40] <wgrant> jelmer: http://staging.launchpadlibrarian.net/72500040/vcs-imports-virt-manager-trunk.log
[01:41] <wgrant> Something to worry about?
[01:41] <jelmer> wgrant: somewhat - I tagged one of the bugs associated with the newer-bzr branch qa-bad for this reason
[01:42] <lifeless> jelmer: qa-bad meaning 'must rollback'
[01:42] <wgrant> At this stage it is more "must panic"
[01:43] <lifeless> yup
[01:43] <lifeless> so, rollback that rev.
[01:43] <wgrant> jelmer: How critical is this?
[01:43] <wgrant> Can we just roll back bzr-hg, or do we have to do the whole thing?
[01:43] <wgrant> I guess the whole thing.
[01:43] <lifeless> rollback the lot, its simplest.
[01:43] <lifeless> known good.
[01:43] <jelmer> wgrant: the whole thing, the older bzr-hg won't work (at least isn't tested) with the older bzr
[01:44] <wgrant> OK, rolling back.
[01:44] <wgrant> Thanks.
[01:44] <wgrant> buildbot is even waiting for us.
[01:44] <lifeless> \o/
[01:44] <StevenK> Hah
[01:44] <wgrant> Although we'll just miss the following db-devel run.
[01:44] <wgrant> So QA will be this evening.
[01:45] <wgrant> What else can go wrong...
[01:45] <wgrant> Build breakage, qastaging breakage, staging breakage, three RC revs, two bad revs, major QA backlog
[01:45] <lifeless> 8000000 estimated plans make me cry
[01:46] <wgrant> + deploying a big new feature at the same time
[01:46] <lifeless> well
[01:46] <lifeless> shortly after
[01:46] <lifeless> I agree, it would be nice not to have it bundled in
[01:47] <lifeless> wgrant: you redid the tag portlet queries recently right ?
[01:47] <wgrant> lifeless: Yes.
[01:47] <wgrant> They still suck.
[01:47] <lifeless> https://bugs.launchpad.net/launchpad/+bug/793809
[01:47] <_mup_> Bug #793809: Distribution:+bugtarget-portlet-tags-content timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/793809 >
[01:47] <wgrant> Will need bugsummary.
[01:47] <wgrant> (which is in!)
[01:47] <lifeless> yes
[01:47] <lifeless> I'm hacking on that now
[01:47] <wgrant> Fantastic.
[01:47] <lifeless> just gthering data on th ecurrent behaviour
[01:47] <wgrant> jelmer: Do you have a bzr-hg bug for that?
[01:49] <lifeless> (actual time=0.164..0.164 rows=1 loops=323890)
[01:49] <lifeless> what is 0.16ms * 300K :P
[01:50] <jelmer> wgrant: bug 793812
[01:50] <_mup_> Bug #793812: doesn't lock target repository when reading tags during fetch <affects-launchpad> <Bazaar Hg Plugin:In Progress by jelmer> < https://launchpad.net/bugs/793812 >
[01:51] <wgrant> jelmer: Hm, weren't tags not supported before?
[01:51] <wgrant> So this will only affect branches that were already broken?
[01:51] <jelmer> wgrant: tags were ignored before, and *most* of these branches were not working earlier
[01:52] <StevenK> lifeless: 48 seconds?
[01:52] <wgrant> Hmmmm.
[01:52] <wgrant> lifeless: Perhaps we should not roll back.
[01:52] <wgrant> Given that we can roll out to the importds later fairly easily.
[01:52] <jelmer> wgrant: (hence my answer "somewhat" to your question earlier; the risk is that there's a couple of branches out there that were previously working that have tags)
[01:53] <lifeless> StevenK: yes, and thats what bug privacy costs us
[01:54] <lifeless> jelmer: wgrant: I'm fine with saying that this only affects previously broken branches
[01:54] <lifeless> but in that case its not qa-bad
[01:54] <lifeless> its qa-ok
[01:54] <wgrant> lifeless: It looks like it will break some existing branches.
[01:54] <lifeless> fsvo some
[01:54] <wgrant> But bzr-hg is still beta.
[01:54] <wgrant> Well.
[01:54] <wgrant> It looks like there are 15 succeeding bzr-hg branches.
[01:54] <wgrant> In all of LP.
[01:54] <wgrant> So it can't break more than 15 branches.
[01:54] <lifeless> some of them may have tags
[01:55] <StevenK> lifeless: "Orsum"
[01:55] <lifeless> jelmer: when do you think this will be fixed ?
[01:55] <jelmer> lifeless: tomorrow morning
[01:55] <lifeless> StevenK: see the plan in the bug I linked if you are interested
[01:55] <wgrant> I say we deploy with this, and rerelease to the importds on Friday or Monday.
[01:55] <lifeless> jelmer: wgrant: FWIW I wouldn't rollback given this analysis
[01:55] <wgrant> Right.
[01:55] <jelmer> Yeah, I agree.
[01:55] <wgrant> I was trying to convince you of that, but it seems it wasn't necessary.
[01:55] <wgrant> Great.
[01:56]  * mwhudson too, if anyone cares
[01:56] <wgrant> jelmer: You've tested the others?
[01:56] <jelmer> Sorry, I probably should've communicated that a bit better than just saying qa-bad and "somewhat"...
[01:56] <wgrant> bzr-git seems happy, but I've not tried bzr-svn.
[01:56] <wgrant> Heh.
[01:56] <wgrant> It's late :)
[01:56] <jelmer> I've tried bzr-svn and bzr-git
[01:57] <wgrant> jelmer: qa-bad today means zomgpanic, since we have downtime in <48 hours.
[01:57] <jelmer> wgrant: I realize that, but I also didn't want to say qa-ok while it could break existing branches (I hadn't bothered looking at the graph yet)
[01:57] <wgrant> Yep.
[01:57] <wgrant> Heh.
[01:58] <wgrant> jelmer: Should we qa-ok all the bugs?
[02:00] <jelmer> wgrant: yep
[02:01] <wgrant> Hopefuly 13162 is good.
[02:04] <lifeless> wgrant: btw, a window function eliminates the union
[02:04] <wgrant> lifeless: Oh?
[02:04] <wgrant> How?
[02:05] <lifeless> tag in (official) or rank() < 10, or something like that
[02:05] <lifeless> I won't need to do it
[02:05] <wgrant> Hmm, true.
[02:05] <lifeless> just noting another technique we could use to tune further
[02:08] <lifeless> (49 rows)
[02:08] <lifeless> Time: 595.781 ms
[02:08] <wgrant> Nice.
[02:09] <lifeless> thats for distro=1
[02:10] <lifeless> https://bugs.launchpad.net/launchpad/+bug/793809/comments/3
[02:10] <_mup_> Bug #793809: Distribution:+bugtarget-portlet-tags-content timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/793809 >
[02:27] <cjohnston> wgrant: thanks for looking at my qa-needstesting's
[02:28] <StevenK> cjohnston: Hah. wgrant looks at *everyone's* qa-needstesting's revisions :-)
[02:28] <cjohnston> lol
[02:29] <cjohnston> in that case, there's still one pending.. lol
[02:29] <StevenK> cjohnston: He couldn't possibly steal all of your fun.
[02:39] <wgrant> cjohnston: I'm waiting on a script to run on qastaging.
[02:39] <cjohnston> :-)
[02:39] <wgrant> hloeung: How's send-bug-notifications.py going?
[02:39] <hloeung> wgrant: Still going... and going... and going...
[02:40] <wgrant> hloeung: Is branchmail eating the CPU or something?
[02:40] <StevenK> I had no idea send-bug-notifications.py was the energizer bunny
[02:40] <wgrant> I see nothing new in the inbox.
[02:41] <hloeung> wgrant: err, I'm seeing it print out lots of "Notifying <email@address> about bug XXXXXX" being displayed on my screen
[02:42] <wgrant> Ah, yes, Thunderbird was just being slow.
[02:44] <hloeung> It's not just the branchmail, there's quite a few jobs running right now
[02:44] <hloeung> so yes, the load is pretty high on that server
[02:44] <wgrant> :(
[02:48] <StevenK> hloeung: Define pretty high? 10? 50?
[02:49] <hloeung> StevenK: anything over 10 is high for me, and it's at 12
[02:52] <LPCIBot> Project windmill-db-devel build #369: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill-db-devel/369/
[03:48] <wgrant> StevenK: Can I have mawson?
[03:48] <StevenK> wgrant: Take it, I'm done with it until after lunch.
[03:48] <wgrant> Thanks.
[03:51] <wgrant> lifeless: We are green.
[03:51] <wgrant> Shall we unfreeze?
[03:57] <wgrant> wallyworld: The pickers are healthy when the flags are all disabled?
[03:57] <wallyworld> wgrant: afaik
[03:58] <wgrant> wallyworld: Great.
[03:58] <wallyworld> i last tested that a day or two ago
[03:58] <wallyworld> but there have been code changes since
[03:58] <wgrant> Yeah,.
[03:58] <wgrant> I'll check once hloeung's back.
[03:58] <wgrant> By disabling them on qas.
[03:58] <wallyworld> i think prod has an earlier version deployed that is fine
[03:58] <wgrant> Yeah.
[03:58] <wgrant> But that's about to change.
[03:59] <wgrant> Well, the earlier version thing is about to change. The fineness hopefully won't.
[03:59] <wallyworld> i tested when i put in support for the result ordering to be behind a flag
[03:59] <wgrant> But we've had lazr-js changes and such since.
[04:00] <wallyworld> yes, but the lazr-js changes don't use a ff
[04:00] <wgrant> So they are more likely to break even when the FF is off.
[04:00] <wallyworld> lazr-js will use json attributes if they are there, which they won't be if the ff is off
[04:01] <wgrant> Sure. But this is Launchpad.
[04:01] <wgrant> I'm still going to test it :)
[04:01] <wallyworld> ok
[04:01] <lifeless> wgrant: fully, really ?
[04:01] <wgrant> lifeless: Hm?
[04:02] <wgrant> Oh, QA? Yes.
[04:03] <wgrant> Both are fully green.
[04:04] <lifeless> \o/
[04:04] <lifeless> daaaaploy
[04:04] <wgrant> Already requested.
[04:04] <lifeless> love your work
[04:04] <wgrant> Will do it and unfreeze and remerge once hloeung is delunched.
[04:04] <wgrant> Heh.
[04:06] <lifeless> garrrr
[04:06] <lifeless> storm reference columns paaaain
[04:07] <wgrant> Yes.
[04:16] <wgrant> ~/launchpad/lp-branches/devel$ bzr diff -c13163 | wc -l
[04:16] <wgrant> 20211
[04:16] <wgrant> D:
[04:26] <lifeless>  lib/lp/bugs/doc/bug-tags.txt
[04:26] <lifeless>   Ran 1 tests with 0 failures and 0 errors in 0.679 seconds.
[04:26] <lifeless> \o/
[04:34] <lifeless> wgrant: (48 rows)
[04:34] <lifeless> Time: 165.065 ms
[04:34] <wgrant> lifeless: Where'd the 49th row go?
[04:35] <wgrant> And the other 340ms.
[04:35] <lifeless> I had forgotten we aggregate up by sourcepackagename
[04:35] <lifeless> so it was counting a few hundred K rows too many
[04:35] <wgrant> Ahh
[04:38] <lifeless> the extra row was apport-collected
[04:38] <lifeless> not sure why its gone, looking
[04:41] <lifeless> is there with spn is null
[04:41] <lifeless> my theory - it was 11th with the duplicates fixed.
[04:41] <lifeless> because its /all/ source package targeted bugs it had 100% inflation
[04:42] <wgrant> Ahh
[04:42] <wgrant> That could do it, I guess.
[04:43] <lifeless>  3626
[04:43] <lifeless> (null)
[04:43] <lifeless> and
[04:43] <lifeless>  3869
[04:43] <lifeless> (not null)
[04:43] <lifeless> discrepancy handwaved away by multi-task bugs
[04:43] <lifeless> that takes its count to 7K
[04:44] <lifeless> and that was 10th place
[04:44] <lifeless> hmm,t hats ever
[04:44]  * lifeless checks with open
[04:45] <lifeless> 2100
[04:48] <lifeless>  rank |          tag           |  sum
[04:48] <lifeless> ------+------------------------+-------
[04:48] <lifeless>     1 | i386                   | 34609
[04:48] <lifeless>     2 | apport-crash           | 29323
[04:48] <lifeless> ...
[04:48] <lifeless>    14 | apport-collected       |  2003
[04:50] <michaelh1> Hey, the 'Packaging/SourceBuildsdaily builds knowledge base' link at the bottom of 'https://help.launchpad.net/Packaging/SourceBuilds/BzrBuilder' is broken.  I can't seem to log in to fix it...
[04:55] <lifeless> can has review ? https://code.launchpad.net/~lifeless/launchpad/bug-793809/+merge/63635
[04:55] <wgrant> michaelh1: login attempts seem to hang for me :/
[04:55] <lifeless> sso is having trouble probably; we have a bug open on that
[04:56] <wgrant> Ah, finally worked.
[04:58] <wgrant> michaelh1: Fixed, thanks.
[04:59] <michaelh1> Ta
[05:09] <hloeung> wgrant: You called?
[05:10] <wgrant> hloeung: Hi! Three things:
[05:11] <hloeung> okay, hit me
[05:11] <wgrant> 1) Could you please bring PQM out of RC mode (I think both devel and db-devel are RC at the moment)?
[05:12] <wgrant> 2) Could you remove the disclosure.picker_enhancements.enabled feature rule from qastaging, so we can test how it will behave on production without it tomorrow?
[05:12] <wgrant> 3) There's a nodowntime deployment request on LPS, to deploy all the stuff before the db-stable merge.
[05:17] <wgrant> lifeless: Reviewed.
[05:20] <lifeless> wgrant: dunno whats wrong with the indentation
[05:20] <jtv> wgrant: if I have a PackageUpload pu, and I do pu.addSource(…), should that be enough to make contains_source become True?
[05:21] <wgrant> jtv: Yes.
[05:21] <wgrant> jtv: Minus caches, but there might not be any.
[05:21] <wgrant> lifeless: Multi-line function calls are meant to be indented like this:
[05:21] <wgrant> something(
[05:21] <wgrant>     foo, bar)
[05:21] <wgrant> Not
[05:21] <wgrant> something(foo,
[05:21] <wgrant>     bar)
[05:22] <wgrant> And multi-line function definitions are to be indented like:
[05:22] <wgrant> def something(foo,
[05:22] <wgrant>              bar)
[05:22] <wgrant> I forgot a space.
[05:22] <wgrant> But you get the idea.
[05:22] <lifeless> problem is both of those are fugly.
[05:23] <lifeless> you'll find indenting like I did already present in the code base
[05:23] <lifeless> -> vet, back soon
[05:25] <wgrant> lifeless: Hm, I think the postgres planner needs a good killing.
[05:25] <jtv> Nice argument there: the same person who won't listen to his reviewer and created optional reviews says "I can do it the way I like because we already have places where it's done that way."  :-)
[05:26] <wgrant> Heh.
[05:29] <jtv> What's the problem with the postgres planner?
[05:29] <wgrant> jtv: See the last comment in the MP.
[05:29] <wgrant> https://code.launchpad.net/~lifeless/launchpad/bug-793809/+merge/63635
[05:31] <jtv> The answer to that is not killing the planner.
[05:31] <wgrant> It would help.
[05:32] <jtv> No it wouldn't — then we'd have to hand-tune _every_ query at the cost of legibility.
[05:32] <jtv> What Robert mostly uses WITH for AFAICS is as a new optimization barrier.
[05:32] <wgrant> Yeah.
[05:32] <StevenK> I was tempted to read the slides about the query planner from the last Postgres meetup, but I chickened out
[05:34] <jtv> It's just an ever-shifting battleground: we find we can get a query faster (at least for the cases we're looking at) by making it too hard for the optimizer to restructure.
[05:34] <jtv> Then the optimizer gets smarter, and most queries get faster — but it breaks that trick.
[05:34] <jtv> The fights over planner hints are endless.
[05:36] <jtv> Even though the decision is already made: we're not going to have them.
[05:36] <wgrant> Heh.
[05:36] <wgrant> Yay, I can self-review now.
[05:36] <StevenK> But you have been for months with rs=wgrant
[05:37] <StevenK> Or was I not supposed to point that out?
[05:37] <wgrant> That was always for testfixes/merges.
[05:37] <wgrant> No new code :)
[05:37] <wgrant> But yes, shh.
[05:39]  * jtv worriedly pretends he had not heard that
[05:41] <wgrant> Hmm.
[05:41] <wgrant> Pickers with dozens of pages look a bit bad.
[05:41] <wgrant> But it'll do.
[05:41] <wgrant> eg. search for 'launchpad' in the product picker on https://bugs.qastaging.launchpad.net/launchpad/+bug/1234
[05:41] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 >
[05:42] <jtv> This is a bit of python syntax I'm still missing: the "if" clause from list comprehensions, but without the "for"
[05:42] <jtv> Names = [self.name if self.name is not None]
[05:43] <wgrant> Yes :(
[05:44] <wgrant> filter()'s deprecation upset me.
[05:44] <wgrant> Same with map().
[05:44] <jtv> Those have been deprecated!?
[05:44] <StevenK> What jtv said?!
[05:44] <jtv> Surely that's only in MS Python.NET enterprise?
[05:45] <jtv> Or some other thing that we don't care about?
[05:45] <wgrant> Hm, looks like they weren't actually killed from py3k. There were going to be at one point.
[05:45] <jtv> Phew.  So their obsolescence was deprecated?
[05:46] <wgrant> map/filter appear to be iterators in py3k, though.
[05:49] <jtv> That makes more sense.
[05:50]  * jtv dreams for a moment about the cool vectorizations we could have if this wonderful language were a compiled one
[05:50] <jtv> Then again, modern compilers can do that without it being explicit in the code can't they
[05:51] <wgrant> Yes :(
[05:54] <lifeless> -> vet, back soon]]]]]({{{{{kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkK0;2~")Y9;2~<GF[3;2~String formatting in SQL: Australia says no.
[05:54] <lifeless> Also, calling that "store" is a bit too much of a lie for my tastes.
[05:54] <wgrant> Did you forget to take the cat?
[05:54] <StevenK> Hahaha
[05:55] <StevenK> wgrant: Perhaps that was cat clawing despertly in a vain attempt to not be scooped up
[05:55] <wgrant> We can only hope!
[05:55] <lifeless> jtv: uhm, I do listen to reviewers - a lot.
[05:55] <jtv> Shhh you're spoiling it
[05:56] <StevenK> Never let the facts get in the way of a good punch line
[05:57] <wgrant> hloeung: PQM is indeed un-RC'd. Thanks.
[05:58] <hloeung> wgrant: How did you check? Just so I know in the future how to check
[05:58] <wgrant> hloeung: I landed something :/
[05:58] <hloeung> Oh hahah
[05:59] <lifeless> so, if you look at the query plans *we get*, the planner often treats exists / subqueries as things to run multiple times
[05:59] <wgrant> lifeless: Sure. But it should be smart enough to not do that.
[05:59] <lifeless> jtv: if you can find a way to get it to not do that, without a with, that would be cool.
[05:59] <wgrant> At least sometimes.
[05:59] <lifeless> AFAICT using WITH as a way to declare what is essentially a variable is good style SQL wise.
[05:59] <jtv> lifeless: I don't know of a way — I think it's one of those cases where it just wasn't the extra optimizer time.
[06:00] <jtv> Yes, it's fine.
[06:00] <wgrant> lifeless: Perhaps good style, but unconventional.
[06:00] <jtv> Well no, that's exactly what it's for.
[06:00] <wgrant> Right. But it's not very much.
[06:00] <wgrant> I've rarely seen it used.
[06:00] <wgrant> And it's ugly in Storm.
[06:00] <jtv> It's relatively new.
[06:00] <wgrant> Right. New => unconventional.
[06:00] <lifeless> wgrant: so, help make it better in storm?
[06:01] <lifeless> wgrant: unconventional in our code base perhaps.
[06:01] <wgrant> I've read enough horror stories in that MP.
[06:01] <jtv> The main "good" reason to use it is to remove such duplication.  The main practical reason is as an optimization barrier.
[06:01] <lifeless> anyhow, when storm is three times the size of direct queries, I really start to wonder why we use it.
[06:01] <jtv> How does it work in storm?
[06:01] <lifeless> jtv: see the use of with_ in https://code.launchpad.net/~lifeless/launchpad/bug-793809/+merge/63635
[06:02] <jtv> Ah, great to have that as a keyword isn't it?  :)
[06:03] <lifeless> yes (no)
[06:03] <lifeless> wgrant: so, I
[06:03] <lifeless> 've changed the browser/ indenting as its much of a muchness
[06:03] <lifeless> (though its still fugly)
[06:03] <wgrant> Not a muchness!
[06:03] <wgrant> Heh.
[06:03] <lifeless> the bug.py indent is really harder to read
[06:04] <wgrant> Oh?
[06:04] <lifeless> def foo............
[06:04] <lifeless>                            fwejijw
[06:04] <lifeless>     """.....
[06:04] <lifeless> dunno about you but that plays havoc with my eyes
[06:05] <wgrant> It's not ideal.
[06:05] <wgrant> But not much is.
[06:06] <lifeless> I can raise a discussion on list about this if you like, but this is the sort of thing I really hate about coding standards.
[06:06] <jtv> We've had that discussion.
[06:06] <StevenK> We have
[06:06] <lifeless> jtv: I don't think the discussion is over
[06:06] <jtv> I hate it too, but having the consistency and stability is probably more valuable than making it prettier in that case.
[06:06] <StevenK> Can the bikeshed not change colour again?
[06:07] <jtv> Exactly.
[06:07] <lifeless> StevenK: I've been consistently arguing one thing.
[06:07] <StevenK> lifeless: And you keep bringing it up because the bikeshed is a different colour, it seems.
[06:08] <lifeless> StevenK: no, I keep bringing it up because I have neither been convinced that the status quo is a good place to be, nor that what I am arguing for is a bad place to be.
[06:08] <StevenK> IOW, the bikeshed needs a new coat of paint
[06:08] <lifeless> or to not be a bikeshed
[06:09] <jtv> The great thing is, if we change it now, the people who argued the other way get their say again.
[06:09] <lifeless> hah
[06:10] <jtv> That can't be bad, right?
[06:10] <lifeless> interestingly PEP8 says we are wrong.
[06:10] <lifeless> not for function definitions
[06:10] <lifeless> but for function calls
[06:11] <lifeless> jtv: healthy discussion is fine.
[06:11] <StevenK> lifeless: In the words of the Debian Policy maintainers, why must we make hundreds (if not thousands) packages (read as: lines of code) insta-buggy?
[06:11] <lifeless> StevenK: you seem you have your troll hat on. Can you take it off please?
[06:11] <jtv> If healthy discussion is fine, by all means let's have more of it.  Now excuse me while I get some work done.
[06:12] <lifeless> so I was discussing this with my reviewer; the rest of you just piled in :)
[06:12] <StevenK> lifeless: Do I have to? :-(
[06:12] <jtv> lifeless: Because you didn't want to listen to your reviewer, which you deny.  Seriously, it's pretty clear to me that you're the one with the troll hat on today.
[06:16] <lifeless> right, breath taken.
[06:16] <lifeless> jtv: there is a huge difference between dialogue and instruction.
[06:17] <lifeless> jtv: if our reviewers are having a dialogue, then its up to the coder to listen and choose; making it an absolute must-be-X stops it being a dialogue and makes it instructions.
[06:17] <StevenK> lifeless: In my experience, reviewers can do either.
[06:18] <StevenK> lifeless: Must-be-X is usually of the form "That is horrid! *needs fixing*"
[06:19] <lifeless> I have been wondering whether removing that from reviewers entirely would help folk understand the cultural distinction
[06:20] <lifeless> I'm going to go off to the side and finish this specific discussion with wgrant, we can chew the fat about big picture stuff another time
[06:27] <wgrant> lifeless: Hm, so anybody can r-c bless truly r-c stuff now?
[06:27] <lifeless> yes
[06:28] <wgrant> Great.
[06:28] <wgrant> Makes sense.
[06:28] <lifeless> more centralised authority undone
[06:28] <wgrant> Yup.
[06:28] <lifeless> let folk -shock, horror- make decisions.
[06:28] <wgrant> Except for formatting :P
[06:28] <lifeless> I have a list.
[06:50] <wgrant> Eep.
[06:51] <lifeless> wgrant: ?
[06:51] <wgrant> An OOPS editing a bug.
[06:51] <wgrant> Trying to find it.
[06:53] <wgrant> I can't find CE anywhere...
[06:53] <wgrant> Ah, wampee's rsync config has changed.
[06:54] <wgrant> AssertionError: Attribute bug_subscribers not in object <BugTask for bug 97266 on <Product at 0xd8588d0>>
[06:54] <_mup_> Bug #97266: Suggestions menu next to "Choose..." doesn't do anything <javascrcipt> <lp-web> <project-picker> <qa-ok> <webkit> <Launchpad itself:Fix Committed by sinzui> < https://launchpad.net/bugs/97266 >
[06:54] <wgrant> Panic.
[06:54] <lifeless> ?!?!
[06:54] <lifeless> that seems undesirable
[06:54] <wgrant> OOPS-1984CE15
[06:55] <wgrant> Yes.
[06:55] <lifeless> HTH did it get through tests
[06:55] <wgrant> It doesn't affect all bugs.
[06:55] <wgrant> I bet it's the thing I've rolled back three times already.
[06:55] <wgrant> The dupe subscriptions muting thing.
[06:57] <wgrant> I guess one of getDirectSubscribers and getIndirectSubscribers is raising an AttributeError...
[06:57] <wgrant> Reproducible on qastaging, I guess we should roll back.
[06:57] <wgrant> And then panic.
[06:58] <lifeless> yup
[06:58] <wgrant> hloeung: Hi :(
[06:58] <hloeung> wgrant: Hi
[06:58] <lifeless> will this prevent unhiding the subscriptions feature?
[06:58] <wgrant> lifeless: It prevents deployment.
[06:58] <wgrant> Of anything.
[06:58] <wgrant> Hence panic.
[06:58] <lifeless> even after reverting the rev ?
[06:59] <wgrant> Ah. No, probably not. It's ugly, but not entirely critical.
[06:59] <wgrant> The issue is that there won't be a mute link if you only have a dupe subscription.
[06:59] <lifeless> we can deal for a few days lke that I think
[06:59] <wgrant> Possibly it must even be a team subscription to a dupe.
[06:59] <wgrant> Yes.
[06:59] <wgrant> hloeung: We need to roll back that deployment, I'm afraid.
[07:00] <hloeung> wgrant: okay sure, to what REVNO?
[07:00] <wgrant> hloeung: 13144, the previous nodowntime.
[07:00] <wgrant> lifeless: Fourth time lucky :/
[07:03] <hloeung> that last rollout actually had issues, not sure if it's related - https://pastebin.canonical.com/48230/
[07:04] <hloeung> neumayer rebooted itself
[07:04] <wgrant> hloeung: Not related, but still concerning.
[07:04] <wgrant> Ah...
[07:04] <wgrant> That's even more concerning.
[07:05] <lifeless> wgrant: I need to prep dinner
[07:05] <lifeless> I will drop by in a bit to touch base
[07:05] <wgrant> lifeless: Thanks, but it should be OK.
[07:09] <wgrant> I do wish we had a gary now.
[07:10] <hloeung> wgrant: https://pastebin.canonical.com/48232/
[07:11] <wgrant> hloeung: Hm, you're doing a full redeploy?
[07:11] <wgrant> hloeung: The deployment tool has an option to rollback to a previous rev.
[07:11] <wgrant> That's already built.
[07:11] <hloeung> oh?
[07:11] <wgrant> --rollback-to or somesuch... let me find it.
[07:12] <wgrant> 00:48 < mthaddon> Chex: should just be ./deploymgr.py --config=lp --revert-to-revno=XXXX lpnet edge
[07:12] <wgrant> But we want all of nodowntime this time.
[07:12] <wgrant> Note that the tree has to already be built.
[07:13] <wgrant> So it may be too late if you've already killed it.
[07:13] <wgrant> In which case we will have to recover from that conflict, which is easy enough.
[07:14] <wgrant> Grarrrrrr
[07:14] <wgrant> Conflicts reverting this.
[07:20] <hloeung> what should we do?
[07:20] <StevenK> Hm, perhaps the deployment manager should remove the sourcedeps.cache
[07:20] <wgrant> StevenK: More like we should fix the bug which makes it depend on dict ordering.
[07:20] <wgrant> But we have bigger crises than that right now.
[07:24] <wgrant> hloeung: Oh, sorry, missed that message.
[07:25] <wgrant> hloeung: is the old tree still present, so --revert-to-revno will work?
[07:25] <hloeung> where do I check?
[07:26] <wgrant> I'm... not sure. See if you can find the directories with revnos in them, and see if there's an existing one for r13144. Not sure whether it needs to be on prasé or everywhere else.
[07:26] <wgrant> deploymgr is still black magic to me.
[07:31] <hloeung> checked out a couple of servers and it looks to be there
[07:32] <wgrant> I guess try a --revert-to-revno and see if it works.
[07:32] <wgrant> I think it should.
[07:32] <wgrant> The tree should even still be on prasé, even though that shouldn't matter.
[07:33] <LPCIBot> Project windmill-devel build #177: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-devel/177/
[07:38] <wgrant> I guess we need to re-RC PQM :/
[07:39] <wgrant> Or we could just not bother, since we're sorta screwed either way.
[07:41] <hloeung> so cold today
[07:41] <wgrant> Yes :(
[07:43] <hloeung> Seems to be working
[07:43] <hloeung> soybean is back at 13144
[07:43] <hloeung> it's currently doin wampee
[07:43] <hloeung> *doing
[07:46] <wgrant> hloeung: Fantastic, thanks.
[07:46] <wgrant> Much quicker than a full rebuild, see :)
[07:46] <hloeung> definitely
[07:48] <wgrant> hloeung: I guess we should fix that conflict.
[07:48] <wgrant> Might as well just revert the whole tree, I guess.
[07:48] <wgrant> But I don't really know how that works...
[07:49] <hloeung> just leave it with me, I'll ask Tom when he gets online
[07:50] <hloeung> now what about pqm in RC mode? leave that as is?
[07:51] <wgrant> I guess we should put it back in RC, just in case. It's just about trivial.
[07:55] <lifeless> wgrant: hloeung: re-rc please
[07:55] <lifeless> may as well mitigate the damage
[07:55] <wgrant> Yeah.
[07:55] <hloeung> lifeless: okay!
[08:29] <LPCIBot> Project windmill-devel build #178: STILL FAILING in 43 min: https://lpci.wedontsleep.org/job/windmill-devel/178/
[08:40] <adeuring> good morning
[08:41] <jtv> hi adeuring
[08:42] <adeuring> hi jtv!
[08:55] <lifeless> jml`: guten morgen
[08:55] <jml`> lifeless: good morning
[08:55] <jml`> and good morning to all
[08:57] <jml`> huwshimi: good morning
[08:58] <huwshimi> jml`: Hello! Welcome back :)
[08:58] <jml`> thanks.
[08:58] <jml`> hmm
[08:58] <jml`> who's the other jml...
[08:58] <jml> there we go.
[08:58] <huwshimi> jml: Someone had to be you while you were gone
[08:59] <StevenK> Haha
[09:00] <jml> huwshimi: firing up skype now.
[09:02] <jml> huwshimi: I can hear you. gimme a sec.
[09:10] <mrevell> Good morning everyone.
[09:34] <wgrant> gmb: Dupe muting seems to be somewhat ill-fated :/
[09:35] <gmb> Yeah.
[09:35] <gmb> I feel like I'm stuck in a Python version of Groundhog Day.
[09:37] <jml> o/` Just put your little hand in mine... o/`
[09:52] <bigjools> jml is having a relapse
[09:53] <jml> ... back to Groundhog Day
[10:03] <jml> why might I get a bug task that has a closed status but a null date_closed?
[10:05] <lifeless> very old data?
[10:09] <jml> lifeless: Perhaps. the query is modified_since=2011-05-11, status=CLOSED_STATUSES
[10:09] <jml> lifeless: it's conceivable that an old bug was modified but not closed in that time
[10:09] <lifeless> bug # ?
[10:09] <jml> lifeless: I don't know.
[10:10] <lifeless> k
[10:10] <jml> afk for a bit.
[10:31] <lifeless> meep
[10:31] <lifeless> Bugs fixed elsewhere 125
[10:31] <lifeless> takes ~ 1 second to generate on its own
[10:31] <jml> lifeless: that's pretty bad.
[10:34] <danilos> though, if it took 1 second to fix 125 bugs elsewhere, that'd be pretty good
[10:34] <danilos> (not saying this is useful or relevant observation :)
[11:07] <lifeless> danilos: :P
[11:07] <lifeless> jml: it is
[11:08] <lifeless> jml: I'm wondering if its sufficiently useful to show a number at all
[11:08] <lifeless> jml: should we talk about the wiki briefly ?
[11:09] <jml> lifeless: some other day, if that's ok. I'd rather catch up on it via email along with all of the other stuff.
[11:10] <lifeless> sure
[11:10] <lifeless> I have done nothing
[11:10] <lifeless> on the basis that all my concerns are technical
[11:10] <lifeless> and we don't seem even close to that sort of discussion yet
[11:11] <lifeless> s/all my concerns/all the things I'm concerned about *and should be concerned aout*
[11:12] <jml> lifeless: yeah.
[11:12] <lifeless> jml: but perhaps us talking about it may help with scope or clarity. I dunno.
[11:13] <jml> lifeless: my main concern is giving these guys a fighting chance of actually helping with the wiki without smothering them in blockers. honestly, it's pretty low on my priority queue atm.
[11:14] <lifeless> jml: yes, there are some competing concerns here
[11:50] <LPCIBot> Project windmill-db-devel build #370: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill-db-devel/370/
[11:59] <LPCIBot> Project devel build #783: FAILURE in 5 hr 47 min: https://lpci.wedontsleep.org/job/devel/783/
[12:01] <gmb> Anyone got a spare minute to give me a review on https://code.launchpad.net/~gmb/launchpad/bug-61531/+merge/63672?
[12:32] <bigjools> wgrant: are you managing this rollout?
[12:37] <wgrant> bigjools: In no official sense, but I have done much of the preparation.
[12:38] <bigjools> wgrant: ok, do you know if db-devel 10648 should have been merged to devel?  It didn't make it since 10647 was merged
[12:40] <bigjools> not even sure why it landed there, they didn't change anything under database/
[12:41] <wgrant> bigjools: I remerged db-stable earlier.
[12:41] <wgrant> Up to 10651, IIRC.
[12:41] <bigjools> \o/
[12:41] <bigjools> which saves me a shitload of work!
[12:41] <wgrant> 10648 depended on stuff in db-devel.
[12:41] <wgrant> But only 10647 was on staging when I needed to do the first merge.
[12:42] <wgrant> Why?
[12:42] <bigjools> because I merged one too many revisions from db-devel yesterday and then did a load of work on top of that
[12:42] <wgrant> Ahh.
[12:42] <bigjools> see #bzr :)
[13:01] <danilos> gmb, fwiw, the Bug:+subscribe page doesn't offer mute functionality, you have to go to Bug:+mute page for that (regarding your MP, I don't have the time to review it right now, but just noticed this)
[13:02] <gmb> danilos: Ah, bugger. I forgot that had changed.
[13:02] <gmb> Thanks. I'll update my branch.
[13:02] <danilos> gmb, yw
[13:03] <gary_poster> danilos, thanks for mail about bug 788874.  Do you (or wgrant) know if the task is to simply review and shepherd the branch poolie has?  Or is there something more that needs to be done?
[13:04]  * gary_poster looks at branch
[13:04] <gary_poster> ah
[13:05] <gary_poster> nm
[13:07] <bigjools> please make the code import emails stop :(
[13:08] <jelmer> bigjools: sorry about that :-/
[13:08] <jelmer> I wonder if there's an easy way we can clean them up without generating so much noise
[13:08] <bigjools> put the contact address back until the bug is fixed? :)
[13:09]  * jelmer wasn't aware anything had changed, been getting these for years
[13:09] <bigjools> oh
[13:09] <bigjools> it's vcs-imports I think
[13:11] <maxb> I don't mind getting ~vcs-imports mails. They are a bit spammy, but it can be useful to review my saved folder of them as a log at times
[13:11] <jelmer> canonical-launchpad is a member of vcs-imports, and vcs-imports is set to mail each member individually
[13:13] <jelmer> I can certainly restrict it while I do the cleanup
[13:14] <bigjools> I honestly don't know what the best thing to do is
[13:15] <bigjools> I just know that some of us are getting more email than we want :)
[13:20] <benji> gary_poster: I am indeed.
[13:21] <benji> pfft
[13:26] <jml> benji: good morning.
[13:27] <benji> morning, jml; I trust all is well with you.
[13:27] <jml> benji: almost everything is very well, thank you.
[13:27] <jml> benji: however there's a current production issue (see recent discussion on #launchpad-ops), and I was wondering if you'd be able to take care of it.
[13:28] <jml> benji: wgrant says that it's https://wiki.canonical.com/IncidentReports/2011-05-27-LP-2011-05-27-LP-incoming-mail-wedged come again.
[13:28] <benji> jml: sure, I'll be glad to take a look
[13:28] <jml> benji: thank you.
[13:32] <StevenK> Is the topic to date in terms of revision number?
[13:32] <wgrant> StevenK: Unless something else has broken since I EODed.
[13:32] <wgrant> Which is not unlikely.
[13:33] <wgrant> But let's see.
[13:33] <wgrant> StevenK: It is up to date.
[13:40] <jelmer> wgrant: could it be that nothing was rolled out to the importds yet?
[13:40] <bac> gmb: after our call could you look at https://code.launchpad.net/~bac/launchpad/bug-789383/+merge/63695
[13:40] <wgrant> jelmer: Ah, yeah, about that...
[13:40] <wgrant> jelmer: We had deployed it.
[13:40] <wgrant> jelmer: Then I got half-way through closing the bugs.
[13:40] <wgrant> jelmer: When one of them OOPSed.
[13:40] <wgrant> So we had to roll back.
[13:40] <wgrant> Sorry, entirely forgot I'd closed a few of them by that point.
[13:41] <jelmer> wgrant: ah, ok - what was the OOPS?
[13:42] <wgrant> jelmer: See the end of bug #772609
[13:43] <jelmer> wgrant: thanks
[13:44] <jelmer> wgrant: sounds like you had a tough day... have a good evening :)
[13:45] <Ursinha> hello
[13:46] <jml> hello
[14:36]  * jml out for lunch & errands.
[14:44] <flacoste> gmb: so what's the story? is 13154 a blocker or not? from deployment-stable.html and the bug report it looks like it, but i'm not sure from your email exchange with wgrant on the list
[14:44] <wgrant> flacoste: It's a blocker.
[14:44] <wgrant> flacoste: We had to revert the nodowntime deployment. I guess I forgot to put that bit in the email.
[14:46] <wgrant> But simply reverting it is OK; it need not be fixed and relanded.
[14:46] <allenap> Eyup gmb, got time for a shortish straightforwardish review?
[14:46] <gmb> allenap: Sure
[14:46] <allenap> gmb: Thanks :) https://code.launchpad.net/~allenap/launchpad/derives-from-portlet-bug-793547/+merge/63703
[14:46]  * gmb looks
[14:47] <allenap> gmb: Oops, I forgot to retarget to db-devel... one moment.
[14:47] <gmb> Woah, conflcty.
[14:47] <wgrant> allenap: Why's that db-devel?
[14:47] <flacoste> wgrant: ok thanks, and i guess gmb is handling the reversal?
[14:48] <wgrant> allenap: Unless that has a DB patch, it can land on devel.
[14:48] <wgrant> flacoste: I reverted it hours ago, and it just passed buildbot.
[14:48] <gmb> flacoste: I thought it had been reverted
[14:48] <wgrant> flacoste: Should be on qastaging in half an hour or so.
[14:48] <gmb> AH, which it has.
[14:48] <gmb> Molto bene.
[14:48] <allenap> wgrant: Has db-devel been merged into devel recently? If not, then I strongly suspect this depends on stuff that's only in db-devel.
[14:48] <wgrant> allenap: We release in <36 hours. db-devel has nothing that devel doesn't have.
[14:49] <wgrant> allenap: It was merged into devel twice yesterday.
[14:49] <allenap> wgrant: Okay. I wonder why so many conflicts then :-/
[14:49] <wgrant> Possibly a criss-cross... but I deliberately tried to avoid that.
[14:49] <wgrant> Maybe you merged devel recently?
[14:49] <flacoste> wgrant. gmb: thanks a lot!
[14:50] <wgrant> flacoste: So we should be deployable again in an hour.
[14:50] <flacoste> awesome!
[14:51] <wgrant> And hopefully nothing more will crop up tomorrow, because we've really had enough of that sort of stuff already.
[14:53] <allenap> gmb: https://code.launchpad.net/~allenap/launchpad/derives-from-portlet-bug-793547/+merge/63704 is targeted to db-devel, which gives a sensible diff and can be reviewed. I'll try and land it to devel though, if I can figure out wtf is going on.
[14:53] <gmb> RIGHT, TA.
[14:53] <allenap> Thanks :)
[14:53] <gmb> Woah.
[14:54] <gmb> That was a bit old-man-of-Lancashire.
[14:54] <gmb> RIGHTO LAD, TA.
[14:54] <allenap> gmb: That's exactly as I interpreted it :)
[14:54] <gmb> I shall go and get me cap and pipe.
[14:54] <wgrant> allenap: I suspect things should go away if you merge db-devel in a few minutes.
[14:54] <gmb> And then tek a sken at thy branch.
[14:54] <wgrant> Or devel.
[14:55] <wgrant> Hm.
[14:55] <wgrant> PQM sees a conflict merging stable into db-devel. I do not.
[14:56] <wgrant> Ahh, there.
[14:57] <allenap> wgrant: Cool, cheers.
[15:00] <gmb> allenap: Approved
[15:00] <allenap> gmb: Thanks :)
[15:11] <StevenK> jml: O hai, can you recall off the top of your head if there is a bug about ec2 land giving an ugly traceback if the URL provided is not an MP?
[15:12] <jml> StevenK: I don't *think* so. I've tried to make sure bugs like that are tagged ec2land, and I can't see any.
[15:12] <StevenK> jml: I'm happy to file one -- I just wanted to avoid the "Oh, damn, someone has had that idea already."
[15:13] <jml> StevenK: that'd be great. thanks.
[15:13] <StevenK> jml: Either that, or maybe I fix it.
[15:15] <jml> StevenK: that'd work too :)
[15:16] <StevenK> jml: Could not think of an elegant way, sadly. :-(
[15:16] <StevenK> jml: Bug 794067
[15:16] <_mup_> Bug #794067: ec2 land gives traceback when URL isn't an MP <ec2land> <Launchpad itself:Confirmed> < https://launchpad.net/bugs/794067 >
[15:18] <jml> StevenK: funny. I could have sworn that bug had been filed.
[15:18] <RawChid> Hey, from Python I try to load a pot from LP (staging). The code should work and I should have the right permission, nevertheless I get HTTP Error 401: Unauthorized  (Unknown access token). Any ideas?
[15:18] <StevenK> jml: Bah
[15:19] <RawChid> By "the code should work" I mean I just checked it out and i works for other people
[15:19] <jml> StevenK: but I can't find it.
[15:19] <StevenK> jml: I doubt we can use isinstance() in this case, though
[15:19] <jml> StevenK: to handle this case, you could do this:
[15:20] <jml> StevenK: assume the URL is for a branch; if that branch has exactly one merge proposal that is Approved (or maybe Needs review), then use that merge proposal
[15:20] <jml> StevenK: otherwise assume the URL is for a merge proposal
[15:21] <jml> still doesn't handle cases where the user specifies http://example.com/whatever or LP object URLs that are neither branches nor MPs.
[15:21] <jml> how come I still don't have food yet?
[15:21] <jml> gnuh.
[15:21] <jml> bbiab.
[15:22] <StevenK> jml: Yes, I was hoping to figure out an elegant solution that handled both cases.
[15:26] <henninge> gmb: Hi! Can you please review this branch of mine?
[15:26] <henninge> gmb: https://code.launchpad.net/~henninge/launchpad/bug-347117-duplicate-template-name/+merge/63710
[15:26] <henninge> gmb: it claims to be a 629 line diff but it's only 238. See the comment. ;-)
[15:35] <cjohnston> henninge: they are done! yay
[15:36] <henninge> cjohnston: yes. Thanks for your contribution and sorry it took so long.
[15:36] <wgrant> cjohnston: Uh, well, sort of.
[15:37] <cjohnston> Not a problem.. Part of it taking so long was me and my not knowing, then me getting too busy.
[15:37] <wgrant> cjohnston: They were deployed for about 20 minutes.
[15:37] <cjohnston> uh
[15:37] <wgrant> cjohnston: When we had to revert for unrelated reasons.
[15:37] <wgrant> They will be redeployed on Thursday.
[15:37] <cjohnston> ok.. well close enough to being done
[15:37] <cjohnston> lol
[15:37] <RawChid> Hm, when running I get "The kwalletd service has been disabled". Maybe this has something to do with the authentication error?
[15:37] <wgrant> I forgot to reopen the bugs, sorry.
[15:39] <cjohnston> oh well
[15:39] <cjohnston> They are ready and able to go, and that's as much as I can hope for
[15:39] <cjohnston> Although it will be cool when my text is spamming a gazillion people on each bug email.. lol
[15:50] <bac> gmb:  can you take a look at https://code.launchpad.net/~bac/launchpad/bug-789383/+merge/63695 ?
[15:51] <gmb> bac: Syre
[15:51] <gmb> *Sure
[15:59] <gmb> bac: Approved.
[16:02] <henninge> deryck: Hey!
[16:02] <henninge> gmb: If you could also have a look at my branch, please, I'd be very happy. ;-)
[16:02] <gmb> henninge: Ah, sorry. I missed your ping. Looking now.
[16:03] <henninge> gmb: np
[16:05] <gmb> henninge: I like this approach of saying "Everything after line XXX isn't interesting." I'll try and land more changes that way...
[16:10] <jml> sinzui: hello
[16:10] <jml> sinzui: I'm moving the disclosure roadmap doc that we worked out to the wiki. Any place that would make sense for you?
[16:12] <sinzui> jml, do we have a page for current features? I think it would be helpful to have pages showing the derived distros and disclosure roadmaps
[16:12] <jml> sinzui: no we don't. we are exploring uncharted realms of documentation.
[16:12] <jml> sinzui: and yes I fully agree.
[16:13] <jml> sinzui: but I'm afraid the disclosure feature is the guinea pig for whatever doc / proj. planning experiments we're doing.
[16:13] <jml> sinzui: if you don't have a preference for a location on the wiki, I'll just add it somewhere that makes sense to me.
[16:14] <sinzui> jml: forward me the URL after your decision
[16:14] <jml> sinzui: will do.
[16:14] <gmb> henninge: Approved.
[16:15] <henninge> gmb: thank you very much ;-)
[16:15] <gmb> np
[17:14] <jml> hey, what's that word for "post-mortem" that people use to avoid saying "mortem" when they want to talk about a project that's just finished?
[17:15] <timrc> on does the on call reviewer process work? I need to assign a reviewer to a merge proposal... original pre-implementation discussion happened mostly w/ bigjools
[17:15] <timrc> on does? how does..
[17:16] <bigjools> timrc: looks like there's no OCR at the moment
[17:17] <bigjools> I would review your work but I am really swamped, sorry
[17:17] <timrc> bigjools, I've seen one for awhile... is there a certain time of day or night I should be here?
[17:17] <timrc> gah... I haven't seen one
[17:17] <bigjools> it depends on the timezone they are in
[17:17] <timrc> bigjools, is there a schedule on the wiki, perhaps?
[17:17] <bigjools> timrc: https://dev.launchpad.net/ReviewerSchedule
[17:18] <bigjools> :)
[17:18] <timrc> nice
[17:18] <bigjools> I think you missed both of today's
[17:19] <timrc> bigjools, naturally :)
[17:19] <timrc> I'll wait 'til Wednesday, that's fine
[17:19] <bigjools> you'll have to wait, or sweet talk someone
[17:20]  * timrc accidentally drops a hundred dollar bill near abentley's foot... oops... can you get that for me?
[17:20] <bigjools> bad luck actually, today is the only day where there's no reviewer in north america
[17:20] <bigjools> timrc: that could be interpreted more than one way ...
[17:22] <timrc> bigjools, doh
[17:22] <LPCIBot> Yippie, build fixed!
[17:22] <LPCIBot> Project devel build #784: FIXED in 5 hr 23 min: https://lpci.wedontsleep.org/job/devel/784/
[17:29] <jcsackett> timrc: there's a launchpad reviewers team that you should assign your MP too; many OCR people just work off a queue of projects in +activereviews on their day, so it increases the liklihood that someone will look at it without you needing to nag anyone.
[17:30] <jcsackett> it's not a guarantee that someone will look at it without them pinging you, but it's been known to happen.
[17:33] <jml> jcsackett: there's a team? OCRs don't just use https://code.launchpad.net/launchpad-project/+activereviews?
[17:34] <jcsackett> jml: that's the queue. assigning to the reviewer team means anyone who might be OCR can look at your MP.
[17:34] <jcsackett> i conflated two parts of how things work. sorry. :-P
[17:34] <jml> jcsackett: isn't that the default anyway?
[17:34] <jcsackett> jml: it may well be, but timrc was asking about assigning it to someone.
[17:34] <jml> jcsackett: oh right.
[17:34] <jml> sorry. carry on.
[17:35] <timrc> jcsackett, I don't this the review team in the directory..
[17:36] <timrc> oh man typing skills seriously lacking today
[17:36] <jcsackett> timrc: happens to all of us. i'm assuming you meant "i don't think the review team is in the directory" ?
[17:36] <timrc> jcsackett, yep :)
[17:39] <jcsackett> timrc: don't worry about it. as jml pointed out, if you leave that blank launchpad-reviewers is assigned automatically.
[17:39] <jcsackett> if i were better at providing help on irc, i would have told you that first before babbling about +activereviews. :-P
[17:40] <timrc> ok, let me remove cody-somerville from the review... I'm sad because I put this merge proposal in last week which means 100,000+ lines have probably changed :)
[17:40] <cody-somerville> timrc, merge from trunk and push then
[17:43] <timrc> cody-somerville, yeah yeah, I'm just trying to guilt-trip you :)
[19:25] <cr3> when making database changes, as per /PolicyAndProcess/DatabaseSchemaChangesProcess, where do I make the database changes considering a patch number is only assigned after review?
[19:27] <cr3> I'm thinking database/schema/launchpad-2208-00-0.sql but that feels weird, so might as well ask
[19:35] <deryck> cr3, make a launchpad-XX.sql and when you have a number rename the file.
[19:36] <deryck> cr3, see #10 under "making a database patch" on that page
[19:37] <cr3> deryck: excellent, thanks
[19:37] <deryck> np
[20:20] <nigelb> StevenK: Happy Birthday!
[21:31] <lifeless> morning
[21:48] <lifeless> gary_poster: hi
[21:48] <lifeless> gary_poster: can we talk about bug 772609 and the impact on the downtime deploy ?
[21:48] <gary_poster> hey on call
[21:48] <_mup_> Bug #772609: bug subscription mute link is not shown for membership in a team with a direct or structural subscription <bad-commit-13003> <bad-commit-13154> <qa-bad> <story-better-bug-notification> <Launchpad itself:Triaged by gmb> < https://launchpad.net/bugs/772609 >
[21:50] <lifeless> gary_poster: after your call is fine, if you have time.
[21:51] <deryck> sinzui, if you're curious, here's the IE filebug issue fix:  https://code.launchpad.net/~deryck/launchpad/ie-filebug-error-500015/+merge/63763
[21:51] <sinzui> wow
[21:52] <sinzui> deryck: I have a working yui test suite on the functional layer. I cannot land it without fixing 5 broken tests that we could not see
[21:53] <deryck> oh, cool.  running yui tests via Windmill?
[21:53] <deryck> I had forgot you were trying to fix that.
[21:54] <deryck> I don't think this will affect that, though.  It was never a problem in yui_tests, only with the big Windmill tests.
[21:54] <sinzui> No windmill
[21:55] <sinzui> deryck: I wrote a simple browser using pywebkit. It loads a page from the filesystem and returns when the command completed
[21:55] <sinzui> no polling, no waits
[21:55] <deryck> very cool!
[21:55] <sinzui> We do have js tests that run in 20 seconds. They violate our fast test policy though
[21:56] <deryck> ouch
[21:56] <sinzui> All but 7 tests pass in 45 seconds on my computer. the remaining take the suite into 3 minutes
[21:56] <deryck> I can't wait for this to land!  sinzui, I can help you fix the remaining yui tests if you like.
[21:57] <sinzui> I might be able to fix them. two were bad setup/teardowns on our part
[21:58] <deryck> cool.  well don't hesitate to ask if you need help.
[21:58] <sinzui> thanks
[22:01] <deryck> alright, and with that, I'm out.  until tomorrow everyone....!
[22:02] <gary_poster> lifeless: hi.  I was nervous about that bug, but gmb seemed to think it was under control.  I didn't dig into it enough with him to give you any more information than you have already, and in fact I suspect you know more about it than I do.  I am vaguely nervous about it.  f you think a call would help with something, I'm happy to have one
[22:02] <lifeless> gary_poster: I don't think we need a call
[22:03] <gary_poster> I thought that he needed to land that branch in order to fix something else critical
[22:03] <gary_poster> and I thought that this meant that our current state was Really Bad
[22:03] <lifeless> AIUI if we roll the patch back again, then we will just be missing that mute klink
[22:03] <gary_poster> But he didn't think so
[22:04] <gary_poster> lifeless, I think you are right.  I think I am getting confused about a follow-on bug that a previous branch caused
[22:04] <gary_poster> (a previous branch for that bug)
[22:04] <lifeless> ok, so wgranthas been doing the legwork. I think either he fluffed a little bit of metadata
[22:04] <lifeless> -or- qatagger is confused because of too many joined bugs
[22:04] <lifeless> either way, I will get the patch backed out if it isn't
[22:05] <lifeless> and that mute button can be fixed post-release-of-the-feature
[22:05] <gary_poster> ok thanks lifeless.  Completely agreed that this bug is not critical to its release.
[22:05] <lifeless> no worries
[22:05]  * gary_poster runs away now.  Have a good night all
[22:05] <lifeless> its a shame we're running into such friction. night night
[22:19] <wgrant> lifeless: Huh?
[22:20] <wgrant> Oh, bah, that bug was linked to 13164 too.
[22:20] <wgrant> Fixed.
[22:20] <wgrant> Should be green in 30s.
[22:22] <lifeless> wgrant: actually, I added the bad-commit-13164 after looking at the deploy report
[22:22] <lifeless> wgrant: did 13164 (the follow-on-oops) also need backing out ?
[22:23] <wgrant> lifeless: No, it's unrelated.
[22:23] <wgrant> Well, slightly related.
[22:23] <wgrant> But not really.
[22:23] <wgrant> You should be able to see from the diff that's it's safe :)
[22:24] <lifeless> I'd only just started looking at stuff
[22:24] <wgrant> .... conflict for 7 hours, awesome.
[22:26] <wgrant> Has someone QA'd the rollback?
[22:26] <lifeless> no
[22:26] <wgrant> I pre-QA'd on DF, but let's see anyway.
[22:26] <lifeless> when I started looking deploy-manager thought things were bad
[22:27] <lifeless> and the rollback has no linked bug to qa against from the deploy-report perspective
[22:27] <wgrant> It always considers a rollback to be deployable, anyway.
[22:27] <lifeless> wgrant: rev 13164 is linked to bug 772609
[22:27] <_mup_> Bug #772609: bug subscription mute link is not shown for membership in a team with a direct or structural subscription <bad-commit-13003> <bad-commit-13154> <qa-ok> <story-better-bug-notification> <Launchpad itself:Triaged by gmb> < https://launchpad.net/bugs/772609 >
[22:27] <wgrant> lifeless: Yes. I've marked that qa-ok and removed bad-commit-13164
[22:27] <lifeless> ok
[22:29] <wgrant> Hmm. Is the Subscribe/Unsubscribe link meant to do nothing when not logged in?
[22:29] <lifeless> I don't think we have JIT login yet
[22:29] <wgrant> Yeah, but normally it's a non-AJAX link which prompts for login.
[22:29] <wgrant> Bug #792502
[22:29] <_mup_> Bug #792502: Bug page subscribe/unsubscribe link doesn't work for anonymous users <exploratory-testing> <qa-ok> <story-better-bug-notification> <Launchpad itself:Fix Committed by gary> < https://launchpad.net/bugs/792502 >
[22:31] <wgrant> lifeless: It is green now.
[22:34] <wgrant> So, I think the confusion has stemmed from three things: 13154 vs. 13164 is not very obvious; 13164 shouldn't have had 772609 linked to it; I didn't notice that it did.
[22:34] <wgrant> Fail.
[22:34] <wgrant> Anyway, sorted now.
[22:34] <lifeless> yup, agreed on that
[22:34] <lifeless> I thought you had missed 13164
[22:34] <lifeless> (because they were similar)
[22:35] <wgrant> It's still good on qastaging.
[22:35] <wgrant> So I think we're fine.
[22:36] <lifeless> so we need rc= and testfix to land atm right ?
[22:36] <wgrant> Are we in testfix!?
[22:36]  * lifeless was wagging
[22:36] <lifeless> ok, so rc it is
[22:36] <wgrant> Just need RC.
[22:36] <wgrant> I have a conflict resolution branch.
[22:36] <wgrant> For stable->db-devel.
[22:36] <wgrant> Do I have your blessing?
[22:36] <lifeless> aaron had one
[22:37] <wgrant> Ah.
[22:37] <wgrant> k
[22:37] <lifeless> I've just shoved it at pqm
[22:37] <wgrant> Thanks.
[22:37] <lifeless> with the right headers
[22:37] <wgrant> I actually prepared one last night.
[22:37] <wgrant> But decided it would be entertaining to see what happened if I left it overnight.
[22:37] <wgrant> Plus it was 1am so meh.
[22:38] <lifeless> I wonder if telling postgresql to block %foo% searches would break too much
[22:38] <wgrant> Or we could upgrade to 9.1.
[22:39] <lifeless> it has indexable substring searches ?
[22:39] <wgrant> IIRC.
[22:39]  * wgrant googles.
[22:39] <wgrant> http://www.postgresonline.com/journal/archives/212-PostgreSQL-9.1-Trigrams-teaching-LIKE-and-ILIKE-new-tricks.html
[22:40] <lifeless> right
[22:40] <lifeless> thats available in 8.4
[22:40] <lifeless> its just an addon
[22:41] <lifeless> (and needs the query to be mangled a little)
[22:48] <wgrant> lifeless: DId you forget your QA tags again?
[22:48] <wgrant> It doesn't seem to have landed.
[22:49] <lifeless> [rc=lifeless][no-qa][r=lifeless] ...
[22:49] <lifeless> is what i did
[22:49] <wgrant> release-critical=
[22:49] <wgrant> Not rc=
[22:49] <lifeless> bwah
[22:49] <wgrant> [no-qa] is also traditionally at the end, but unlike [testfix] I don't think the order matters too much.
[22:49] <wgrant> Something to consider if it fails again.
[22:56] <lifeless> I wonder if julian will facepalm when he gets my reply.
[23:03] <poolie> hi all
[23:07] <wgrant> lifeless: How is the conflict?
[23:09] <lifeless> checking for cron errors
[23:10] <lifeless> ah
[23:10] <lifeless> abentley: your branch was private and not accessible to canonical-launchpad-branches
[23:28] <lifeless> flacoste: ping; would you consider bug 794008 critical ? It's not js, rather css, but still...
[23:28] <_mup_> Bug #794008: Opera displays Launchpad _without text_ <opera> <Launchpad itself:Triaged> < https://launchpad.net/bugs/794008 >
[23:57] <sinzui> wallyworld: wgrant: I just got called to pickup my daughter. I will be 20 minutes late
[23:57] <wallyworld> sinzui: ack
[23:58] <wgrant> sinzui: Sure.