[00:09] <lifeless> sinzui: you will laugh and cry at bug 618356
[00:09] <_mup_> Bug #618356: Person-picker takes a very long time consistently <disclosure> <lp-blueprints> <pg83> <sprints> <timeout> <Launchpad itself:Triaged by launchpad-teal-squad> < https://launchpad.net/bugs/618356 >
[00:09] <lifeless> sinzui: full text queries without a full text index are slow.
[00:11] <sinzui> lifeless: we are discussing this right now actually. Why do we do a fti searching for a person? I think we care about displayname, not homepage_content
[00:11] <lifeless> sinzui: the simplest thing would be to drop the fti lookup
[00:11] <lifeless> sinzui: but if we do /any/ fti lookups on person we will need that index
[00:16] <lifeless> sinzui: anyhow, its in your squads court; I just dug into the query from curiosity; I hope that helped.
[00:16] <sinzui> lifeless: It was a very timely query. Thank you very much
[00:18] <wallyworld_> huwshimi: http://people.canonical.com/~ianb/person-picker-extra-detail.png
[00:21] <huwshimi> Ugh, my wifi is flaky
[00:38] <LPCIBot> Project windmill-db-devel build #312: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-db-devel/312/
[00:52] <wgrant> lifeless: How does it not explain the cause?
[00:52] <wgrant> It says there are already binaries published in the archive.
[00:52] <wgrant> It is less than completely transparent.
[00:53] <wgrant> But it *does* explain the cause for anybody who knows anything about Debian archives in the last 10 years.
[00:53] <lifeless> wgrant: its sufficiently opaque to confuse doko.
[01:03] <wgrant> True.
[01:14] <wgrant> Why does an Icelandic volcano always erupt like a month before we go to Europe? :/
[01:28] <wgrant> Die, git, die.
[01:28] <wgrant> WedonotneedaForkbuttondammit
[02:48] <lifeless> man, users get *so* confused
[02:48] <lifeless> bug/158702
[02:50] <wgrant> Yes.
[02:50] <wgrant> But this user has a bit of karma.
[02:50] <wgrant> It's not the normal confused brand new user case.
[02:50] <spiv> Ah, heh.
[02:51] <lifeless> no
[02:51] <lifeless> its a confused established user
[02:51] <spiv> I think they meant question 158072?
[02:51] <spiv> Er, 158702.
[03:08] <lifeless> wow
[03:08] <lifeless> bug queries with structuralsubscriptions in the are -really- slow
[03:11] <lifeless> still running
[03:13] <lifeless> still running
[03:13] <lifeless> !
[03:18] <StevenK> lifeless: When doing the initial work for populate-spr-changelogs, the initial query took 65 *minutes* on DF
[03:21] <LPCIBot> Project windmill-devel build #124: STILL FAILING in 1 hr 19 min: https://lpci.wedontsleep.org/job/windmill-devel/124/
[03:53] <lifeless> heh
[03:53] <lifeless> this is up at 45 now
[03:54] <lifeless> you can see why its timing out in prod
[03:59] <lifeless>  Aggregate  (cost=816866.73..816866.74 rows=1 width=0)
[04:04] <mwhudson> that's quite a lot of milliseconds
[04:04] <lifeless> thats cost, not ms
[04:05] <lifeless> running it the time was past  45 minutes when I nuked it
[04:05] <lifeless> cost may be ms, but its actually not comparable between pg instances unless - all- the config knobs are identical (including CPU)
[04:05] <mwhudson> ah
[04:06] <lifeless> plans are evaluated by cost
[04:06] <lifeless> the cheapest is chosen
[04:06] <lifeless> the knobs say things like 'a block of random IO costs X'
[04:07] <lifeless> and an in-memory sort of width 500 length 200 costs Y
[04:11] <LPCIBot> Project windmill-devel build #125: STILL FAILING in 50 min: https://lpci.wedontsleep.org/job/windmill-devel/125/
[04:21] <sinzui> wgrant: ping
[04:22] <wgrant> sinzui: Hi.
[04:22] <sinzui> wgrant: I want to talk about bug 561380
[04:22] <_mup_> Bug #561380: /builders page is oopsing <boobytrap> <disclosure> <lp-soyuz> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/561380 >
[04:23] <wgrant> I'm not sure it requires any discussion, but OK :)
[04:23] <wgrant> The fix is very clear and simple.
[04:24] <lifeless> delete the page yeah ?
[04:25] <sinzui> wgrant: Since the template is just reporting current state; I propose PackageBuildFormatterAPI return either nothing, , state thee is nothing to see, or the link the build obfuscating the private team+ppa,
[04:25] <wgrant> sinzui: We already have facilities to show private BPBs.
[04:25] <wgrant> We just need to extend that to SPRBs.
[04:25] <wgrant> lifeless: Why?
[04:26] <lifeless> wgrant: I have a massive headache; my sense of humour gets distorted at such times
[04:28] <sinzui> I do not see the formatters for that.
[04:29] <wgrant> lifeless: I suspected it may have been an attempt at humour, but you are not unknown for making radical proposals.
[04:33] <wgrant> sinzui: Let me see.
[04:34] <wgrant> Oh, I see.
[04:34] <wgrant> This is different from the SPRB bug.
[04:35] <wgrant> So, yes, Julian's analysis is correct.
[04:35] <wgrant> But hmm.
[04:36] <wgrant> I think this may be fixed.
[04:36] <sinzui> wgrant: PackageBuildFormatterAPI think it is checking that the user can see it:
[04:36] <sinzui> if not check_permission('launchpad.View', build):
[04:36] <sinzui>             return 'private source'
[04:36] <wgrant> IPerson's launchpad.View adapter allows commercial admins to see the person.
[04:36] <sinzui> But that guard predates the bug reports
[04:36] <wgrant> s/the person/private teams/
[04:36] <wgrant> Sure, in this case he can view the build because he can view the archive because he's a commercial admin.
[04:36] <wgrant> But the archive is owned by a private team.
[04:37] <wgrant> Which he can see (at least now).
[04:37] <wgrant> I guess the adapters have changed since PMTs were removed.
[04:37] <wgrant> But let's see.
[04:38] <wgrant> Heh.
[04:38] <wgrant> Yes.
[04:38] <wgrant> You fixed this in August.
[04:38] <wgrant> 11327.2.1 "Allow commercial admins to view private teams."
[04:39] <sinzui> Yes, but was bigjools the victim here?
[04:40] <wgrant> "You are logged in as Julian Edwards."
[04:40] <wgrant> Unless we have another Julian Edwards.
[04:40] <sinzui> He has also been a commercial admin for more that a year, so how did he see it
[04:40] <wgrant> hmm?
[04:40] <wgrant> This was filed in last April.
[04:40] <wgrant> When he could see all private PPAs due to his commercial adminity.
[04:40] <wgrant> But couldn't see private teams.
[04:40] <sinzui> Sorry
[04:40] <sinzui> I have no ind
[04:40] <sinzui> mind
[04:41] <wgrant> No ind!
[04:41]  * sinzui shuts up
[04:41] <wgrant> This sounds disastrous.
[04:41]  * wgrant closes ze bug.
[04:41] <sinzui> ViewBinaryPackageBuild looks sensible too
[04:42] <wgrant> Yeah.
[04:42] <wgrant> SPRBs into private archives may still be problematic.
[04:42] <wgrant> But BPBs are fine.
[04:42] <wgrant> (assuming the security adapters aren't insane, and in this case they were -- access to a subordinate object was granted without having access all the way up to the root)
[04:43] <wgrant> jtv: The conventional way to avoid this discussion is just to use ~janitor.
[04:43] <wgrant> jtv: I think that may be prudent here.
[04:43] <jtv> wgrant: been over that.  No.
[04:43] <wgrant> :(
[04:44]  * jtv relocates
[04:46] <wgrant> lifeless: Any ideas on that maybe-bad rev?
[04:46] <wgrant> I've tested it in a few browsers and it seems to work OK.
[04:46] <wgrant> And bac did not respond to my cries last night.
[04:47] <wgrant> And the feature is as-yet unreleased.
[04:47] <wgrant> So I think I shall qa-ok it and the two other things and organise a deployment.
[04:47] <wgrant> Hm.
[04:47] <wgrant> Although we are LOSAless.
[04:47] <wgrant> So I guess it doesn't matter all that much.
[04:59] <wgrant> lifeless: You were saying earlier that person.fti was unindexed, but I see a gist index on it.
[05:19] <wgrant> sinzui: Still around?
[05:19] <sinzui> yes
[05:19] <lifeless> wgrant: where are you looking
[05:20] <wgrant> sinzui: I am attempting to install Balsamiq Mockups. They have am amd64 .deb, but I cannot locate an amd64 build of Adobe AIR. Am I missing something here, or must I hack the i386 one?
[05:20] <lifeless> wgrant: revert the bad rev
[05:20] <wgrant> lifeless: Huh, you're right, it's not on the production DB.
[05:20] <wgrant> But is on dev.
[05:21] <StevenK> wgrant: http://kb2.adobe.com/cps/521/cpsid_52132.html
[05:21] <wgrant> lifeless: :(
[05:21] <sinzui> yuck.
[05:21] <lifeless> wgrant: the different between theory and practice
[05:21] <wgrant> StevenK: BURN
[05:21] <sinzui> I am using i386
[05:21] <StevenK> sinzui: The 90s called, they want their archtag back
[05:21] <wgrant> i386 VM time.
[05:21] <lifeless> its ironic to be using proprietary software to build open source software
[05:22] <lifeless> by ironic I mean saddening
[05:22] <wgrant> lifeless: *cough splutter* Launchpad *cough cough*
[05:22] <sinzui> StevenK: I gave up on 64 when I realised that the apps were only using more memory  and not providing more performance
[05:22] <StevenK> wgrant: By various hacks that I don't want to recall, I got AIR to install on amd64
[05:23] <wgrant> StevenK: Yes, but I probably don't want Adobe crap outside a VM anyway.
[05:23] <jtv> wgrant: at least we fixed Launchpad.
[05:23] <StevenK> sinzui: But it's a complete waste if you have more than 4GiB RAM
[05:23] <wgrant> jtv: This is true.
[05:23] <sinzui> not soon enough for me. I was tired if having deadlines with a broken environemnt
[05:24] <jtv> StevenK, wgrant: mind if I kick df for an upgrade?
[05:24] <StevenK> YES
[05:24] <wgrant> I believe StevenK is currently touching it in bad ways.
[05:24] <jtv> wgrant: mind if I kick StevenK for an upgrade?
[05:24] <StevenK> I'm using it, hands off
[05:24] <jtv> Well keep the door open just in case.
[05:25] <jtv> Or do you mean "I'm using it.  Hands off."?
[05:25] <StevenK> I updated the code before lunch, so about 2 hours ago
[05:26] <jtv> Looks like that was still well before my overnight landing percolated through.  :(
[05:27] <lifeless> wgrant: so bac's rev
[05:27] <lifeless> wgrant: I think it should be reverted
[05:27] <lifeless> wgrant: i said as much in the bug
[05:27] <wgrant> I shall revert it.
[05:27] <wgrant> You did.
[05:29] <jtv> Ahhh what luck it was merely the version number that was out of date—my branch is in there.
[05:29] <jtv> StevenK: mind if I sync a few oneiric packages on df?
[05:29] <StevenK> jtv: Yes
[05:29] <jtv> hmmmgrr
[05:30] <StevenK> I'm playing with the package copier
[05:30] <jtv> Ah!
[05:30] <jtv> Then maybe you can just tell me what I need to know.
[05:30] <jtv> In fact, looks like (once I got past the timeouts just now) I've found an example of just the display I was trying to reproduce.  Thanks
[05:33] <wgrant> Gnargh testfix.
[05:33] <wgrant> lifeless: Can we disable the rabbit test pls?
[05:33] <StevenK> s/test //
[05:34] <lifeless> wgrant: gavin has an improvement he is/has landed
[05:34] <wgrant> Stil fails.
[05:34] <wgrant> +l
[05:34] <lifeless> wgrant: its possible that the failure is due to that improvement, or that the improvement hasn't reached bb
[05:34] <wgrant> No, this is clearly a failure with the new code.
[05:34] <wgrant> Hard to tell if it's the same failure that we've hit 20 times in the last week.
[05:34] <wgrant> But concealed by the improvement.
[05:35] <lifeless> so sure - critical bug for disabled test, etc
[05:39] <wgrant> You know it's failing probably near half the buildbot runs, right?
[05:40] <lifeless> wgrant: I just agreed to disabling it!
[05:40] <wgrant> Yes, but your suggestion that the improvement caused the failure suggests that it hadn't already been failing every second run for weeks.
[05:41] <lifeless> wgrant: I didn't realise it was that flaky
[05:41] <wgrant> It's actually only 1/3. But yeah.
[05:41] <wgrant> still not great.
[05:41] <lifeless>                      ->  Bitmap Index Scan on bugtask__distribution_sourcepackage__heat__idx  (cost=0.00..567.17 rows=17172 width=0) (actual time=141.166..141.166 rows=503359 loops=164)
[05:42] <lifeless> repeated 146 times
[05:42] <wgrant> Fun.
[05:42] <lifeless> -> structural subscription scaling fail
[05:42] <lifeless> 70M rows processed to get 2.5K results
[05:42] <wgrant> Hmm.
[05:42] <wgrant> Not sure how best to disable this.
[05:42] <wgrant> Since it's the only test in the class.
[05:42] <wgrant> And the only class in the file.
[05:42] <wgrant> I guess I should rename the file.
[05:42] <StevenK> Yeah, rename the file
[05:43] <lifeless> hih
[05:43] <lifeless> just rename the test
[05:43] <wgrant> No, then the testrunner bitches that there are no tests in the class.
[05:43] <wgrant> :(
[05:43] <lifeless> well
[05:43] <lifeless> thats a stupid freaking test runner then isn't it
[05:43] <lifeless> does it support skips ?
[05:43] <wgrant> I don't think so.
[05:43] <lifeless> actually
[05:44] <lifeless> testtools does
[05:44] <lifeless> just do a skip
[05:44] <lifeless> self.skip('disabled')
[05:44] <wgrant> @skip?
[05:44] <lifeless> see what happens
[05:44] <wgrant> Heh.
[05:44] <wgrant> OK.
[05:44] <lifeless> or that; 6 billion ways to spell it
[05:45] <wgrant> It appears to succeed, but at least does not fail.
[05:45] <wgrant> Thanks.
[05:47] <lifeless> not the plan your doctor ordered:
[05:47] <lifeless>  Nested Loop  (cost=2.76..17359385328490.43 rows=247357031677542 width=4)
[05:48] <wgrant> .....
[05:51] <lifeless> exactly
[05:52] <StevenK> Is that 247 trillion?
[05:52] <lifeless> who knows
[05:53] <StevenK> Looks like it. I don't think we have that many rows in our entire db
[05:53] <lifeless> structsubs
[05:53] <lifeless> win
[05:53] <lifeless> got it down to 25 seconds so far
[05:54] <wgrant> 247 trillion, yeah. Awesome.
[05:54] <lifeless> 25 seconds
[05:54] <lifeless> bah
[05:54] <lifeless> 15
[05:54] <lifeless> server team has 146 subscriptions
[05:55] <lifeless> the live plan is evaluating *each one* with 5 bugtask table index bitmap scans
[05:56] <lifeless> sorry, 164 subs
[05:57] <wgrant> Adobe crap safely contained in a VM :)
[05:57] <wgrant> I like how the AIR download page tells you you'll probably need to turn off antivirus software.
[05:59] <lifeless> win!
[06:15] <lifeless> hah, this subscription query is broken anyhow
[06:18] <wgrant> Oh?
[06:19] <lifeless> actually a sub limit
[06:19] <lifeless> can't do series + package
[06:46] <wgrant> Hm.
[06:46] <wgrant> ValidPersonOrTeamVocabulary is stupid.
[06:51] <StevenK> jtv: Did you copy alien-arena-data into oneiric-updates?
[06:52] <jtv> StevenK: yesterday (though I didn't get to specify a pocket)
[06:52] <StevenK> jtv: It's component is non-free
[06:52] <wgrant> Because copies don't do overrides.
[06:52] <StevenK> Yet
[06:53] <wgrant> ValidPersonOrTeamVocabulary is pretty nice.
[06:53] <jtv> StevenK: did I cause a problem?
[06:53] <StevenK> Yes
[06:53] <jtv> I'm sorry about that... any way in which it could have been prevented?
[06:53] <wgrant> It seems to take the 100 most relevant results, then order them by displayname instead of relevance.
[06:53] <wgrant> How useful.
[06:54] <StevenK> jtv: By not doing that
[06:54] <jtv> *And* get my Q/A done?
[06:54] <StevenK> By undoing it
[06:54] <StevenK> :-)
[06:55]  * StevenK re-publishes -updates
[06:55] <wgrant> Or by copying stuff that's in Debian main.
[06:55] <wgrant> And not contrib/non-free.
[06:55] <wgrant> That's the critical bit.
[06:55] <jtv> Why is it specifically contrib and non-free that are a problem?
[06:56] <wgrant> Because they're not in Ubuntu.
[06:56] <StevenK> Because Ubuntu doesn't have those components
[06:56] <wgrant> The other Debian component is main, which Ubuntu has too.
[06:56] <lifeless> wgrant: win!
[06:56] <jtv> Then presumably the copy simply went into main?
[06:56] <wgrant> jtv: No, because that needs overrides.
[06:56] <wgrant> Copies don't do overrides.
[06:57] <jtv> So then what happened instead?
[06:57] <wgrant> It went into non-free.
[06:57] <jtv> So it created a component?
[06:57] <StevenK> And alien-arena is in contrib
[06:57] <wgrant> it created an invalid publication.
[06:57] <wgrant> Because that component is not publishable in that archive.
[06:58] <jtv> I suppose that will be fixed at some point though?
[06:58]  * StevenK re-publishes -updates AGAIN
[06:58] <wgrant> lifeless: It also seems to retrieve the top N private teams separately, then merges the two and drops all the FTI info.
[06:58] <wgrant> That whole function makes my head hurt.
[06:58] <StevenK> jtv: Copies need overrides, yes. I'm QAing it now
[06:58] <StevenK> Which this mess didn't help at all
[06:59] <wgrant> QAing the first step of it.
[06:59] <jtv> Very sorry about that; I'll coordinate with the others next time I copy a package.
[07:00] <StevenK> Or pick a package that is in Debian main, not contrib or non-free, like wgrant said
[07:00] <wgrant> Proprietary software destroys the world, again!
[07:00] <StevenK> Bwaha
[07:02] <jtv> StevenK: I don't think that'll help as much: this time it's a matter of figuring out what Debian component it's in (which I guess I'd find out on packages.debian.org?) but once this particular bug is fixed, it'll be something else.
[07:03] <StevenK> jtv: rmadison is your friend
[07:04] <jtv> It may say so on youface or whatever your kids use these days, but I'm not aware of the lady in question.
[07:04] <StevenK> % rmadison -u debian -s sid alien-arena
[07:04] <StevenK>  alien-arena | 7.51-2 | sid/contrib | source, amd64, armel, hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
[07:05] <wgrant> Ah, alpha/hppa are actually dead now?
[07:05]  * jtv sheds tear for alpha
[07:05] <wgrant> Or at least on ports.
[07:06] <StevenK> They've moved
[07:22] <LPCIBot> Project windmill-devel build #126: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/126/
[07:24] <jtv> Hi stub!  Want to try the Ubuntu Café for going over that patch?
[07:24] <stub> Urgh.
[07:24] <stub> Still booting.
[07:25] <stub> Where is it btw?
[07:25] <wgrant> The BranchRevision.id doompatch?
[07:26] <stub> The footgun, yeah.
[07:26] <wgrant> It looked simple enough, but zomgscary.
[07:26] <stub> With luck, it will give our toenails a lovely trim.
[07:26] <StevenK> And not our toes?
[07:27] <jtv> Ha ha, StevenK, always the optimist
[07:36]  * jtv relocates
[07:45] <lifeless> oh man, that was a tough one.
[07:45] <lifeless> wgrant: if you're interested - https://bugs.launchpad.net/launchpad/+bug/787294/comments/11
[07:45] <_mup_> Bug #787294: Person:+patches timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/787294 >
[07:45] <lifeless> my headache really didn't help - hard to think well about problems with a pounding going on
[08:48] <adeuring> good morning
[09:04] <allenap> wgrant, lifeless: We could try increasing the time-out. I didn't change that.
[09:04] <allenap> Re. the RabbitMQ fixture test.
[09:04] <wgrant> Hmm.
[09:09] <allenap> wgrant: The time-out is only 5 seconds right now, which is fairly tight. I think we should put it up to 15 seconds and see what happens.
[09:18] <mrevell> Guten morgen
[09:20] <LPCIBot> Project windmill-devel build #127: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill-devel/127/
[11:02] <LPCIBot> Project windmill-devel build #128: STILL FAILING in 1 hr 17 min: https://lpci.wedontsleep.org/job/windmill-devel/128/
[11:09] <lifeless> oh yay
[11:09] <lifeless> linkin invites sent to lp bugs
[11:16] <nigelb> heh
[11:17] <nigelb> how long does a fix take to land from qa-staging to production?
[11:17] <nigelb> (after being verified)
[11:18] <bigjools> nigelb: depends how quickly someone presses the button
[11:18] <nigelb> bigjools: Ah, so just wait some more I guess :)
[11:18] <bigjools> and what other things need QA
[11:19] <StevenK> nigelb: Which revision?
[11:19] <nigelb> StevenK: "Fixed in stable r13094"
[11:20] <StevenK> Ah, you're stuck behind r13092 which is qa-bad
[11:20] <StevenK> There was a revert happening at some point
[11:20] <StevenK> gmb needs to QA r13096
[11:21] <StevenK> And allenap needs to QA r13101
[11:21] <nigelb> ah, that's 13108, revert 13092
[11:21] <StevenK> Right, it likely hasn't hit qastaging yet
[11:21] <StevenK> Ah
[11:21] <StevenK> It has
[11:21] <StevenK> My deployment report was old
[11:21] <allenap> StevenK: I /think/ I've done that one.
[11:22] <nigelb> I was looking at http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/changes
[11:22] <StevenK> nigelb: And you need to QA r13106 :-)
[11:22] <nigelb> StevenK: that landed a few hours back, didn't get time :D
[11:22] <StevenK> "[testfix][rs=wgrant][rollback=13092] Disable TestRabbitFixture.test_start_check_shutdown. Its days of destroying the test suite are over."
[11:22]  * StevenK cackles
[11:23] <nigelb> haha
[11:23] <StevenK> nigelb: So, to answer your question: "It depends"
[11:23] <nigelb> Right, so I think I'm one of the people blocking it at this point :)
[11:24] <StevenK> There is a bunch of QA to do
[11:24] <nigelb> :)
[11:24] <nigelb> I guess I have to wait until 13108 to get QA'd because of 13092.
[11:25] <StevenK> r13108 won't get QA'd, it's a rollback
[11:25] <StevenK> If you mean up to r13108, that's different.
[11:26] <jml> lifeless: hi
[11:26] <nigelb> I meant upto.
[11:26] <nigelb> Bah, my rev isn't seeming to work.
[11:26] <StevenK> nigelb: Right, then yes, you do.
[11:26] <nigelb> How do I know something is in qastaging for sure?
[11:27] <nigelb> wait, PQM got done with it a minute back :/
[11:27] <lifeless> jml: hi
[11:27] <lifeless> nigelb: when its on qastaging the tagger will notice and tag the bug
[11:27] <bigjools> nigelb: check the revision number that it landed on
[11:28] <bigjools> compare with the one at the bottom of every page
[11:28] <nigelb> lifeless: ah, yes. Its tagged.
[11:28] <nigelb> bigjools: hrm, that seems to indicate its landed. But it isn't working. *whee* QA fail.
[11:28] <bigjools> nigelb: we only flag qa-bad if it should block rollout
[11:29] <nigelb> bigjools: Its not doing anything harmful, just needs more fixing.
[11:29] <nigelb> hrm, okay.  This is really random.
[11:29] <nigelb> https://blueprints.qastaging.launchpad.net/ubuntu/+spec/test-blueprint-mark/
[11:29] <nigelb> I don't even know what order its getting sorted :(
[11:30] <nigelb> Its working "mostly" except for the adicarlo name.  I suspect it has something to do with python's sort function.
[11:32] <StevenK> You probably should have used .order_by() on a ResultSet?
[11:32] <nigelb> I used sort because that's what's used in the sprints too.
[11:34] <spiv> nigelb: Python's sort is entirely sensible, except that the default ordering for objects that don't define how they should be compared is arbitrary (i.e. based on memory address)
[11:34] <nigelb> Bah, its a problem with using sort(), it clubs all the capitals first and the small letters later.
[11:35] <jml> lifeless: hello. I'm at a cafe, but am willing to try some sort of voice comms if you're up for it
[11:35] <lifeless> that sounds great. pick your poison
[11:35] <lifeless> sky.net?
[11:35] <spiv> nigelb: Well, that's how str/unicode's sort order is defined :)
[11:35] <spiv> nigelb: sort(seq, key=unicode.lower)
[11:36] <spiv> nigelb: or as StevenK says use order_by on the result set
[11:36] <LPCIBot> Project windmill-db-devel build #313: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-db-devel/313/
[11:36] <nigelb> order_by ?
[11:36] <nigelb> isn't that a query thing?
[11:36] <jml> lifeless: ok.
[11:37] <spiv> nigelb: yes.  The data originates in a db query after all.
[11:37] <nigelb> spiv: yeah, but its a cached property, so we end up having to mutate that list every now and then when someone subscribes newly.
[11:37] <bigjools> that's probably the most efficient place to do it
[11:38] <nigelb> https://code.launchpad.net/~nigelbabu/launchpad/90628-spec-sub/+merge/62003
[11:38] <nigelb> ^^ that's the branch with the merge changes for this one
[11:38] <jml> lifeless: hello can you hear me speaking?
[11:39] <jml> lifeless: I can hear you
[11:39] <jml> lifeless: my mic isn't coming up in sound config, even though it's correctly configured.
[11:40] <spiv> nigelb: well I guess just add .lower() to the sort key func, e.g. key=lambda sub: sub.person.displayname.lower()
[11:40] <nigelb> spiv: aha, I shall test that when I get to my computer running LP and propose merge again :)
[11:40] <nigelb> this means I should add a test case for this.
[11:41] <spiv> nigelb: I'm so glad you said that :)
[11:42] <bigjools> gmb: I have a branch waiting for your perusal if you're reviewing please?
[11:42] <gmb> bigjools: Sure. I'll be free to look in about ten minutes
[11:42] <bigjools> cheers, no rush
[11:45] <nigelb> spiv: yay, it works locally. So I need to fix and push them both.
[11:46] <nigelb> Sorry for breaking it :)
[12:06] <jml> lifeless: http://blog.launchpad.net/general/a-cream-pie-in-the-face
[12:10] <gmb> bigjools: r=me
[12:10] <bigjools> gmb: cheers
[12:10] <bigjools> pie chart - rofl
[12:33]  * gmb -> lunch
[13:05] <wallyworld_> benji: i've checked a mp your way. it's a redo of a recent bug fix you did to fix an issue with the picker widget. the original fix broken some windmill tests. the detail is in the mp. thanks in advance for looking :-)
[13:06] <benji> wallyworld_: sure, I'll take a look
[13:09] <wgrant> wallyworld_: Doesn't that make the names ambiguous?
[13:10] <wallyworld_> wgrant: no. the field names are unique and hence the ids are too. uniqueness has never ever been an issue afaik
[13:10] <wallyworld_> the real issue in the bug report was the invalid chars
[13:11] <wgrant> wallyworld_: It looks to me like that just suppresses invalid characters.
[13:11] <wgrant> If there are two names differing only by invalid characters, they are ambiguous.
[13:11] <wallyworld_> yes, that's all that's needed
[13:12] <wallyworld_> as i said, uniqueness has never been an issue, unless i am totally wrong :-)
[13:12] <wgrant> I don't see how it isn't an issue now...
[13:12] <wallyworld_> wgrant: i don't think tat's a real issue?
[13:13] <wallyworld_> we've never had bugs due to uniqueness
[13:13] <wallyworld_> or lack thereof
[13:13] <wallyworld_> in node ids for the picker widgets
[13:13] <wallyworld_> unless i'm missing something
[13:14] <wgrant> The original change was made because some package name had a . in it.
[13:14] <wgrant> Which means that package names are used in IDs.
[13:14] <wallyworld_> it was a "+"
[13:14] <wgrant> Or that.
[13:14] <wgrant> One of them
[13:14] <wgrant> Even so.
[13:14] <wgrant> You're now string that out.
[13:14] <wgrant> Which means that a package named 'foo' and a package named 'foo+' will conflict.
[13:14] <wallyworld_> the package was gtk+
[13:14] <wallyworld_> will that be an issue in practice?
[13:15] <wallyworld_> i could replace the "+" with another char
[13:15] <wgrant> Can we not go for "probably won't break in practice if we don't have an unlucky package combination", please? :)
[13:15] <wallyworld_> i could get hit by lightning too, but the chances are not worth worring about :-)
[13:16] <wgrant> Yeah, but this is easily avoidable and *will* break at some point.
[13:16] <wallyworld_> but anyway, if i replace the invalid chars with a  "-" or something, that should suffice
[13:16] <wgrant> Can't we urlencode it or something?
[13:17] <wallyworld_> probably
[13:17] <wgrant> That's likely to be less ambiguous.
[13:17] <wgrant> Replacing them all with a constant character is still ambiguous.
[13:17] <benji> wgrant: my original fix was to urlsafe_b64encode it
[13:17] <wgrant> RIght.
[13:17] <wallyworld_> the main point is that for tests, we need to be able to determine the id from the field name
[13:17] <wgrant> But that's a bit too opaque.
[13:17] <benji> yep, I see that now
[13:17] <wgrant> I don't have a problem with it, but it is slightly awkward for tests.
[13:17] <wallyworld_> more than slightly :-)
[13:18] <wgrant> The original code was probably written when someone thought along the lines of "pfft, who is going to put a + in a package name"
[13:18] <wgrant> We should make our code correct.
[13:18] <wgrant> Not working in most cases that we can conceive.
[13:20] <benji> I propose we replace the non-ID-safe characters with string equivalents plus the escaping char; so "gtk+" would become "gtk-plus-" and "foo-bar" would become "foo-dash-bar"
[13:20] <wallyworld_> benji: that sounds reasonable. it won't affect the existing tests because we don't put such chars in there in the first place for testing
[13:21] <benji> a definate plus ;)
[13:21] <wallyworld_> and the node ids are still easily discoverable from the field names
[13:21] <wgrant> wallyworld_: You can't identify the nodes in the tests some other way?
[13:22] <wallyworld_> not easily
[13:22] <wgrant> Attempting our own encoding method is somewhat fraught with peril.
[13:22] <benji> how about field names?  the base64ification was only for IDs
[13:22] <wallyworld_> and when one views page source, b64 "gibberish" is pretty yucky to look at
[13:22] <wgrant> You could even reuse the tiny base63-encoding helper.
[13:22] <wgrant> In the tests.
[13:22] <wgrant> When generating field names.
[13:22] <wgrant> That way we have correctness and not too terrible tests.
[13:22] <wallyworld_> yik, why go to all that bother
[13:22] <wallyworld_> yuk
[13:23] <wgrant> Because it's correct and reasonably clean.
[13:23] <wgrant> Ugly source.
[13:23] <wallyworld_> i like benji's idea :-)
[13:23] <wgrant> But cleaner than implementing our own dodgy encoder.
[13:23] <wgrant> Only [A-Za-z0-9_:.-] are permitted in ids.
[13:24] <wgrant> So you're going to have to manually encode a lot of stuff.
[13:24] <wallyworld_> benji: wrt field names, if they're dynamically generated from some data then we may still have an issue there
[13:25] <wallyworld_> wgrant: we could just replace with the ascii code number then
[13:26] <benji> wallyworld_: try this one on for size: if the ID has no disallowed characters then we do nothing, if it does we base64 encode it; that way all the tests work and we still cover all the bases
[13:26] <wallyworld_> that may work :-)
[13:27] <wallyworld_> benji: it's not just current tests, it's also new ones that need to be easy to write :-)
[13:28] <wallyworld_> if ^%^@!%^%^@! windmill were not turned off then we wouldn't be having this conversation :-(
[13:28] <benji> right, but I don't think we'll be doing too many wonky things in tests, so it won't happen very often -- back to your lightning argument ;)
[13:29] <wallyworld_> actually, i think it's the other way around. in tests, we have simple field names and we need to be able to easily know what the corresponding "show widget" element is called
[13:30] <wallyworld_> for some tests
[13:30] <wallyworld_> that need to poke that node
[13:31] <wallyworld_> benji: i'm tired now so i'll very likely rework the mp tomorrow morning
[13:33] <benji> wallyworld_: have a good rest, re. "the other way around.": I might have miscomunicated, I intended the tests to never need to encode and only encode in real life when neccesary
[13:33] <wgrant> wallyworld_: Sorry to pedantic, but I don't think it's a really great idea to, after fixing a bug which was caused by code not handling the whole input domain, replace the good fix with one that is known not to handle the whole input domain, and presume it will be good because users won't do crazy things.
[13:33] <wallyworld_> benji: yes. i think we're both on the same page
[13:33] <wgrant> If you are relying on users not doing crazy things, you probably have a bug.
[13:34] <wgrant> And someone will find it.
[13:35] <wallyworld_> wgrant: can't argue your points. it's been a good discussion thanks. i'm happy we've converged on a solution that's easily to implement that achieves the goals
[13:35] <wgrant> Yup.
[13:35] <benji> wgrant: the idea was to not base64 encode unless there is an invalid character in the ID, that way the tests will be fine and we'll still cover the real-world corner cases
[13:35] <wgrant> Sounds reasonable.
[13:56] <henninge> adeuring: Hallo! ;)
[13:56] <henninge> adeuring: my laptop is blocked branching LP trunk ...
[13:56] <henninge> adeuring: I still have to install mumble
[13:57] <adeuring> henninge: ok...
[13:57] <henninge> adeuring: oh, works
[13:57]  * henninge tried to use software center but that did not start
[14:07] <LPCIBot> Project windmill-db-devel build #314: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-db-devel/314/
[14:20] <deryck> Morning, all.
[14:20] <deryck> abentley, adeuring, henninge -- you guys done with standup?
[14:20] <abentley> deryck: morning, yes we are.
[14:21] <deryck> ok, cool.
[14:21] <henninge> Hi deryck!
[14:21] <deryck> sorry about running late.
[14:21] <deryck> Thanks for going ahead with it.
[14:26] <deryck> henninge, bug 785637 is still marked in progress, but the linked branch is merged.  Has it passed buildbot yet?
[14:26] <henninge> n
[14:26] <henninge> o
[14:27] <henninge> deryck: it's in there now
[14:27] <deryck> o
[14:27] <deryck> k
[14:27] <deryck> ;)
[14:27] <henninge> ;)
[14:29] <jcsackett> wallyworld: it
[14:29] <jcsackett> it's sort of shocking to wake up to so many cards moved across kanban. :-P
[14:30] <jml> :)
[14:31] <bigjools> I hope they were all pie-critical?
[14:32] <deryck> abentley, ready when you are.
[14:32] <abentley> deryck: Coming...
[14:32] <deryck> np
[14:32] <jcsackett> bigjools: alas, we're on feature work, which doesn't hit the pie-critical queue.
[14:32] <jcsackett> or at least, doesn't hit it very often.
[14:32] <bigjools> a crying shame
[14:35] <LPCIBot> Project windmill-devel build #129: STILL FAILING in 1 hr 18 min: https://lpci.wedontsleep.org/job/windmill-devel/129/
[14:37] <sinzui> jcsackett: do you have time to mumble?
[14:38] <jcsackett> sinzui: i do.
[14:38]  * jcsackett fires up mumble
[15:16] <nigelb> sinzui: Well, yesterday's sort is not qa-ok per se.
[15:16] <nigelb> I need to do a .lower() of the element.
[15:16] <LPCIBot> Project windmill-db-devel build #315: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-db-devel/315/
[15:16] <sinzui> nigelb: yes, you can do that. qa-ok means it is safe to roll out. It will not break. So you can report an new bug and show me the fix.
[15:17] <nigelb> sinzui: awesome, I'll do that :)
[15:17] <sinzui> nigelb: did you see alejandra in the listing?
[15:18] <nigelb> sinzui: which one?
[15:19] <sinzui> In my qa, I saw alejandra was the last user listed because she was the only lowercase display name
[15:21] <nigelb> sinzui: ah, I did a qa with some other starting with lowercase 'a'
[15:26] <LPCIBot> Project windmill-devel build #130: STILL FAILING in 50 min: https://lpci.wedontsleep.org/job/windmill-devel/130/
[15:59] <bigjools> it'd be really nice if bug triagers tagged bugs please
[16:00] <sinzui> benji: I may have stepped in your review of https://code.launchpad.net/~wallyworld/launchpad/better-popup-show-widget-name/+merge/62113 . The branch appears to reimplement FormattersAPI.css_id
[16:02] <benji> sinzui: no worries; that review was paused after some discussion here about better ways to accomplish the desired result; your contribution looks valuable too
[16:02] <sinzui> bigjools: +1. I constantly revisit recently triaged bugs
[16:03] <bigjools> sinzui: me too
[16:03] <bigjools> to tag them :)
[16:05] <benji> sinzui: I don't understand how css_id avoids collisions.  What if you had two strings for IDification "foo@bar" and "foo&bar"; would they not both end up as "foo-bar"?
[16:06] <sinzui> benji: it does not. You need to think, as is done in registry.browser.product.ProductView to create widgets for a listing or projects
[16:08] <sinzui> Project names are unique so the engineer is responsible for choosing the namespace. Since the id is used in testing and scripts. The engineer should choose a name we can read and want to maintain
[16:09] <benji> sinzui: I meant even given a namespace prefix you could still have the same ID generated.  E.g., I choose "PREFIX-" as the prefix and there is a project named "foo@bar" and another named "foo&bar" and I want to represent both on the same page, they both will have IDs "PREFIX-foo-bar".
[16:10] <sinzui> benji: I do not think "foo@bar" and "foo&bar" are real cases in Lp name  (unique id) rules.but I can image we could support transliteration instead of substution
[16:11] <abentley> gmb: Could you please review https://code.launchpad.net/~abentley/launchpad/handle-concurrent-lint/+merge/62139 and https://code.launchpad.net/~abentley/launchpad/retry-job/+merge/62145 ?
[16:11] <gary_poster> sinzui, I have a user who is a spammer (all 10 comments are spam).  I marked comments as spam.  Should I deactivate the user next?
[16:11] <gary_poster> Or is there some other procedure
[16:12] <sinzui> gary_poster: If the user has zero karma, yes. If the user has karma, you should contact him and explain that we will suspend him if he does  not confirm he has taken control of his computer, browser, and email account.
[16:13] <gary_poster> sinzui, 0 karma.  Cool, thanks.
[16:13] <sinzui> gary_poster: https://wiki.canonical.com/Launchpad/DealingWithSpam#Dealing with spam
[16:13] <sinzui> \o/ an easy one
[16:14] <gary_poster> bigjools, sinzui: triaging bugs: the only tags I know if that are particularly important are critical bugs that need to be tagged regression, timeout, oops.  Are there other important tags/actions?  If so, is this documented?
[16:14] <gary_poster> sinzui, I thought we had a page, but should have checked on the internal wiki.  Thanks.
[16:14] <LPCIBot> Project db-devel build #575: FAILURE in 6 hr 1 min: https://lpci.wedontsleep.org/job/db-devel/575/
[16:14] <bigjools> gary_poster: I have a bunch of standard soyuz-related ones that I can educate maintenance teams about if you'd like
[16:14] <bigjools> ideally on a wiki page for sure
[16:15] <bigjools> hey, we used to have one of those :)
[16:15] <sinzui> gary_poster: I add tags that describe the objects in play and the kind of issue eg: ppa+email, teams-ui
[16:15] <sinzui> the tag widget is very good at suggesting
[16:16] <gary_poster> bigjools...I guess.  CHR docs are already quite long in parts, and I'm encouraging my squad to do things to make things shorter (like Danilo is going to make the translations stuff much easier hopefully)
[16:16] <bigjools> sinzui: it is indeed
[16:16] <bigjools> gary_poster: I agree with making things easier - this is why I really recommend the effort of tagging up front as it reduces pain later
[16:17] <gary_poster> sinzui, bigjools, ok...we can make an effort.  It feels pretty ad hoc
[16:17] <gary_poster> ok, I'll hold further comments till after we try it a while :-)
[16:18] <sinzui> gary_poster: it is because the user did not know how to describe the issue into domains and uses
[16:19] <abentley> gary_poster: does https://dev.launchpad.net/BugTriage help?
[16:19] <gary_poster> sinzui: ...yeah, that seems to describe my general concern...
[16:19] <gary_poster> abentley, I don't see the word "tag" on that page, which is what I'm talking about
[16:20] <abentley> gary_poster: True, but "oops" "regression" and "timeout" are there...
[16:20] <sinzui> gary_poster: I was working with question emails a few weeks ago. I search for questions+email and located all the bugs related to the code I was in. I fix 4 critical bugs and 7 low bugs. The low bugs would not have been fixed if the bugs were not properly tagged
[16:21] <gary_poster> abentley, yeah, thanks.  those are the three I'm most comfortable with, and that our squad is working with already.
[16:22] <gary_poster> sinzui, I'm not questioning value, but process.  But really, let's table this discussion until my squad has given it a try for a while.
[16:22] <sinzui> gary_poster: remember that you want to tag bugs my team create a disclosure to ensure my team works them. otherwise you get extra work :)
[16:22] <gary_poster> heh
[16:22] <sinzui> s/a/as/
[16:27] <abentley> gary_poster: I've added the word "tagged" to the page :-)
[16:27] <gary_poster> abentley, lol, cool, thanks
[16:28] <bac> gmb: time for a wee review?  https://code.launchpad.net/~bac/launchpad/bug-777789-2/+merge/62150
[16:28] <gmb> bac: Sure
[16:30] <gmb> bac: r=me
[16:30] <bac> gmb: thanks
[16:37] <LPCIBot> Project windmill-devel build #131: STILL FAILING in 1 hr 11 min: https://lpci.wedontsleep.org/job/windmill-devel/131/
[16:47] <LPCIBot> Project windmill-db-devel build #316: STILL FAILING in 1 hr 16 min: https://lpci.wedontsleep.org/job/windmill-db-devel/316/
[16:48] <jcsackett> sinzui: http://people.canonical.com/~jc/images/lp-id-screenshots/
[16:48] <jcsackett> i'm working on something better on the profile page. the current inline versions are terrible.
[16:48] <jcsackett> but i realized it was getting on towards noon so i thought i'd ping you with the versions i have.
[16:49] <jcsackett> sinzui: after seeing them rendered it, doing it with the "Launchpad Id:" thing looks terrible.
[16:49] <sinzui> jcsackett:  would the example be clearer if there were two comments from two different Jonathans?
[16:50] <jcsackett> sinzui: on the pickers shots?
[16:51] <sinzui> and comments. I have seen two Toms posting messages in a bug conversation
[16:51] <sinzui> I think we should not submit the Launchpad-Id example. It really is more annoying than explict
[16:52] <jcsackett> sinzui: sure, i can set those up. and i'll just kill the Launchpad-Id, as i concur. it's just terrible.
[16:52] <sinzui> jcsackett: and the picker examples were be more convincing of the problem we are solving if the users had hidden email addresses
[16:53] <jcsackett> sinzui: dig.
[16:55] <sinzui> jcsackett: I had not thought to put the Lp-id in the profile page title. I think users may expect that though. I look forward to user feedback
[16:59] <jcsackett> sinzui: it seems we should probably standardize where we can if we go down this road.
[17:00] <sinzui> jcsackett: that is the intent of this  excercise
[17:00]  * sinzui is reporting a bug about IRC nicks at this moment
[17:10] <henninge> gmb: Hi! Here is an easy one to send you home with .... ;)
[17:10] <henninge> https://code.launchpad.net/~henninge/launchpad/bug-683406-xss-ppa/+merge/62158
[17:10] <gmb> henninge: Righto!
[17:26] <jcsackett> sinzui: updated http://people.canonical.com/~jc/images/lp-id-screenshots/
[17:27] <sinzui> jcsackett: that looks good to test
[17:28] <jcsackett> sinzui: cool. email the link to mrevell (who has now been pinged, if he's listening...)
[17:28] <jcsackett> >
[17:28]  * jcsackett fails at typing.
[17:28] <jcsackett> just assume that last bit was a question. :-P
[17:28] <mrevell> um
[17:28]  * mrevell reads up a bit
[17:29] <sinzui> mrevell: we want to show Launchpad-id in comments and in the person picker so user are not confused by similar user display names. We do not know how to represent the Launchpad Id
[17:30] <mrevell> Ahhh
[17:30] <mrevell> cool
[17:30] <mrevell> Wow, that rocks.
[17:30] <jcsackett> i can email you a zip of these images if you would prefer, mrevell.
[17:31] <mrevell> jcsackett, Nah, the link on people.c.c is fine. Thanks. Sorry I was a bit slow off the mark.
[17:31] <jcsackett> mrevell: all good. :-)
[17:34] <jcsackett> sinzui: you wanted to mumble a bit again post-mockups, yeah?
[17:38] <LPCIBot> Project windmill-db-devel build #317: STILL FAILING in 51 min: https://lpci.wedontsleep.org/job/windmill-db-devel/317/
[19:16] <jcsackett> sinzui: ready to chat again when you are.
[19:16] <sinzui> jcsackett: I was just going to try to configure sip
[19:17] <jcsackett> sinzui: cool. i think i have sip setup. at least, i am told that i do.
[19:18] <sinzui> jcsackett: I have credentials I tested 4 years ago
[20:03] <sinzui> jcsackett: http://www.youtube.com/watch?v=r711rZ4M5K0 . The fish joke stars about 1 minute 25 into the scene, but the last part is missing. Mike returns empty handed and asks "What's this fish doing in my bed", and the rest ask, "What fish?"
[20:07] <jcsackett> that's excellent.
[20:08] <deryck> lifeless, ping
[20:09] <LPCIBot> Project windmill-db-devel build #318: STILL FAILING in 1 hr 11 min: https://lpci.wedontsleep.org/job/windmill-db-devel/318/
[20:12] <bac> hi sinzui, do you know anything about bug 490767?
[20:12] <_mup_> Bug #490767: Cannot post a comment on an existing bug with Konqueror. <comments> <javascript> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/490767 >
[20:13] <bac> lifeless mentions an email thread but i cannot find it
[20:14] <sinzui> bac I think it was escalated without being confirmed it is still a problem. Check the age of the bug against the fact Konqueror got a major upgrade.
[20:14] <sinzui> There are no dupes or other affected users either
[20:14] <bac> sinzui: right, i cannot reproduce it with current konq in lucid or natty
[20:15]  * bac closes
[20:15] <sinzui> Konqueror now uses webkit
[20:15] <bac> i'm just curious as to what new info caused it to be escalated
[20:15] <sinzui> bigjool, thumper, and flacoste are also kubuntu users
[20:16] <sinzui> lifeless reconnised the description as a script fault
[20:16] <sinzui> s/reconnised/recognised/
[20:16] <sinzui> I would close it, or at the very least mark it incomplete
[20:17] <sinzui> bac: this bug may also be fixed for the same reasons: bug 457784
[20:17] <_mup_> Bug #457784: When bugs reporting tries to report bug in Kubuntu,  using Konqueror, "I am affected by this bug" popup does not works <filebug> <javascript> <lp-bugs> <ui> <Launchpad itself:Triaged> <kde4libs (Ubuntu):Invalid> < https://launchpad.net/bugs/457784 >
[20:19] <deryck> sinzui, your team is doing the disclosure story now, right?
[20:19] <sinzui> bac: and If you are using konqueror right now, you can check bug 546813 and close it if it was fixed by one of our rounds to ensure empty anchors are not used
[20:19] <_mup_> Bug #546813: Bugtask table "Affects" edit icon missing in Konqueror <css> <lp-bugs> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/546813 >
[20:19] <sinzui> deryck: yes
[20:19] <deryck> ok, thanks
[20:19] <bac> sinzui: will do
[20:19] <deryck> sinzui, I think bug 419531 should be downgraded to high.  I'm commenting as such in the bug now.
[20:19] <_mup_> Bug #419531: project name picker search / vocabulary is hard/impossible to use (too many results on exact searches) <disclosure> <regression> <vocabulary> <Launchpad itself:Triaged> < https://launchpad.net/bugs/419531 >
[20:20] <deryck> can it really be a regression if it was opened two years ago? ;)
[20:20] <sinzui> bac: bug 255294 is surprising if it is true.
[20:20] <_mup_> Bug #255294: Links with target=help don't render on Konqueror <javascript> <lp-web> <Launchpad itself:Triaged> < https://launchpad.net/bugs/255294 >
[20:21] <flacoste> sinzui: i'm a Ubuntu user who uses a lot of KDE apps (but I'm no longer a Kubuntu user)
[20:21] <flacoste> and i don't use konqueror
[20:21] <flacoste> bac: i'm not sure Critical was the right priority for this
[20:21] <flacoste> bac: konqueror isn't a supported browser
[20:22] <flacoste> JS errors are critical, sure
[20:22] <sinzui> deryck: I agree. The project picker is better than it was tree years ago. It is not a regression. It just continues to suck
[20:22] <bac> flacoste: good to know
[20:22] <flacoste> but if it only affects a low-following browser, i'm not sure Critical is the right priority there
[20:23] <flacoste> we often discussed that we don't have the resources to test/support all browsers
[20:23] <deryck> sinzui, exactly!  And while sucking sucks, it doesn't make it critical. :-)
[20:23] <sinzui> The timeout will stop the user from selecting a project in some forms unless you do the trick in the work around
[20:24] <flacoste> konqueror is 0.22% of our audience
[20:25] <sinzui> deryck: the timeout makes it critical. disclosure makes it high. My team will officially start on it in 2 weeks, but I believe one or two members of the squad will address the performance issue next week
[20:25] <flacoste> IE is 5.4%
[20:25] <flacoste> and Opera even beats it at 3.20%
[20:25] <deryck> flacoste, I also think we should downgrade bug 490767 to HIGH or LOW since we don't support Konq.
[20:25] <_mup_> Bug #490767: Cannot post a comment on an existing bug with Konqueror. <comments> <javascript> <lp-bugs> <Launchpad itself:Invalid> < https://launchpad.net/bugs/490767 >
[20:26] <flacoste> deryck: it is marked invalid
[20:26] <deryck> oh, heh
[20:26] <deryck> flacoste, sorry, I had it open to ask about and never refreshed. :-)
[20:26] <deryck> I see bac is working over all the konq bugs.
[20:27] <deryck> I'm just trolling for new work and getting bugs off the list however I can! :-)
[20:27] <sinzui> bac also closed an IRC nick bug today, but landed the work last August. bac rocks.
[20:27] <bac> deryck: apparently if you launch konq you get to touch all the bugs!  :)
[20:27]  * flacoste is amazed that 25% of our visits come from Windows client
[20:28] <bac> sinzui: what IRC nick bug?
[20:28] <deryck> sinzui, should we file a new bug about the timeout as critical?  it really is two wildly, separate issues.
[20:28] <flacoste> beats Mac users who are 4.25%
[20:28] <bac> flacoste: and most of those work on launchpad
[20:28] <bac> s/those/them
[20:28] <sinzui> flacoste: Lp has spectacular Google fu
[20:29] <sinzui> bac: the bug was about contradictory instructions when adding an irc nick, and the presentation of that nick on the profile page
[20:30] <sinzui> We no longer ask for irc:// nor present it
[20:32] <sinzui> deryck: The picker timeout is ultimately caused by a missing ranking, and an improper use of fti. The impelmentation causes bad UI and timeouts. So my squad will fix both
[20:32] <deryck> sinzui, gotcha.  thanks for supporting my downgrading it. :-)
[20:33] <sinzui> This action will also permit my squad to contribute to the critical count
[20:33] <abentley> deryck: boo.  I hoped when you touched bug 419531 that you were going to fix it. :-(
[20:33] <_mup_> Bug #419531: project name picker search / vocabulary is hard/impossible to use (too many results on exact searches) <disclosure> <regression> <vocabulary> <Launchpad itself:Triaged> < https://launchpad.net/bugs/419531 >
[20:33] <deryck> abentley, not me, sorry.  but sinzui's team is.  So some hope there, no?
[20:34] <abentley> deryck: Yes, some hope.
[20:37] <lifeless> deryck: hi
[20:38] <deryck> lifeless, hi.  See my scrollback discussion with sinzui or look at what I said/did on bug 419531.
[20:38] <_mup_> Bug #419531: project name picker search / vocabulary is hard/impossible to use (too many results on exact searches) <disclosure> <regression> <vocabulary> <Launchpad itself:Triaged> < https://launchpad.net/bugs/419531 >
[20:38] <deryck> lifeless, just wanted to argue that bug should be high, but I just changed it.  and can certainly discuss if you disagree.
[20:40] <flacoste> lifeless: sorry to have stood you up yesterday, but it was a public holiday in Canada
[20:40] <lifeless> deryck: its a regression
[20:40] <lifeless> flacoste: ah! no worries
[20:41] <deryck> lifeless, for some value of the word "regression," no? :)
[20:41] <flacoste> lifeless: in what way it's a regression?
[20:42] <flacoste> i don't think this ever worked
[20:42] <flacoste> the regression tag was added 2 years after the initial bug
[20:42] <deryck> flacoste, I think he means in a world before pickers you didn't get this error.
[20:42] <lifeless> flacoste: the UI used to be a text field plus 'choose'
[20:43] <lifeless> flacoste: in that world you could select 'launchpad' as the project
[20:43] <lifeless> flacoste: now the UI is a popup
[20:43] <flacoste> ah right
[20:43] <lifeless> flacoste: and its impossible to select launchpad as the project
[20:43] <flacoste> i forgot about that
[20:43] <lifeless> how is that *not* a regression
[20:44] <lifeless> deryck: I don't see it needing feature level work: oh theres tonnes that could be done but special casing an exact match is < 4 hours work
[20:45] <lifeless> deryck: anyhow, the current rule we have is 'tagged regression -> critical'
[20:45] <deryck> lifeless, maybe "needing feature level work" is the wrong phrase.  it will be fixed by sinzui's team doing feature work.  or it is part of the disclosure feature anyway.  or some other phrasing.
[20:45] <lifeless> deryck: so lets finish discussing whether its a regression or not.
[20:45] <flacoste> deryck: that doesn't lower it's priority nor remove the regression tag :-)
[20:45] <deryck> right
[20:45] <deryck> flacoste, right.  but I don't consider it a regression, that is my main point.
[20:45] <lifeless> Do you agree that something users could do before, and can't now?
[20:45] <deryck> but I knew regression purists would disagree and was looking for more ammo ;)
[20:46] <flacoste> deryck: it's been a long-standing regerssion
[20:46] <lifeless> deryck: And further, do you agree that it wasn't an *intentional* restriction in functionality?
[20:47] <flacoste> because lifeless is right, the regression doesn't come from the pop-up itself, that vocabulary has always been broken
[20:47] <flacoste> but before that, the picker was optional
[20:47] <flacoste> now it's not
[20:47] <flacoste> before the picker was used to pre-fill a text field
[20:48] <flacoste> now the text-field is gone
[20:48] <deryck> sure, but that's by design.
[20:48] <deryck> that's all I'm saying.  it's not the same kind of regression.
[20:48] <flacoste> it is
[20:48] <deryck> it's a two year old bug
[20:48] <flacoste> the bug report is actually too vague
[20:49] <deryck> no, I understand the problem perfectly.
[20:49] <flacoste> the regression is that on some specific pages, you could enter a team/project name
[20:49] <flacoste> in case the picker failed you
[20:49] <flacoste> you can't anymore
[20:49] <deryck> I know, I remember :-)
[20:49] <flacoste> it's really a different bug
[20:49] <lifeless> well
[20:49] <flacoste> so yes, that specific bug report isn't a regression per se
[20:49] <lifeless> ok, now I'm lost
[20:49] <flacoste> but there is another one (unfiled) that is
[20:50] <lifeless> flacoste: step me through this?
[20:50] <deryck> if it's this complicated, it can't be a regression.  or at least it doesn't matter.
[20:50] <deryck> :-)
[20:50] <lifeless> deryck: why do you want this to not be a regression? What does it help you with ?
[20:51] <lifeless> flacoste: also, would you like to do a call today?
[20:51] <deryck> lifeless, I fear the precedent of js changes behavior, you now can't do what you did before, and it's a critical bug.
[20:51] <flacoste> lifeless: i have a call with gary in 10 minutes, i could do after that, but we could have more time tomorrow as i don't have any in the afternoon
[20:52] <deryck> I just don't like the word regression for this.  maybe it's just me
[20:52] <flacoste> lifeless: the picker was actually always broken, that's not a regression
[20:52] <lifeless> deryck: so I think if we deliberately change the UI to be nicer that the old UI going is *not* a bug in any regard.
[20:53] <flacoste> the regression is that in some case, we remove the possibility of not using the picker
[20:53] <lifeless> deryck: but if an existing bug prevents using the nicer UI to accomplish stuff, we've essentially removed a workaround and have to consider the combination of events a regression
[20:53] <flacoste> but fyi, on forms, the picker is still optional
[20:53] <flacoste> it's on inline-edit forms (new design) that it's impossible to use
[20:53] <deryck> flacoste, but we're not going to fix it so you can get an input element.  we're committed to removing the input element as an option.
[20:53] <flacoste> deryck: agreed
[20:54] <flacoste> but i don't think we removed any form yet
[20:54] <deryck> so the picker is bugged, not regressed.
[20:54] <flacoste> yes
[20:54] <lifeless> deryck: thats fixable in two ways: restore the old UI (fugly) or fix the new UI to permit the old workflow
[20:54] <flacoste> we have been constant there :-)
[20:54] <flacoste> lifeless: actually, i'm pretty sure that all the boomerang pages still exist
[20:54] <flacoste> with the old way of selecting things (text field + picker)
[20:54] <lifeless> flacoste: even in shiny shiny like recipes?
[20:54] <flacoste> they might not be linked to though
[20:55] <lifeless> flacoste: right
[20:55] <deryck> lifeless, but we're not going to fix the ui to allow the old workflow, here.  and going back is not an option for these js workflows.  and you can still right-click your way to a real page.
[20:55] <flacoste> if it's shinny new, it's not a regression ;-)
[20:55] <deryck> lifeless, therefore, I don't see us calling this a regression.
[20:55] <lifeless> so why do I want to call this a regression
[20:55] <lifeless> because I can't see our users considering it anything else
[20:55] <deryck> you have a pedantic streak in you ;) :)
[20:56] <flacoste> deryck: i think he's striving for clarity :-)
[20:56] <deryck> I meant that in fun, not insulting way
[20:56] <lifeless> if we change something and the result doesn't work, *and* we didn't intend to make things not work
[20:56] <lifeless> then I think users would say that we've regressed in functionality
[20:57] <deryck> maybe so.  but to me that's not the issue.  not what they would *say*.  I do care that they're blocked.  and I do think this should have been fixed well before now.
[20:57] <lifeless> if we explicitly said 'we don't care about folk searching for exact matches', it would be entirely different
[20:58] <lifeless> deryck: so if this is tagged regression and we had the regression-jumps-queue policy two years ago, it would have been fixed well before now.
[20:58] <deryck> sure.
[20:58] <lifeless> deryck: are you worried that we have other regressions sitting in our 6K database?
[20:58] <deryck> but even today, I wouldn't call this a regression
[20:58] <deryck> partly, yes.  and partly, I fear the slippery slope.  especially when you start saying "a user would say this is a regression, so it is"
[20:59] <deryck> it's really that ^^ mostly
[20:59] <deryck> in that case, lp is nothing but one big regression, and for a certain class of user that is completely true and valid.
[20:59] <bac> sinzui: regarding bug 255294, the help pop-up does appear now and is readable, which is good.
[20:59] <_mup_> Bug #255294: Links with target=help don't render on Konqueror <javascript> <lp-web> <Launchpad itself:Triaged> < https://launchpad.net/bugs/255294 >
[20:59] <lifeless> I don't think thats true
[20:59] <lifeless> deryck: we can always make an explicit choice when changing something
[21:00] <lifeless> deryck: but unexpected consequences *are* regressions I think; we can say 'actually thats a consequence we like, WontFix'
[21:00] <bac> sinzui: unfortunately, most of the sprites do not appear!
[21:01] <allenap> lifeless: Hi. By any (remote) chance do you have some time in the next 30 minutes to chat about Rabbit? If not, some time tomorrow or later in the week?
[21:01] <lifeless> deryck: or 'the use case didn't work before it just looked like it did', and mark it low
[21:01] <lifeless> allenap: sure do
[21:01] <bac> sinzui: so on a project page, the help icon is not shown but if you know where it *should* be you can make the help pop-up pop.
[21:01] <sinzui> bac: okay, The real defect bug 521219 and that is really Lp making bad markup. It affects web kit to some degree too
[21:01] <_mup_> Bug #521219: Konqueror does not display sprite for empty element <css> <lp-web> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/521219 >
[21:01] <lifeless> deryck: what I don't understand is how 'could do X -> cannot do Y' can be not-a-regression
[21:01] <deryck> lifeless, but every bug is an unexpected consequence.
[21:01] <lifeless> deryck: I understand that at no point did we revert out a patch
[21:02] <allenap> lifeless: Awesome :) Mumble, Skype...?
[21:02] <lifeless> allenap: in ~ 15 minutes, skype.
[21:02] <sinzui> bac: oh, update the bug then. The issue may also be a sprite on empty markup
[21:02] <allenap> lifeless: Cool, thanks.
[21:02] <lifeless> deryck: yes, but not all unexpected consequences prevent doing things
[21:02] <bac> sinzui: ok.  i'll close 255294
[21:02] <LPCIBot> Project windmill-db-devel build #319: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-db-devel/319/
[21:03] <deryck> lifeless, I guess I don't see users being prevented here.  you can click through to a real form if you want in every case.
[21:03] <deryck> it's a search or picker bug.  a new bug.  with unintend consequences.  the ui changed.  it didn't regress.
[21:03] <lifeless> deryck: I assert that without user testing its impossible to agree or not agree
[21:03] <deryck> fair enough.
[21:03] <deryck> lifeless, may I approach this another way?
[21:04] <deryck> do you have the time?
[21:04] <lifeless> of course
[21:04] <lifeless> this is kindof my job :)
[21:04] <deryck> maybe a better way is to say, "I don't think this is a queue jumping bug"
[21:04] <deryck> even if it happened today.
[21:05] <deryck> it shouldn't sit around for two years, and it shouldn't be released with crappy basic search not working, but I just don't think it's enough to be critical.
[21:05] <lifeless> mmm
[21:05] <lifeless> so lets say then that we had no criticals
[21:06] <lifeless> that is, that while we have a huge number of bugs, every use case that we have implemented is working
[21:06] <lifeless> things we haven't implemented are working, but thats fine we'll get to them
[21:06] <lifeless> now, purple squad come along and ajaxify the PPA package copy screen
[21:07] <lifeless> there is a bug in their js and copies from security ppas to the main archive security pocket don't work
[21:07] <sinzui> deryck: I have been saying that for many years. we cannot have more criticals or highs then we can plan to fix without interruption. The fact that we let failed to be honest about the importance of bugs, and worked on other bugs put us into this mess
[21:07] <lifeless> and they removed all visible links to the non-ajax UI
[21:08] <lifeless> deryck: when its released we find out from the ubuntu security team immediately when they go 'zomg cannot unembargo xyz disclosure'
[21:08] <deryck> the use of "security" here makes this more important than current issue, I think.
[21:08] <lifeless> deryck: what would we do ?
[21:08] <lifeless> deryck: thats deliberate
[21:09] <deryck> I think it's critical because of "security" not because of removing old ui.
[21:09] <deryck> and it's not a regression
[21:09] <lifeless> we have existing bugs affecting the ubuntu security team that are only high.
[21:09] <lifeless> bugs where they cannot do things
[21:09] <lifeless> [this bit isn't fictional, its real]
[21:10] <deryck> ok, so maybe I'm reading too much into the word "security" and picturing ubuntu cannot make a security update.
[21:10] <lifeless> deryck: that is the scenario
[21:10] <lifeless> deryck: something they could do and now they can't, and its something very important
[21:11] <deryck> but I'd call it critical for that reason.  the impact.  I don't consider removing a web 1.0 link in favor of js a ui regression.
[21:11] <lifeless> deryck: I think we'd rollback the UI via its feature flag until fixed
[21:11] <deryck> sure
[21:11] <deryck> agreed
[21:11] <lifeless> deryck: but the bug does not say 'put the 1.0 link back'
[21:11] <deryck> right
[21:11] <deryck> but there is no way this picker search bug is near the impact of that security bug
[21:11] <lifeless> deryck: the bug says 'trying to do X, which I could before, and I get Y (an error)'
[21:12] <deryck> no, "can't make an Ubuntu security udpate" vs. "can't search for the project I want" are worlds apart in impact.
[21:12] <lifeless> deryck: so I'm arguing that things of that pattern, unless we wanted that result, are regressions.
[21:13] <lifeless> our users, the people we write Launchpad for, don't care about the implementation choices of our system, they care about the things they can do with it.
[21:13] <lifeless> any discussion about regression that talks implementation rather than doable-things is (IMO) missing the point
[21:13] <deryck> sure, we're agreed about that.  I think in practice this naming of things -- "regression" or not -- is really not that important to our users.
[21:14] <lifeless> I think its vitally important to our users because its a queue jumping mechanism (for good or bad)
[21:14] <deryck> sure, I think I'm talking about doable things.
[21:14] <lifeless> deryck: but you're not: you're talking about implementation - about replacing the widgets we used
[21:15] <deryck> in order to try to define a regression.
[21:15] <deryck> how about this....
[21:15] <deryck> if we change the UI and introduce a bug, that is not a regression to me.
[21:15] <deryck> no matter what you could do before.
[21:15] <lifeless> so for me its clearly conditional.
[21:15] <lifeless> the conditions being:
[21:16] <lifeless>  - you could do X before
[21:16] <lifeless>  - we didn't intend to disable X
[21:16] <deryck> but we did!
[21:16] <lifeless>  - with a grey are for X's that were only accidentally possible in the first place
[21:17] <lifeless> deryck: we wanted to stop people selecting launchpad when asked to choose a project?
[21:17] <deryck> no
[21:17] <lifeless> then clearly we didn't intend to disable X
[21:18] <deryck> so how are people assigning a bug to launchpad today?
[21:19] <lifeless> I don't know :). Certainly not through the 'normal' UI
[21:19] <deryck> I would describe this as: we introduce a new ui, search is broken for that ui
[21:19] <deryck> people can still right-click their way to the old ui and enter names directly.  it's not ideal, but you can do it that way if you want.
[21:19] <deryck> that's why I speak of impact.
[21:19] <lifeless> but do they know that?
[21:20] <deryck> not every Launchpad user, no.  of course not.  but I think we have fairly web savy users.  clearly they put up with a lot from us so far. :-)
[21:20] <deryck> this is not to excuse the current behavior.
[21:20] <deryck> I just fail to see how introducing a new ui with bugs is a regression.
[21:21] <deryck> I don't think we'll ever agree about this.
[21:21] <lifeless> I'd say lets talkin Dublin
[21:21] <lifeless> but I won't be there
[21:21] <deryck> yeah, and I don't particularly enjoy talking about things where we aren't likely to get much consensus.
[21:21] <lifeless> I intensely dislike the 'introduce new thing and its bugs get carte blanche' slope
[21:22] <deryck> sure, and I don't intend to argue that.
[21:22] <lifeless> I totally get that a new thing may be worse in some ways than an old thing
[21:22] <lifeless> thats inevitable
[21:22] <deryck> I would prefer we never released this widget, and I hope that the current review process with jml's team makes this go away.
[21:23] <lifeless> deryck: right! its essentially tech debt from a prior project that didn't get to the standard it needed to be consumer ready
[21:23] <deryck> but bugs are inevitable.  and I think we dealing with a new UI, it's easier to judge impact, then the semantics of whether or not it's clearly a regression.
[21:23] <deryck> lifeless, yes, agreed.
[21:23] <lifeless> all our critical are either stakeholder escalations, things changing on us (e.g. browser support ones) or things we've done to ourselves potentially far in the past
[21:24] <deryck> sure.
[21:24] <deryck> I don't see what that has to do with whether or not this sort of bug is a regression and therefore critical.
[21:24] <lifeless> in terms of judging impact
[21:24] <lifeless> I worry
[21:25] <lifeless> I think if we want an impact-based assessment for queue jumping, we should remove regression as a queue jumper - to be honest about how we assess things
[21:26] <deryck> And I would be ok with that. :-)
[21:26] <deryck> I think "regression" is an attempt to had objective assessment to something that always has to be subjectively assessed.
[21:26] <deryck> I think regressions are seldom clear cut for a web app.
[21:26] <deryck> we don't do releases after all
[21:27] <lifeless> anyhow, the old UI is broken these days too
[21:27] <lifeless> go here
[21:27] <lifeless> https://bugs.qastaging.launchpad.net/launchpad/+bug/419531/+editstatus
[21:27] <_mup_> Bug #419531: project name picker search / vocabulary is hard/impossible to use (too many results on exact searches) <disclosure> <regression> <vocabulary> <Launchpad itself:Triaged> < https://launchpad.net/bugs/419531 >
[21:27] <lifeless> type bazaar into the input box for project
[21:27] <deryck> timeout and oops is easy to objectively assess.  functionality for a web app is not.
[21:27] <lifeless> click on save changes
[21:27] <lifeless> 'There are 2 errors in the data you entered. Please fix them and try again.
[21:27] <lifeless> '
[21:27] <lifeless> 'Enter a project name'
[21:28] <lifeless> with bazaar sitting there in plain text
[21:28] <deryck> hmmm, I didn't get that error.
[21:28] <allenap> lifeless: I see you're still busy. Would you have time in the morning, around 8pm your time?
[21:28] <deryck> but I know the one you speak of
[21:28] <lifeless> allenap: no, because 6am phone call for TL meeting
[21:28] <deryck> allenap, sorry I sidelined lifeless from you.
[21:28] <lifeless> allenap: lets call now
[21:28] <allenap> lifeless: Okay.
[21:28] <allenap> Ring when you're ready.
[21:29] <allenap> deryck: No worries :) He's in demand!
[21:29] <lifeless> deryck: I'm going to put this back to critical, because the OLD UI has been broken too; I'm not trying to close off the conversation - but I need to given allen a hand
[21:29] <deryck> lifeless, thanks for the chat.  sorry to be so stubborn on this.  but well, I just am on ui judgements. :-)
[21:29] <lifeless> deryck: strong opinions are good - we learn from such things
[21:29] <deryck> lifeless, while I strongly disagree that this is critical, I respect that you're the TA and can make that call. :-)
[21:29] <lifeless> allenap: whats your skype id ?
[21:29] <allenap> lifeless: gavinpanella
[21:29] <lifeless> ah, I see it
[21:33] <lifeless> allenap: https://dev.launchpad.net/ArchitectureGuide/Services
[21:33] <thumper> sinzui: you should drop me off the kubuntu users, and add wallyworld_ :-)
[21:35] <sinzui> I think we might want to survey ourselves at the next thunderdome. OSes, distros, browsers, editors
[21:35] <sinzui> The non vim/emacs can sit at the children's table with me
[21:39] <LPCIBot> Yippie, build fixed!
[21:39] <LPCIBot> Project db-devel build #576: FIXED in 5 hr 24 min: https://lpci.wedontsleep.org/job/db-devel/576/
[21:45] <Ursinha> OOPS-1970CG450
[21:49] <jcsackett> sinzui: how would your survey handle those of us who regularly use two or more things in a given category?
[21:50] <sinzui> one moment
[21:50] <sinzui> jcsackett: this is what I collected from staging: http://pastebin.ubuntu.com/612449/
[21:51] <jcsackett> huh. i'm surprised we don't have more people with two irc nicks, honestly.
[21:52] <sinzui> I may hunt down the person with 24 nicks
[21:52] <deryck> 24!  wow.
[21:53] <deryck> they're not domain names
[21:54] <jcsackett> it's possible it's someone registering all the variations of their nicks. e.g. jcsackett, jcsackett-afk, jcsackett|afk, and so on.
[21:54] <sinzui> jcsackett: I think freenode is the secret here. Lp/ubuntu/debian  has a long history with one network. If I am use one of those, I may only need to list that one
[21:54] <jcsackett> still crazy, mind you.
[21:54] <jcsackett> sinzui: that makes sense.
[21:55] <sinzui> jcsackett: Lp has a small issue in that we collection irc nick as a contact address, so listing just the freenode is correct.
[21:55] <sinzui> I do not list the rizon net since that is for manga for example
[21:56] <jcsackett> sinzui: yeah, i have several networks not listed here, b/c they're not contextually needed.
[21:56] <jcsackett> including rizon, come to think of it, though i don't use that one much.
[21:56] <sinzui> jcsackett: deryck: https://launchpad.net/~ionutjula
[21:57] <sinzui> I wish dot plan would make a comeback
[21:58] <jcsackett> wow. it really is mostly separate networks.
[21:58] <sinzui> This looks like a misconception that Lp is a geek dating site
[22:01] <sinzui> I might get this: http://www.redbubble.com/people/zerobriant/art/7186582-omg-they-killed-rory-posters
[22:01] <mwhudson> holy doodoo what happened to all the code imports overnight?
[22:02] <sinzui> jcsackett: I really think we should just drop 'network' from the formatting. just use "pting on irc.freenode.net".
[22:03] <jcsackett> sinzui: that seems reasonable to me. the network is very clearly implied.
[22:03] <jcsackett> and only people who would understand that are going to care about irc nicks as ID anyway.
[22:04] <lifeless> flacoste: hi
[22:04] <lifeless> flacoste: ping me when you are done
[22:04] <lifeless> ?
[22:04] <sinzui> jcsackett: I agree. That is the salient point
[22:04] <lifeless> sinzui: irc nick isn't usable as a trustable address
[22:04] <lifeless> sinzui: we can't validate them
[22:05] <lifeless> sinzui: if this is about the trustable picker subproject
[22:05] <sinzui> lifeless: we know, but users check multiple data points when search for a user
[22:05] <jcsackett> lifeless: it's not remotely the only thing used.
[22:05] <jcsackett> but people search on ircnicks in the picker.
[22:06] <flacoste> lifeless: done
[22:06] <lifeless> jcsackett: sinzui: its not got a UNIQUE on it
[22:06] <lifeless> you might consider searching on it but not showing it. I dunno :)
[22:06] <sinzui> No WAY
[22:06] <sinzui> that is why users thing we are stupid
[22:07] <lifeless> ah, ok
[22:07] <sinzui> We allow you to search for information then not show why it matched
[22:07] <jcsackett> lifeless: part of the reason people don't trust the picker is b/c they search on "sinzui" and get this other guy and don't know why he came up.
[22:07] <lifeless> we could show what matched (irc/name/fulltext/email) without showing that data
[22:08] <lifeless> I don't mean to interfere here :) just riffing
[22:08] <jcsackett> we're at the riffing stage, so this is fine. :-)
[22:08] <jcsackett> well, partially riffing.
[22:09] <sinzui> We have an open bug about IPersonSet.findPerson() not supporting nick. That method has diverged from the vocabulary. I think we should consider unifying them. There will be less code to audit
[22:12] <jcsackett> works for me.
[22:41] <lifeless> flacoste: http://queue.acm.org/detail.cfm?id=1394128
[22:42] <lifeless> 'BASE is diametrically opposed to ACID. Where ACID is pessimistic and forces consistency at the end of every operation, BASE is optimistic and accepts that the database consistency will be in a state of flux.'
[23:45] <sinzui> wgrant: wallyworld_,  I will be 15 minutes late to the stand up meeting
[23:45] <wallyworld_> ok