[00:40] <poolie> huwshimi, hooray for starting somewhere
[00:41] <huwshimi> poolie: Haha.
[00:43] <huwshimi> poolie: For too long I've been paralised by Launchpad not having the infrastructure to do things properly.
[00:44] <huwshimi> poolie: Making the infrastrucuture right has resulted in a trade-off for good UX in Launchpad
[00:44] <huwshimi> poolie: Now I don't care about the infrastructure, I just want the UX to be good
[00:46] <huwshimi> *flame war, GO!*
[00:53] <lifeless> infrastructure for its own sake is waste ;)
[00:57] <lifeless> huwshimi: I totally applaud reasoned cutting-of-gordian-knots, which I think you are doing here.
[00:58] <huwshimi> lifeless: And likewise, I'm all for proper infrastructure
[01:01] <huwshimi> I actually really can't stand doing things poorly. I've just gotten to the point that I'd rather do things poorly than not at all at the moment
[01:03] <lifeless> huwshimi: One thing launchpad has gotten stuck on in the past is defining 'right' - and ended up with bells and whistles we don't need.
[01:03] <lifeless> We also tend to focus too much on doing it all ourselves, IMO
[01:05]  * poolie cheers
[01:06] <poolie> i still like the idea of accumulating even just a set of screenshots of things we think were done right
[01:06] <poolie> by way of a cheap style guide
[01:06] <huwshimi> lifeless: Also as this is the web we should be architecting for change
[01:07] <lifeless> huwshimi: of course! you've seen my slides, right :)
[01:07] <wgrant> Launchpad has never done any sort of, well, design or architecture.
[01:07] <wgrant> Except when it designs things too much and badly.
[01:08] <lifeless> wgrant: you may find yourself stepping on toes if you don't qualify things a little :)
[01:08] <huwshimi> lifeless: Are they slides from Dallas?
[01:08] <huwshimi> or dublin
[01:09] <lifeless> huwshimi: prague and dallas
[01:09] <huwshimi> lifeless: Are they online somewhere, I remember your talk, but don't remember all the details
[01:09] <lifeless> let me get you a link
[01:09] <lifeless> there is one in the wiki under ArchitectureGuide, but also ..
[01:10] <lifeless> https://docs.google.com/present/edit?id=0AR8DGdpwOJuiZGdwZGNmbjlfMTFoY2Nwcm1ocw&authkey=CMiPvu0F
[01:10] <lifeless> and
[01:10] <lifeless> https://docs.google.com/a/canonical.com/present/edit?id=0AR8DGdpwOJuiZGdwZGNmbjlfNGZkNDZmZ2N6&authkey=CJWpj5EN&hl=en_US
[01:10] <lifeless> blargh, if either don't work let me know :)
[01:11] <huwshimi> lifeless: They, work. Just taking a look
[01:16] <poolie> huwshimi, the question came up the other day of: why do the importance labels look like "tags"  or labels
[01:17] <poolie> not sure if you were here for it but i'm curious if you know
[01:18] <huwshimi> poolie: There's no real science behind it. It's a very common design pattern for representing importance or status. Both importance and status were displayed like that in early mockups
[01:27] <poolie> it's ok with me
[01:52] <lifeless> wgrant: sob
[01:53] <lifeless> wgrant: 'TypeError: Could not serialize object set([u'OOPS-ABCDEF1234']) to JSON'.
[01:53] <lifeless> wgrant: is this just cruft - e.g. if I list() it, its good ?
[01:54] <lifeless> [list works]
[01:56] <wgrant> omg optus finally fixed it.
[01:56] <wgrant> lifeless: Yep, listing it should work fine.
[01:58] <StevenK> wgrant: It's only taken them until 1pm
[01:58] <wgrant> It's apparently been broken since 3am or so.
[01:59] <StevenK> So 10 hours of international routing being broken. Epic.
[01:59] <wgrant> Only for most of Europe.
[01:59] <wgrant> Which nobody cares about, I guess.
[02:09] <lifeless> and with that, oops-prune is dead.
[02:15] <lifeless> I need a hero^Wreviewer https://code.launchpad.net/~lifeless/launchpad/bug-888375/+merge/81928.
[02:15] <huwshimi> wallyworld_: Not sure if you saw my last message yesterday about that javascript I was working on. I changed the io events and also fixed things up so they use classes instead of styles for show/hide. Do you want to give that one last look? https://code.launchpad.net/~huwshimi/launchpad/tag-cloud-removal-709009/+merge/81689
[02:16] <wallyworld_> huwshimi: looking now
[02:16] <huwshimi> wallyworld_: Thanks, no hurry
[02:16] <wallyworld_> lifeless: i'll look at your mp too :-)
[02:18] <lifeless> thanks
[02:19] <wallyworld_> huwshimi: looks good. were you going to write or update any yui tests?
[02:19] <huwshimi> wallyworld_: Erm, I didn't look
[02:20] <huwshimi> wallyworld_: I guess I'll need to have a look as I've moved this code around (I didn't write most of it, just fixed it up)
[02:20] <wallyworld_> huwshimi: understood. it's was naughty for it to be approved without any questions about tests :-)
[02:21] <huwshimi> wallyworld_: :)
[02:32] <wallyworld_> lifeless: do we want to make the search interval half closed as is common with date/time based searches?
[02:33] <lifeless> wallyworld_: I don't think we care
[02:33] <wallyworld_> or allow one of the start/end dates to be None, perhaps with a sensible default to disallow too broad an interval
[02:33] <lifeless> I think thats overthinking it
[02:34] <wgrant> SIGH
[02:34] <wgrant> It is broken again.
[02:34] <wallyworld_> i would care because if you want all oops for a particular day, you would normally do 1/1/2009 00:00 <= date < 2/1/2009 00:00 for example
[02:34] <lifeless> our replication strategy alone means the former wouldn't be sufficient and the latter is unneeded - oops will always care about exact end dates as they won't be pruning very new things
[02:35] <wallyworld_> ok
[02:36] <lifeless> wallyworld_: between is fully open
[02:36] <lifeless> wallyworld_: a BETWEEN x AND y
[02:36] <lifeless> ->
[02:36] <lifeless> a >= x AND a <= y
[02:36] <wallyworld_> hmm. i checked the online. the example given was fully closed
[02:36] <lifeless> wallyworld_: so naive use will Just Work anyhow (subject to replication lag etc etc if we ever get the API running on slaves)
[02:36] <wallyworld_> but it could be wrong
[02:36] <lifeless> http://www.postgresql.org/docs/8.4/static/functions-comparison.html
[02:36] <wallyworld_> should there be asserts / ValueError checks to catch None dates being passed in then? also context_params is not checked for None. do we care?
[02:37] <lifeless> 'addition to the comparison operators, the special BETWEEN construct is available:
[02:37] <lifeless> a BETWEEN x AND y
[02:37] <lifeless> is equivalent to
[02:37] <lifeless> a >= x AND a <= y
[02:37] <lifeless> '
[02:37] <lifeless> context_params is internal code only
[02:37] <lifeless> date ranges are the only thing clients are permitted to influence
[02:37] <lifeless> if they pass none in, it will do date between NULL AND <other>
[02:38] <wallyworld_> internal code can still be buggy :-) but fair enough
[02:38] <lifeless> which will match nothing (as null operator foo -> false)
[02:38] <lifeless> wallyworld_: it can be, which is why there are two ws tests that test the product and distribution glue is correct
[02:39] <wallyworld_> ok. thanks for clarifying :-)
[02:39] <lifeless> wallyworld_: I will teak the interface docstring
[02:39] <lifeless> wallyworld_: to avoid folk getting confused and thinking its like a slice vis-a-vis None
[02:39] <wallyworld_> cool. that would be good, since what's there is open to assumptions :-)
[02:54] <wallyworld_> lifeless: i can't see the replacement pruning functionality. there's apis to search for oopses but the pruning capability has been deleted ans there's no replacement in this mp?
[02:55] <lifeless> thats right
[02:55] <lifeless> its no longer a launchpad concern
[02:56] <lifeless> it should never have been part of the LP tree anyway :)
[02:56] <wallyworld_> sure. just checking that we weren't losing expected functionality
[02:56] <wallyworld_> s/expected/required
[02:56] <lifeless> oh we are
[02:56] <lifeless> just it won't be coming back to the LP tree
[02:56] <lifeless> separate project now
[02:57] <wallyworld_> and it's ready to go? or will we go without pruning for a bit?
[02:57] <lifeless> python-oops-datedir-repo
[02:57] <lifeless> its about an hours work
[02:57] <lifeless> :)
[02:57] <wallyworld_> ok
[02:57] <wallyworld_> famous last words :-)
[02:57] <lifeless> getting it deployed will take longer
[02:58] <wallyworld_> so we can afford not having oops pruning for X interval till it gets done i guess
[02:58] <lifeless> yes
[02:59] <lifeless> carob suffers before the appservers do
[02:59] <huwshimi> Does a + in one of our urls signify a static path (as opposed to dynamic data e.g. launchpad.net/dynamic/+static/)? Do all our URLs follow this pattern?
[02:59] <lifeless> and right now, for staging oopses, it has no pruning, because this APi isn't here, but they are using the amqp oops path
[02:59] <wallyworld_> thanks. i'm quite ignorant of our deployment requirements, so just wanted to check :-)
[02:59] <lifeless> huwshimi: the + indicates a view of an object
[03:00] <huwshimi> lifeless: Oh
[03:00] <lifeless> huwshimi: so /~person/+index is the actual url for /~person
[03:00] <lifeless> huwshimi: its a bit bong
[03:00] <lifeless> huwshimi: it has a few reasons behind it, but it gets in the way too
[03:01] <huwshimi> lifeless: So in a hypothetical world where we would map bugs.launchpad.net to a new URL would it be launchpad.net/launchpad/bugs or launchpad.net/launchpad/+bugs?
[03:01] <lifeless> huwshimi: there are plenty of options
[03:02] <lifeless> huwshimi: bugs.l.n has a distinct view from code.l.n, but you could do launchpad.net/+bugs-index and launchpad.net/+code-index
[03:02] <lifeless> for instance
[03:03] <huwshimi> lifeless: OK thanks, it's not a problem now, I was just trying to understand how the +s work
[03:03] <lifeless> de nada
[03:08] <wgrant> huwshimi: + is mostly used to disambiguate system- and user-controlled path segments. Since it's not permitted as the first character of a Launchpad name, we can support paths like /PROJECT/SERIES and /PROJECT/+bug/BUG without conflicts. It's also used in view names (eg. +bugs, +index), for similar reasons.
[03:09] <wgrant> So yes, basically what you said.
[03:09] <wgrant> There are some old paths where that doesn't hold true.
[03:09] <wgrant> eg. /bugs/BUG
[03:09] <wgrant> But it applies to most places.
[03:09] <huwshimi> wgrant: Great, good to know.
[03:11] <lifeless>  /bugs/BUG was deliberate
[03:11] <lifeless> we don't need to use it for new stuff, though it is a safe default
[03:15] <huwshimi> lifeless: I imagine if we did map our subdomains then bugs.launchpad.net/ would become launchpad.net/bugs/ so /bugs/BUG would make even more sense
[03:15] <lifeless> huwshimi: if we consolidate, I'd really love to see the namespace not deepend
[03:16] <lifeless> huwshimi: would launchpad.net/$project -> homepage; click on bugs there, be ok ? I think google code basically do this..
[03:16] <lifeless> huwshimi: or perhaps make 'bugs' subordinate to the project context :)
[03:19] <huwshimi> lifeless: Sorry, I'm not quite sure what you mean?
[03:19] <huwshimi> lifeless: I would imagine you would have something like launchpad.net/launchpad/+bugs, launchpad.net/launchpad/+translations etc.
[03:20] <huwshimi> lifeless: I was saying launchpad.net/bugs/ would become a homepage for bugs like bugs.launchpad.net is now (if we decided we still wanted it)
[03:20] <huwshimi> lifeless: Is that what you were asking?
[03:20] <wgrant> That's how it was originally, actually.
[03:20] <wgrant> until 2006ish.
[03:21] <huwshimi> wgrant: April, 2006
[03:22] <wgrant> huwshimi: How'd you work that out?
[03:23] <huwshimi> wgrant: http://www.markshuttleworth.com/archives/30
[03:23] <wgrant> A-ha.
[03:24] <nigelb> What happened to Applications on subdomains? :)
[03:25] <wgrant> nigelb: That's what we have now.
[03:25] <lifeless> huwshimi: I thought you meant e.g. bugs.l.n/launchpad/+bugs?field.. -> l.n/bugs/launchpad/+bugs?field..
[03:25] <wgrant> And have had for several years.
[03:25] <lifeless> huwshimi: which I think would be ugly
[03:25] <nigelb> wgrant: Ah. Launchpad applications. Right.
[03:25] <nigelb> I confused that with projects.
[03:25] <huwshimi> lifeless: Oh, yeah, not at all. Let's make the project the base and tack the app url on after that somehow
[03:26] <lifeless> huwshimi: I think that makes a lot of sense
[03:26] <huwshimi> lifeless: :D
[03:31] <huwshimi> wgrant: It's funny, there's a few things I think we got right a few years ago that I would like to revert to :)
[03:31] <wgrant> huwshimi: Yeah...
[03:32] <lifeless> wgrant: can you check I transcribed your fix for bug 884265 correctly ?
[03:32] <_mup_> Bug #884265: req_vars header values may cause crash in dboopsloader <python-oops-tools:Triaged> < https://launchpad.net/bugs/884265 >
[03:32] <mwhudson> let's all go back to arch!
[03:32] <wgrant> mwhudson: A sound plan.
[03:32] <lifeless> wgrant: and if so, approve my MP ?
[03:33] <wgrant> lifeless: Your MP being rye's?
[03:34] <lifeless> no
[03:34] <lifeless> t'other one
[03:34] <wgrant> Ah.
[03:34] <wgrant> Which was created after I last looked.
[03:35] <wgrant> approvated
[04:09] <poolie> huwshimi, "a normal ux"
[04:09] <poolie> awesome
[04:09] <poolie> i think even google seems to be going away from having separate subdomains?
[04:10] <lifeless> can has review? https://code.launchpad.net/~lifeless/python-oops-tools/bug-888866/+merge/81933
[04:10] <poolie> it's hard to tell
[04:10] <poolie> but the calendar is now google.com/calendary
[04:12] <nigelb> huwshimi: I like this going back to no subdomains thing ;)
[04:12] <poolie> me too
[04:12] <wgrant> It's also pretty damn easy to move away from subdomains.
[04:12] <poolie> i would like to see a mockup of what the navigation ought to look like
[04:12] <wgrant> We've had so many different navigation UIs over the years.
[04:12] <wgrant> None of them have worked :/
[04:12] <poolie> huwshimi, one interesting thing from gdd was their stuff about breadcrumby/back-stack navigation in android
[04:12] <wgrant> And now GitHub has basically reproduced LP 2.0
[04:12] <poolie> it does not map totally directly
[04:13] <poolie> but there are some ideas
[04:13] <poolie> is that good or bad?
[04:13] <poolie> specifically they have a plain 'back', crossing application or other activity boundaries
[04:13] <poolie> and also an 'up'
[04:13] <nigelb> wgrant: heh, yeah.
[04:13] <poolie> taking you towards the top level of that particular application
[04:14] <poolie> obviously for us its complex because there is browser back, and also going back towards the lp app root vs the pillar root
[04:14] <poolie> but, perhaps we want to emphasize the latter
[04:50] <lifeless> can has review ? https://code.launchpad.net/~lifeless/python-oops-datedir-repo/bug-888866/+merge/81937
[04:51] <lifeless> well, EOD for me.
[04:52] <lifeless> EOW even
[05:20] <poolie> cheerio lifeless
[05:20] <poolie> wgrant, ok, the package style is a bit more modern now
[05:23] <StevenK> Does it make use of dh 7 yet?
[05:41] <wgrant> hardy doesn't have dh7, but cat should if you want it.
[05:43] <StevenK> Oh, drat. Hardy
[06:25] <micahg> hardy-backports has dh7 :)
[06:33] <poolie> it doesn't
[06:33] <poolie> that doesn't seem high on the list of issues
[06:35] <poolie> should i add this to just launchpad-dependencies, or something more specific?
[06:35] <poolie> which one is used to run tests i wonder
[06:37] <poolie> developer dependencies apparently
[06:38] <huwshimi> Have a good weekend all!
[06:38] <poolie> you too
[06:42] <wgrant> poolie: launchpad-developer-dependencies, probably.
[06:43] <poolie> yep, done and pushed
[06:50] <poolie> do i _have_ to update the ec2 image for new dependencies?
[06:51] <wgrant> Yes.
[06:51] <poolie> can't it just install them when it boots?
[06:51] <wgrant> It doesn't apt-get upgrade
[06:51] <StevenK> No
[06:51] <poolie> could it?
[07:03] <poolie> so, to me it really does look like it does an apt-get upgrade
[07:03] <poolie> but that may be a decoy
[07:46] <StevenK> poolie: The only case that does is the AMI upgrade path
[07:47] <poolie> yeah, but istm i can, and might as well, just do it when a real test is booting
[07:47] <StevenK> I don't like that idea.
[07:47] <StevenK> Some tests on ec2 are fragile enough without adding more changes.
[07:48] <poolie> mm
[07:48] <poolie> but this is fairly determinisitic
[07:48] <poolie> and brings the tests closer to what people will experience elsewhere
[07:49] <StevenK> We have been on rev 522 for over one month
[07:50] <StevenK> And given it takes about an hour to make a new AMI, I don't think the cost is high at all.
[07:50] <poolie> !!
[07:51] <poolie> i think an hour of avoidable works' pretty high
[07:51] <StevenK> It isn't an hour of work. It's one command and wait an hour
[07:51] <StevenK> Much like our test suite
[07:51] <poolie> that's worth cutting down too
[07:51] <poolie> an hour of latency is also worth cutting out
[07:52] <StevenK> I would seriously prefer you just make a new AMI and bring up changing it on the mailing list.
[07:52] <poolie> i am running my test in this now
[07:52] <poolie> which seems equivalent
[07:53] <StevenK> And I submit that changing it and then announcing it is as much akin to what you almost accussed me of with +personal.
[07:53] <poolie> oh
[07:53] <poolie> i'm just going to put up an mp
[07:53] <poolie> i'm not going to just change the ami
[07:54] <poolie> in fact i'm pretty sure i am not trusted to change the ami, which is another reason i looked at just updating the single machine
[07:54] <poolie> and i did ask about it here
[07:55] <StevenK> poolie: Have a look at lib/devscripts/ec2test/account.py, line 25 on.
[07:56] <poolie> as i suspected, it's out of date :)
[07:56] <poolie> wrt henninge
[07:56] <StevenK> We don't remove people
[07:57] <StevenK> And I suspect adding your ID there would not cause much of an issue
[07:57] <poolie> yeah i could
[07:57] <StevenK> We can probably remove henning, salgado, jml
[08:00] <poolie> i think current staff who are no longer on the lp team is a bit different
[08:00] <poolie> but, maybe still least privilege
[08:44] <jml> actually, that reminds me, I need to delete my LP image
[08:44] <jml> it's costing me US$0.53 and £2 each month in Amazon & then bank fees.
[08:55] <StevenK> 2GBP is a bit steep
[09:14] <mrevell> Hello
[09:18] <danhg> Morning Everyone
[09:20] <adeuring> good morning
[11:17] <jam1> I thought the new fast-oops was deployed. I got an OOPS trying to list my branches in a project page, but the oops (with a hash) hasn't shown up after about 10 min
[11:17] <jam> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-55ae33da0714197906011068d73e95f3 if people care
[11:17] <rvba> jam: fast-oops is not yet deployed in production.
[11:19] <jam> ah, I thought robert said that it will show up once we switch to hash-based ids
[11:19] <jam> anyway, https://bugs.launchpad.net/launchpad/+bug/889042
[11:19] <_mup_> Bug #889042: OOPS while viewing branch listing for ~user/project <Launchpad itself:Triaged> < https://launchpad.net/bugs/889042 >
[11:20] <jam> browsing to a per-user branch listing tracebacks
[11:22] <rvba> jam, hum, that's related to the new branch menu recently introduced, I think it's worth disabling the flag until the problem that you just had is solved… I'll take care of that…
[11:25] <jam> rvba: thanks. code.lpn/~jameinel works but code.lpn/~jameinel/project doesn't
[11:33]  * nigelb wonders what mrevell was testing
[11:36] <mrevell> nigelb, hmm?
[11:36] <mrevell> nigelb, Oh, the mailing list archive seems to be delayed by a couple of days
[11:36] <nigelb> ah, nice :)
[11:37] <nigelb> I did ask wgrant about it some days ago.
[11:37] <nigelb> err weeks
[11:37] <nigelb> Back then it was hours, not days.
[11:46] <rvba> jam: the flag has been removed so this should be back to normal, thanks for reporting this.
[11:47] <jam> rvba: confirmed, my ~user/project page loads now
[12:49] <deryck> Morning, all.
[12:53] <rick_h> morning
[14:26] <rvba> Hi adeuring, would you have time to have a look at this MP? https://code.launchpad.net/~rvb/launchpad/bug-889042/+merge/81988
[14:26] <adeuring> rvba: sure
[14:27] <flacoste> mrevell, sinzui, gnuoy, allenap: i realy doubt that the delays in mail being sent out is related to the delays in mail archiving
[14:27] <rvba> adeuring: thank you. The diff should be available shortly…
[14:27] <flacoste> mailman is using separate queue runner for all these aspects
[14:28] <sinzui> flacoste, as wgrant remarked, there is a lot of list traffic in ubuntu-x-swat maybe
[14:28] <flacoste> that's a more likely explanation
[14:29] <flacoste> in the past we had issues with the xmlrpc calls timing out, but that was fixed i think
[14:29] <flacoste> is mailman the bottleneck or our stmp server?
[14:29] <flacoste> also, mrevell tests seem to have been near instantaneous
[14:29] <gnuoy> flacoste there is no backlog in exim
[14:29] <flacoste> is there a backlog in mailman?
[14:30] <mrevell> Daviey, Is there still a backlog for the openstack list?
[14:30] <mrevell> Daviey, I mean delay
[14:33] <deryck> adeuring, https://dev.launchpad.net/QA/ExploratoryTesting/CustomBugListings
[14:33] <deryck> abentley, https://dev.launchpad.net/QA/ExploratoryTesting/CustomBugListings
[14:35] <Daviey> mrevell: The archive doesn't seem to be showing recent mail, https://lists.launchpad.net/openstack/
[14:35] <Daviey> regarding actual mail, i'm not sure.
[14:42] <sinzui> Why are there always 3 new bugs? I have checked for private new bugs that we might be be subscribed too, but there are none in production
[14:42] <flacoste> Daviey: right, mailing list archives isn't expected to work, a work around is to visit mail-archives.org
[14:42] <flacoste> all your lists are archived there in real-time
[14:46] <Daviey> flacoste: for the nosey, why is that?
[14:47] <flacoste> actually, it's mail-archive.com
[14:47] <sinzui> excellent, staging is broken in the same way.
[14:48] <flacoste> Daviey: because originally we didn't want to host archives ourself, because there is no good software for it
[14:48] <Daviey> ah
[14:48] <flacoste> down the line we decided to do a dirt-cheap solution
[14:48] <flacoste> but that's what we have now
[14:48] <flacoste> dirt-cheap
[14:48] <flacoste> that doesn't work most of the time
[14:48] <deryck> Seems odd to me we have the same yuixhr failure in both devel and db-devel.
[14:49]  * deryck is investigating build failures
[14:49] <Daviey> flacoste: thanks
[15:05] <adeuring> rvba: r=me
[15:06] <rvba> thank you adeuring.
[15:16] <gnuoy> flacoste, there doesn't seem to be a  backlog in mailman
[15:17] <flacoste> gnuoy: ok, so we think the delay problem is solved?
[15:17] <gnuoy> flacoste, no, sorry, I was just answering your question from an hour ago
[15:18] <flacoste> well, if we don't have a queue, there shouldn't be delays :-)
[15:18] <gnuoy> unless the thing putting them on the queue it the problem
[15:18] <gnuoy> s/it/is/
[15:55] <deryck> abentley, lines are up again if you need to land stuff.
[15:55] <abentley> deryck: Cool, thanks.
[16:00] <deryck> matsubara, we using mumble for the call?  or skype?
[16:00] <matsubara> deryck, skype so danhg can join us
[16:01] <deryck> ok
[16:02] <abentley> matsubara: online now, as aaron_bentley
[16:03] <deryck> matsubara, I'm ready to go too.
[16:03] <deryck> adeuring, you want in this call?
[16:03] <matsubara> abentley, thanks. skype is taking forever to find your user id
[16:04] <adeuring> deryck: sure. skype?
[16:04] <deryck> adeuring, yup.  and tell matsubara your skype id if he doesn't have it.
[16:04] <matsubara> deryck, can you host? I suppose you have aaron and abel already in your list?
[16:04] <deryck> matsubara, sure.
[16:04] <matsubara> do you see me online?
[16:05] <adeuring> matsubara: adeuring on skype. give me two minutes to śtart a machine where skype is installed
[16:14] <flacoste> deryck: with spurious test failures, don't cross fingers, disable tests :-)
[16:38] <allenap> gmb: Do you what's happening/happened with bug relationships?
[16:39] <gmb> allenap: Not since I handed in the draft of the LEP. mrevell and flacoste will likely know where it's at.
[16:40] <flacoste> allenap: your squad is likely to work on it
[16:40] <flacoste> allenap: once gary squad is done with test suite parallelizatin
[16:40] <allenap> flacoste: So something for 2012 then. Ta.
[16:40] <flacoste> allenap: it's not clear what the exact scope will be yet
[16:40] <flacoste> allenap: yep
[16:40] <flacoste> early 2012 is what is on our agenda
[16:45] <deryck> flacoste, sorry was otp.  I wasn't confident it was spurious enough to disable.  if it happens again, I will.
[17:15] <allenap> Does anyone know why I can't find more than 1207 bugs at https://bugs.qastaging.launchpad.net/ares (via advanced search), even though I know that there are 1515 bugs, and launchpadlib confirms it? I assume it's something to do with bugs/bugtasks, yet they are all newly created tasks from an import.
[17:16] <deryck> allenap, private bugs?
[17:16] <allenap> deryck: There's one private bug. Checking anonymously via launchpadlib yield 1514 bug tasks.
[17:17] <deryck> hmm, weird.  I remember something like that with a bug import for me.  either private bugs or closed bugs.
[17:17] <allenap> deryck: I sense that I've figured this one out before, but I cannot quite access the memory.
[17:17] <deryck> heh, yeah
[17:18] <deryck> allenap, do you know what the user sees?
[17:19] <deryck> allenap, also, expired maybe?
[17:19]  * deryck is guessing :)
[17:19] <allenap> deryck: The user and I see the same things: just 1207 bugs (well, he sees 1206). Ah, I have an inking...
[17:20] <allenap> deryck: I've figured it out! There are 308 tasks with Unknown status, and that's not given as an option in the advanced search page.
[17:20] <deryck> allenap, ah ha! :)
[17:21] <allenap> deryck: Thanks for prodding in the right direction :)
[17:21] <deryck> allenap, np!
[18:06] <lifeless> allenap: evening
[18:11] <rvba> Hi lifeless!
[18:11] <lifeless> hi rvba
[18:11] <lifeless> sad news about the oopses!
[18:12] <rvba> yeah, but that's fixed, the branch is in ec2.
[18:22] <lifeless> cool
[18:37] <sinzui> lifeless,  do you know if the process that manages BugSummary ever pruges/rebuilds the stats? I am trying to understand why /launchpad always has three new bugs that the db says is not true
[18:39]  * rvba EODs
[18:42] <rvba> lifeless: I've got a perf related question on this MP, maybe you could have a look next week… https://code.launchpad.net/~rvb/launchpad/builders-timeout-bug-887078-eager-load/+merge/82008
[18:42]  * rvba really EODs now.
[18:58] <lifeless> sinzui: it doesn't no. There is obviously a bug.
[18:58] <sinzui> yes. I think one something odd gets into the data, it is stuck
[18:59] <sinzui> lifeless, http://pastebin.ubuntu.com/735551/ show one of the bugs has a patch. I have been looking for such a bug in Lp. They are pretty rare.
[19:00] <lifeless> sinzui: could you file a bug ?
[19:00] <lifeless> I meant to last time I noticed, but I got distracted
[19:00] <sinzui> lifeless, I will
[19:23]  * micahg hugs sinzui for cleaning up null bug tasks
[19:24] <sinzui> thank you.
[21:16] <deryck> rick_h, ping.  you around?
[21:36] <deryck> abentley, would you like to review my integration branch, which gets toggling of fields working?
[21:36] <abentley> deryck: sure.
[21:37] <deryck> abentley, thanks!  https://code.launchpad.net/~deryck/launchpad/listing-config-widget-integration/+merge/82024
[21:37] <deryck> abentley, I also did a little drive by to clean up some of that CSS/design stuff we've been discussing.
[21:37] <abentley> deryck: ah, okay.
[21:38] <deryck> abentley, when we're nearly done, I'll do a pass to consolidate/polish CSS rules, and perhaps simplify.  But that should be closer to the mockup, and let everyone see we can get it right.
[21:41] <abentley> deryck: It looks like you're specifying field visibility rather than using the values from LP.cache.  Is that right?
[21:42] <deryck> abentley, yes, I'm getting the value from when the form overlay is submitted.
[21:43] <abentley> deryck: I mean BugListingConfigUtil.field_visibility_defaults
[21:43] <deryck> abentley, ah, yes.  I hard coded them in the widget.  so it echos the browser code.
[21:44] <abentley> deryck: What is the purpose of echoing the browser code instead of using the values generated by the browser code?
[21:46] <deryck> abentley, to me it seemed better because the widget can work in isolation of the cache.  or rather, I did build it separate from the cache....
[21:47] <deryck> abentley, so there's no harm in pulling from cache in a later pass and not leaning on the hard coded defaults.
[21:49] <abentley> deryck: I think this is a DRY violation.  If we change only one, then the bug listings (client-side or server-side) and the widget will disagree about which fields are displayed.
[21:50] <deryck> abentley, I agree.  Does it matter for the sake of this branch, though?  Can I change that when I fix the persistence issue?
[21:50] <abentley> deryck: And consider that the browser code will probably start setting these values according to query variables, per the LEP's URL requirements.
[21:50] <deryck> right
[21:52] <deryck> abentley, I'm completely agreed with you.  Just wondering if fixing is a subsequent branch is ok.
[21:52] <abentley> deryck: I guess you could, but I don't understand why you'd want to.  Violating DRY takes more effort then following it.
[21:53] <deryck> abentley, because, it's a larger change, and I want to think about how best to do it.  Assuming you don't have other issues, this could land now, and at least get the interaction live for people to see.
[21:54] <abentley> deryck: It's not just a one-line variable assignment?
[21:55] <deryck> abentley, ah, you mean just in the page hook up?  I was thinking refactoring so the hard coded ones weren't there at all.  fixing tests, etc.
[21:56] <abentley> deryck: Oh, I see.
[21:57] <abentley> deryck: Well, if the tests are holding it back, I guess that's okay then.  I just didn't understand your reluctance.
[21:58] <deryck> abentley, ok, thanks.  I would like to fix it altogether, so the widget can't work without getting data from the cache.
[21:58] <abentley> Right.  And then you could have a factory function for testing.
[21:58] <deryck> it's pedantic I guess, but it makes more sense to me if the test describes what you should do with the widget.
[21:58] <deryck> abentley, right
[21:59] <deryck> I meant my reluctance is pedantic, not your suggestion, abentley :)
[22:03] <abentley> deryck: r=me.
[22:04] <deryck> abentley, thanks!
[22:04] <rick_h> deryck: pong, been afk most of the day
[22:05] <abentley> deryck: We should also look at the module naming.  I see "lp.bugs.buglisting" and "lp.buglisting_utils" and they don't match.  And I'm not sure whether ListingNavigator shouldn't also be a utility.
[22:07] <deryck> abentley, yeah, I agree.  I'm not crazy about my namings of this and configutils.BaseConfigUtil.
[22:07] <abentley> I'm not entirely sure what the style is supposed to be.  I've seen a lot of different things.
[22:18] <deryck> we're inconsistent indeed.  I think everything should just live under lp, a la Y.lp.module.
[22:18] <deryck> and probably a listings module and a utilities modules would let us divide these pieces up nicely.
[22:19] <deryck> abentley, can you mark the mp approved too please?
[22:46] <deryck> Later on, everyone.  Have a nice weekend.