[00:06]  * thumper still writing tests
[00:22] <lifeless> grr bug heat updates
[00:23] <lifeless> wgrant: ID OOPS-1901QS5
[00:24] <thumper> lifeless: you'd like my current tests
[00:24] <lifeless> thumper: I will?
[00:24] <thumper> lifeless: they all have self.assertThat(recorder, HasQueryCount(Equals(0)))
[00:34] <wgrant> with NoStormStatements:
[00:36] <wgrant> lifeless: How? I changed the target of the original bug to a different project, and it sent me to the bug page as expected...
[00:36] <wgrant> Using both +editstatus and the inline form of deprecation.
[00:42] <lifeless> wgrant: I think I hit a redeploy
[00:46] <wgrant> lifeless: How would that change things?
[00:46] <lifeless> wgrant: transaction committed, appserver killed, refresh - boom
[00:47] <wgrant> Mmm, I guess.
[00:47] <lifeless> wgrant: have you seen https://devpad.canonical.com/~lpqateam/ppr/lpnet/2011-03/daily_2011-03-13_2011-03-14/categories.html - lots of requests :)
[00:47] <wgrant> Anyway, once my branch lands it will just redirect instead.
[00:47] <wgrant> Of course it conflicted with leonard's...
[00:47] <lifeless> wgrant: even on post ?
[00:47] <wgrant> lifeless: HTTP is just that awesome.
[00:48] <wgrant> We already do it in some circumstances :/
[00:48] <lifeless> wgrant: sarcasm doth not befit thee
[00:48] <wgrant> lifeless: That's daily?
[00:49] <StevenK> lifeless: Is "sarcasm doth not befit thee" or did you make it up?
[00:49] <wgrant> lifeless: Do we have a graph of 99% time over time?
[00:49] <StevenK> Sigh. Is it a quote
[00:50] <StevenK> mwhudson: Hi!
[00:53] <lifeless> wgrant: thats one day, yes
[00:55] <lifeless> wgrant: https://lpstats.canonical.com/graphs/PPR/
[00:55] <wgrant> lifeless: The translations graph is nice.
[00:55] <wgrant> And should be even nicer tomorrow, I suppose.
[00:56] <lifeless> wgrant: because of the drop ?
[00:56] <lifeless> POFile:+translate was at 9.7seconds 99th percentile
[00:56] <wgrant> lifeless: Right.
[00:56] <lifeless> hopefully it will be better now ;)
[00:56] <lifeless> but todays ppr failed to generate
[00:57] <wgrant> lifeless: +translate seems to mostly complete in under 2 seconds. Nicely done.
[00:58] <lifeless> wgrant: I think so
[00:58] <lifeless> pure fluke that I bothered to try a with plan
[00:58] <lifeless> there may be a fat index impeding regular queries; not sure
[01:02] <lifeless> I want https://lpstats.canonical.com/graphs/PPR/ to be on a log scale
[01:03] <wgrant> Indeed, most of our graphs should be.
[01:04] <lifeless> spm: can tuolumne do that ?
[01:05] <spm> log scale? not that I'm aware of.
[01:07] <wgrant> Looks like pycairochart might not support it.
[01:07] <mwhudson> StevenK: hello?
[01:09] <StevenK> mwhudson: I was talking to Julian yesterday about DSDs, and he was mentioning that we might want to delete DSDs -- which would remove comments associated with the DSD. Would you prefer the DSD hung around to preserve them?
[01:10] <wgrant> Under what circumstances would you remove DSDs?
[01:10] <StevenK> That is what I'm not certain about, but Julian seems to think the DSDJ runner needs to do it.
[01:10] <mwhudson> StevenK: dsd?
[01:10] <StevenK> mwhudson: DistroSeriesDifference
[01:10] <wgrant> I don't think removing them before a series is finished would be a good idea...
[01:11] <mwhudson> StevenK: you are asking me because i have linaro in my cloak i presume?
[01:11] <StevenK> mwhudson: And you're in my TZ. :-)
[01:11] <lifeless> mwhudson: we hear you are slightly technical
[01:12] <mwhudson> i'm not sure i'm the right person to ask about this though sadly
[01:13] <mwhudson> StevenK: i think i plead EINSUFFICIENTCONTEXT
[01:13] <mwhudson> StevenK: maybe get julian to talk to james_w ?
[01:14] <mwhudson> StevenK: or you can try to explain a bit more context i guess
[01:14] <StevenK> Or I can in my morning
[01:14] <mwhudson> like, as wgrant says, "when would you remove them" ?
[01:15] <wgrant> They need to be kept even between series if the difference persists.
[01:15] <StevenK> Like I say, I'm unclear on why Julian wants to do that, and I want to get the simple cases working for the DSDJ runner before I bother diving into the harder stuff.
[01:17] <mwhudson> StevenK: i suggest we acquire some more clarity before discussing further then :)
[01:17]  * wgrant declares war on Makefile.
[01:17] <StevenK> mwhudson: Do you know where to find some? :-P
[01:17] <mwhudson> StevenK: well, find out why julian wants to delete them?
[01:18] <lifeless> data that is no longer interesting shouldn't be kept around in our primary tables
[01:18]  * StevenK teaches mwhudson about "humour"
[01:18] <lifeless> mwhudson: ^ I suspect he's thinking about what is/isn't interesting
[01:18] <mwhudson> StevenK: heh
[01:19] <StevenK> mwhudson: Something you might be able to help with -- I'm writing a run() method for a IRunableJob and I'd like to get at the log, so I can add messages to it, is that easy?
[01:20] <mwhudson> StevenK: isn't there a self.logger or something?
[01:20] <wgrant> I have never worked out how to get the log from outside a RunableJob, either.
[01:20] <wgrant> That would be really handy.
[01:20] <mwhudson> maybe i'm not thinking of the right object
[01:20] <mwhudson> maybe there just should be :-)
[01:22] <mwhudson> sigh, a coherent logging strategy would be nice
[01:22] <StevenK> ... yes
[01:22] <lifeless> a good logging framework would be too
[01:22] <StevenK> thumper helped that by binning about 15 loggers from the tree
[01:22] <poolie> hi all
[01:23] <wgrant> Hi poolie.
[01:23] <mwhudson> logging is one of those things that seems easy, but i've never seen it done satisfactorily
[01:24] <StevenK> It doesn't matter how much it logs, you always want it to log more.
[01:24] <StevenK> (or less, if it never breaks)
[01:24] <mwhudson> well
[01:24] <thumper> StevenK, wgrant: is a SourcePackage object _ever_ created without a distroseries?
[01:24] <mwhudson> jml added some overenthusiastic logging to the sftp server once
[01:25] <mwhudson> when the log got to 8 gigs within a day or something, that was decided to be "a bit too much"
[01:25] <StevenK> Haha
[01:25] <thumper> StevenK, wgrant: see lp.bugs.model.bug line 1135
[01:25] <thumper> ish
[01:26] <lifeless> thumper: SourcePackage should be called DistroSeriesSourcePackage
[01:26] <thumper> lifeless: I realise that
[01:26] <lifeless> thumper: there is a DistributionSourcePackage, which shouldn't exist
[01:26] <lifeless> and a missing table which should exist
[01:26] <thumper> lifeless: but I've found some weird code in bugs
[01:26] <thumper> lifeless: it assumes that distroseries may be None in SourcePackage
[01:27] <thumper> I didn't think it could be
[01:27] <lifeless> in ISourcePackage, not SourcePackage
[01:27] <lifeless> one sec
[01:28] <wgrant> thumper: I think you're right.
[01:28] <thumper> required = True
[01:28] <thumper> in which case, I'll simplify the bug code
[01:28] <wgrant> thumper: But our sample data and/or tests are probably fucked.
[01:28] <wgrant> Remove it and see what breaks, then fix it.
[01:28]  * thumper nods
[01:29] <lifeless> thumper: ok, that looks bogus
[01:29] <thumper> lifeless: I've simplified the bug code
[01:29] <thumper> lifeless: as part of my work
[01:30] <thumper> what I don't understand
[01:30] <thumper> is the requirements of certain tasks
[01:30] <thumper> like...
[01:30] <thumper> what is needed for a source package task to exist?
[01:30] <thumper> a distroseries task
[01:30] <thumper> or a distro source package task
[01:30] <thumper> or either
[01:30] <thumper> or both
[01:30] <thumper> there seems to be implicit rules
[01:30] <wgrant> A SourcePackage task has a DistroSeries and a SourcePackageName.
[01:30] <thumper> not enforced by the model code
[01:30] <wgrant> A DistributionSourcePackage task has a Distribution and a SourcePackageName.
[01:31] <wgrant> See determine_target
[01:31] <thumper> wgrant: yes... I understand that
[01:31] <thumper> wgrant: there are implicit expectations of certain tasks though
[01:31] <wgrant> thumper: Ah, with regard to conjoinment?
[01:31] <thumper> you can't have a distroseries task without a distro task
[01:31] <wgrant> Right.
[01:31] <wgrant> Well, you can, but you're not meant to.
[01:31] <thumper> wgrant: well, exactly
[01:31] <wgrant> eg. bug #43150 will make you cry.
[01:31] <_mup_> Bug #43150: [SRU] maxima frontends fail to connect <wxmaxima (Ubuntu):Fix Released> <gcl (Ubuntu Dapper):Fix Released by wgrant> <maxima (Ubuntu Dapper):Fix Released> < https://launchpad.net/bugs/43150 >
[01:31] <thumper> the database nor model doesn't enforce it
[01:32] <lifeless> thumper: \d bugtask
[01:32] <lifeless> thumper: see the checl constraints
[01:32] <wgrant> The current series task model only came about in late 2006, early 2007.
[01:32] <wgrant> So there are old bugs (like 43150) that have invalid things.
[01:32] <thumper> lifeless: we don't have check constraints of other rows
[01:32] <lifeless> indeed
[01:32] <lifeless> I'd like to delete the conjoined concept
[01:33] <lifeless> I see no benefit in cross-row rules
[01:33] <lifeless> better to have a more powerful concept of 'target' and fix our seach
[01:33] <lifeless> *search*
[01:34] <lifeless> wgrant: wow, the rendering of that bug is --broken--
[01:34] <lifeless> OTOH, 2.38 seconds
[01:34] <thumper> I still don't understand the conjoined thing
[01:34] <lifeless> kinda slow
[01:35] <wgrant> lifeless: What's broken?
[01:35] <lifeless> wgrant: no package name shown for the first two tasks
[01:35] <wgrant> (I use that bug a lot, since it has lots of subscribers, lots of strucsubs, a few dupes, a few tasks, some series tasks, and various bits of activity)
[01:35] <wgrant> lifeless: Right.
[01:36] <wgrant> lifeless: There is no DSP task for them.
[01:36] <wgrant> lifeless: Because they predate the new release management stuff.
[01:36] <wgrant> Well, "new" meaning "4 years ago"
[01:38] <wgrant> We need to discuss it with Ubuntu (to convince them to use milestones instead), but I think we can probably fairly sensibly just remove conjoinment.
[01:42] <wgrant> Is there a function around to mash a string into valid_name?
[01:43] <thumper> not that I know of
[01:44] <wgrant> Ah, sanitize_name.
[01:46] <lifeless> wgrant: well, they don't have the conjoined layout
[01:46] <lifeless> wgrant: but we could render them nicely regardless
[01:46] <wgrant> lifeless: They are not meant to exist, so rendering them nicely probably isn't desired.
[01:46] <wgrant> But I filed a bug on this a long time ago.
[01:47] <lifeless> wgrant: I think we're either completely agreeing, or talking past each other
[01:47] <thumper> someone should write a script to add the missing bugtasks
[01:47] <lifeless> wgrant: my point is that conjoined masters don't express anything that single bugtasks can't
[01:47] <wgrant> Right.
[01:47] <lifeless> wgrant: there is a /behaviour/ change needed when the default series is altered
[01:48] <lifeless> possibly
[01:48] <lifeless> anyhow - milestones are orthogonal I think
[01:48] <lifeless> thumper: or we could just simplify things and get rid of the redundant data
[01:48] <wgrant> lifeless: They're not orthogonal.
[01:48] <wgrant> lifeless: Do you know how Ubuntu uses series tasks?
[01:49] <lifeless> for guiding developer effort in backports
[01:49] <lifeless> not 'backports'
[01:49] <wgrant> Hah.
[01:49] <wgrant> No.
[01:49] <lifeless> I know what I mean
[01:49] <wgrant> That's one use.
[01:49] <wgrant> They are used for security updates and SRUs.
[01:49] <lifeless> yes
[01:49] <wgrant> But also for indicating release criticality.
[01:50] <wgrant> Targetting something to the dev series makes it release critical.
[01:50] <sinzui> thumper: wgrant: I am exhausted, but I can see that this conversation is a sequel to my predicament from last week. thumper the rules and sample data are bad. We may have fixed the factory in the last 12 hours. Have fun storming the castle
[01:50] <lifeless> wgrant: so, conjoined masters are not needed for that
[01:50] <wgrant> lifeless: Eeeeh.
[01:50] <wgrant> lifeless: If there is no DSP task, then the bug won't show up in most listings.
[01:51] <lifeless> wgrant: that is - and always was - a bug in those listings
[01:52] <lifeless> our concept of 'bug target' doesn't map directly to obvious queries
[01:53] <lifeless> if we fix that: e.g. search on distribution=1 or distroseries = distribution.development_focus - a lot of pain just disappears
[01:53] <wgrant> Right.
[01:54] <sinzui> make it so
[01:54] <lifeless> arguably we should search on distribution=1 or distroseries in (distribution.distro_serieses)
[01:54] <lifeless> that would be a behaviour change
[01:54] <lifeless> my point here is that we can, without changing behaviour, eliminate conjoined bugtasks
[01:54] <lifeless> make the bugtask table smaller
[01:55] <lifeless> and make a bunch of code cleaner
[01:55] <wgrant> Behaviour is still slightly changed.
[01:55] <wgrant> But I agree fully.
[01:57] <thumper> I suppose I should go and get my kids from school
[01:58]  * thumper wanders off
[01:58] <lifeless> and that using milestones, or not, is a different discussion, *because* we could do this separately
[01:58] <lifeless> wow
[01:59] <lifeless> 252 Time Outs
[01:59] <lifeless> even *with* that search issue
[01:59] <wgrant> Nice.
[01:59] <wgrant> Less than 1500 critical OOPSes.
[01:59] <lifeless> and a lovely long list of page ids
[02:00] <lifeless>     2 /    0  https://api.launchpad.net
[02:00] <wgrant> And full listings.
[02:00] <wgrant> Yeah.
[02:00] <lifeless> >< wadl
[02:00] <wgrant> [02:00] <wgrant> :(
[02:00] <wgrant> I guess that is potentially less bounded than the pageids.
[02:01] <lifeless> nah, oops-tools code breaks my brain
[02:01] <wgrant> sinzui: Did you get anywhere with the TP corruption?
[02:01] <wgrant> We should be just below 1000 exceptions tomorrow.
[02:01] <wgrant> Er, day after.
[02:01] <sinzui> wgrant: I did not. I wanted to talk to henning. I wondered if he knew something about changes to launchpad translations coordinators
[02:02] <lifeless> might drop us another second tomorrow
[02:02] <wgrant> lifeless: Go all the way to 10.
[02:02] <lifeless> wgrant: no
[02:02] <wgrant> :(
[02:02] <sinzui> wgrant: 1. I believe we could fix the data with a stealthy add remove using the UI, but I want to know how this state happened first
[02:02] <wgrant> sinzui: The SQL breaks my brain.
[02:02] <StevenK> lifeless: Isn't this our third drop in like a week?
[02:02] <wgrant> sinzui: I assume there must be a bug there.
[02:02] <wgrant> StevenK: Only the second.
[02:02] <wgrant> Hence me wanting to go to 10.
[02:03] <lifeless> wgrant: a second at a time mitigates the risk of multiple pages right on the boundary and not clear in the ppa
[02:03] <lifeless> ppr
[02:03] <lifeless> bah
[02:03] <wgrant> Meh
[02:03] <sinzui> oh, I can get jcsackett involved. It might bring back traumatic memories, but I think it will make him stronger
[02:03] <lifeless> wgrant: this strategy is working, so I take your 'Meh' and raise you 'Meh'
[02:04] <wgrant> lifeless: Meh.
[02:04] <lifeless> 147.19s  OOPS-1900K1313  Person:+contactuser <>
[02:04] <wgrant> Someone's trying to talk to big teams.
[02:04] <lifeless> wow 973  OOPS-1900M785   Product:+download
[02:04] <lifeless> wgrant: yes, the 'spam me' button is alive and well :>
[02:04] <StevenK> K, M, C, Q are all different appservers?
[02:04] <lifeless> StevenK: yes
[02:04] <wgrant>    2 ProgrammingError: permission denied for relation revisionauthor
[02:05] <wgrant> In branchmail.
[02:05] <wgrant> Huh.
[02:05] <StevenK> lifeless: Okay, but we don't really care which appserver, right?
[02:05] <lifeless> StevenK: if you suspect GIL contention
[02:05] <lifeless> StevenK: then you will want to lookup and see if its a 1/2 thread server, or a 4-thread server
[02:05] <lifeless> in lp-production-configs
[02:05] <sinzui> We have had a mechanism for queuing emails to users for 2.5 years and it has exactly one call site, person.merge. I think we can speed up a lot of registry and answers reusing it
[02:06] <StevenK> I think we can speed up some of soyuz by also reusing it
[02:06] <lifeless> sinzui: +1 without looking at the code ;)
[02:07] <wgrant> StevenK: Oh?
[02:07] <wgrant> StevenK: Only queue accepts send email.
[02:07] <wgrant> And then only two per package.
[02:07] <wgrant> It's not great, but it's like 0.1% of the time.
[02:07] <lifeless> POTemplate:+index 12529 37194.36 8.03
[02:08] <lifeless> translations will still have a high 99th percentile I think
[02:08] <lifeless> till that page gets improved
[02:08] <lifeless> PreviewDiff:EntryResource has a 54 second 99th percentile ><
[02:09] <lifeless> Distribution:+edit - 33seconds
[02:09] <wgrant> We need to use <blink> on the timing information if it exceeds the 99%
[02:11] <wgrant> https://code.launchpad.net/~wgrant/launchpad/bug-456616/+merge/53556, anyone?
[02:12] <lifeless> wgrant: do you mean by the uid ? and if its over our target 99th percentile?
[02:14] <wgrant> lifeless: The one by the UID, but anything over the current 99th percentile.
[02:14] <wgrant> That way it decreases without everything flashing.
[02:14] <wgrant> With red 72pt bold.
[02:15] <lifeless> wgrant: if you want to do it, I can describe how I'd do it.
[02:15] <wgrant> No.
[02:15] <lifeless> wgrant: I was thinking of a background stylesheet - like demo - with the word 'SLOW' on it.
[02:15] <wgrant> Hah.
[02:15] <wgrant> Oh, even better, an animated GIF background!
[02:15] <lifeless> no
[02:15] <wgrant> We can take slow pages back to the 90s.
[02:16] <lifeless> green on black baby
[02:16] <lifeless> switch the stylesheet
[02:16] <lifeless> so - seriously.
[02:16] <lifeless> in my original concept for this, I wanted a pervasive, unintrusive message on problem pages
[02:17] <wgrant> I was sort of thinking an FF which highlights the time in red if it's exceeded.
[02:17] <lifeless> the watermark idea was one way to do it
[02:17] <wgrant> But your suggestion might be nice.
[02:17] <sinzui> lifeless the background image is really easy. weather configured or using a onload event (life the query count), we can add a class to the body like we do private. huwshimi is landing a replacement for the private background soon too
[02:17] <lifeless> yes, a new FF which sets the time to alert-if-exceeded would be the implementation I'd choose
[02:17] <lifeless> sinzui: can you stack background images ?
[02:18] <sinzui> no
[02:18] <lifeless> sinzui: so I wouldn't want to break private pages and make them appear public
[02:18] <lifeless> sinzui: how is that handled on staging etc?
[02:18] <sinzui> but we also have the maincontent div which allows us to have multiple backgrounds with a little more effort
[02:19] <lifeless> sinzui: if anyone wants to wire this up, I'd be ecstatic; if they need help or input on getting a value in the main template to trigger this - I can do that in ~ 5 minutes, and its -dead- easy.
[02:19] <huwshimi> sinzui: lifeless: css3 does actually give us the ability to have multiple background images, but they need to be defined differently.
[02:19] <sinzui> lifeless: config.is_demo is checking in the base-template and it adds a class to body
[02:19] <lifeless> like the time in the top right, it will need to be onload based.
[02:44] <thumper> lifeless: at least this one is solved :-)   2 / 0NullBugTask:+index
[02:44] <wgrant> thumper: That class no longer exists.
[02:45] <wgrant> It's unfortunate that it didn't time out much on its last day.
[02:45] <thumper> wgrant: exactly. Solved.
[02:45] <wgrant> Heh.
[02:49] <cody-somerville> wgrant, do PPAs not generate kernel udebs or something?
[02:49] <wgrant> cody-somerville: AFAIK they should.
[02:51] <thumper> wallyworld_: ping
[02:51] <wallyworld_> thumper: hi. hope things are ok with your friend
[02:52] <thumper> wallyworld_: he is feeling much better
[02:52] <thumper> wallyworld_: got mumble?
[02:52] <wallyworld_> yep. give me a sec
[03:32] <lifeless> poolie: what was the search you were making that timed out? [also, my preference is for new bugs please]
[03:33] <lifeless> its much easier to dup than to split
[03:34] <lifeless> poolie: bugsearch, for instance, has about 10/20 different components, all of which can be a problem, so theres no particular reason to think that a timeout in one search is meaningful for a timeout in a different search, unless its hitting the same code path with the same data
[03:36] <poolie> surely the search is in the oops?
[03:37] <poolie> for EOFError in /bzr iirc
[03:38] <lifeless> poolie: oopses take up to 20 minutes to get visibility
[03:38] <lifeless> 2.45 seconds for me : https://bugs.launchpad.net/bzr/+bugs?field.searchtext=eoferror&orderby=-importance&search=Search&field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_pa
[03:39] <lifeless> (if that didn't truncate)
[03:41] <StevenK> Did
[03:41] <StevenK> &field.has_no_pa
[03:41] <lifeless> https://bugs.launchpad.net/bzr/+bugs?field.searchtext=eoferror
[03:45] <lifeless> wgrant: hah, I had just started to look at 607954
[03:45] <lifeless> wgrant: enjoy :)
[03:45] <wgrant> lifeless: Just finishing it up now.
[03:45] <wgrant> The page is actually very lucky.
[03:46] <wgrant> In most cases now it avoids another three queries per diff.
[03:46] <wgrant> Because it's already preloaded them accidentally.
[03:46] <lifeless> hahahahah
[03:47] <wgrant> Oh, I hate circular imports.
[03:47] <lifeless> ok, all soyuz errors are clearly visible in the new report
[03:47] <spm> you should try circular servers some time. server A depends on server B being alive and working; B depends on C; C depends on A. Boom.
[03:47] <poolie> if it happens persistently i'll file a new bug
[03:47] <lifeless> poolie: thanks
[03:47] <poolie> it does not seem as regular as it was yesterday
[03:48] <lifeless> spm: we do that to keep you on your toes
[03:48] <poolie> i guess the one off will show up in the oops report?
[03:48] <lifeless> poolie: we're down 50% on timeouts from yesterday
[03:48] <lifeless> poolie: yes, it will
[03:48] <lifeless> poolie: and 75% on timeouts from the week before
[03:51] <poolie> way to go
[03:56]  * StevenK looks for the critical bug graph
[03:57] <mwhudson> StevenK: http://webnumbr.com/.join(launchpad-oops-bugs.all,launchpad-timeout-bugs.all,launchpad-critical-bugs.all) ?
[03:59] <wgrant> Huh.
[03:59] <wgrant> I was going to say that that expression could be simplified. I didn't realise it was a real URL.
[04:00] <lifeless> StevenK: its about to jump
[04:00] <lifeless> StevenK: as I'm going to file bugs for all the timeouts
[04:00] <StevenK> Heh
[04:01] <wgrant> lifeless: Requested the timeout drop yet?
[04:01] <lifeless> wgrant: *tomorrow*
[04:01] <lifeless> wgrant: I want a full day without search index fail etc
[04:02] <wgrant> Ah, right.
[04:02] <lifeless> wgrant: so when the oops reports come out tomorrow, I'll get spm to drop it, and awaaaay we go
[04:03] <lifeless> wgrant: I assure you, I'm ask keen as you are to get the cap down low
[04:03] <lifeless> s/ask/as/
[04:04] <wgrant> Heh
[04:04] <lifeless> bugs domain was 50% of our page renders last month
[04:04] <lifeless> 20M/40M
[04:05] <mwhudson> lifeless: does that exclude robots?
[04:05] <lifeless> mwhudson: its apparently  bong
[04:05] <StevenK> Or API scripts?
[04:05] <mwhudson> lifeless: :)
[04:05] <lifeless> https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-monthly-categories.html
[04:05] <wgrant> API scripts are excluded.
[04:05] <lifeless> All Launchpad except operational pages
[04:05] <lifeless> (?<!\+opstats|\+haproxy)$	39421999
[04:05] <wgrant> I don't trust that number, though.
[04:05] <lifeless> API
[04:05] <lifeless> ^https?://api\.	74901732
[04:05] <lifeless> Launchpad
[04:05] <lifeless> .	164821045
[04:06] <lifeless> so, raw count is 164M
[04:06] <lifeless> api 75M
[04:06] <lifeless> but 'non opstats' is only 40M.
[04:06] <lifeless> wtf
[04:06] <wgrant> Yeah.;
[04:06] <wgrant> That's what I'm wondering.
[04:06] <lifeless> thus - 'bong'
[04:06] <lifeless> fraaaaaaaanics
[04:06] <wgrant> Since the daily non-opstats counts are much higher than 39000000/30
[04:06] <StevenK> And Bugs - search is zero
[04:06] <StevenK> Which amuses me
[04:06] <lifeless> thats a whack reges is all
[04:07] <StevenK> lifeless: Tautology
[04:07] <lifeless> ah
[04:07] <lifeless> down the bottom
[04:07] <lifeless> All launchpad except opstats
[04:07] <lifeless> (?<!\+opstats)$	118473614
[04:07] <lifeless> which is santer than the non-haproxy inclusive one ><
[04:07] <lifeless> -no-freaking-idea
[04:07] <wgrant> But look at daily categories.html
[04:07] <StevenK> Registry is bong, too
[04:07] <wgrant> 6.5m non-opstats-non-haproxy
[04:08]  * StevenK deletes shipit
[04:08] <wgrant> Oh. But that might include API.
[04:08] <wgrant> Yeah.
[04:08] <wgrant> https://devpad.canonical.com/~lpqateam/ppr/lpnet/2011-03/daily_2011-03-05_2011-03-06/categories.html appears to have 3.2m non-API non-haproxy non-opstats requests.
[04:09] <lifeless> wgrant: yes
[04:09] <lifeless> wgrant: according to the daily ppr, most of our growth was scripts
[04:09] <wgrant> Even assuming a conservative 20 working days a month, that's still 64m page views.
[04:09] <wgrant> So where is 40m coming from,.
[04:09] <lifeless> ah, I see what you're cross referencing
[04:09] <lifeless> yes, its bong
[04:36] <jtv> lifeless: I'm looking at the feature flag controller.  The handling of per_thread.features looks pretty messy — so I'm wondering if maybe there's some good reason why we're manipulating per_thread.features ad-hoc in so many places?  (If not, I'd like to clean it up)
[04:37] <wgrant> https://code.launchpad.net/~wgrant/launchpad/bug-607954/+merge/53567, anyone?
[04:37] <jtv> wgrant: oh, I'm OCR so I might as well
[04:37] <lifeless> jtv: the right way would be a participation annotation, but - meh
[04:38] <jtv> lifeless: what's a participation annotation?
[04:38] <lifeless> maybe I mean interaciton annotation
[04:39] <wgrant> You probably want the interaction.
[04:39] <wgrant> Participation could work too, but I like to pretend that participations don't exist.
[04:41] <lifeless> jtv: anyhow, it doesn't seem like an overhaul here would help you at all
[04:41] <jtv> Would improving that be complicated in any way if I replaced all the various reads from and writes to per_thread.features with calls to the existing getter and a new setter?
[04:41] <lifeless> jtv: and you were concerned about rabbit holes the other day
[04:42] <lifeless> jtv: I suspect its a noop change
[04:43] <jtv> I find there's not a lot of cost to cleaning it up, but it saves some wtf in the code that we already have and the code that I need to add.
[04:43] <jtv> I was just wondering if maybe there's some clever grand scheme behind the current mess.
[04:47] <lifeless> nope
[04:49] <jtv> ok, a single getter & single setter it is then.
[04:56] <StevenK> The London Olympics countdown clock has clapped out after less than a day, the BBC reports.
[04:56] <StevenK> The precision timepiece was triumphantly unveiled in Trafalgar Square yesterday, but failed to clear the first 24-hour hurdle and is now stuck on 500 days and 7:06:56.
[04:56]  * StevenK cackles.
[04:58] <lifeless> jtv: fwiw, assignment is a single setter.
[04:59] <wallyworld_> StevenK: it's probably running on windows :-)
[05:01] <StevenK> I thought the Reg's joke of "Well, don't power it with one AAA battery ..." was funnier.
[05:33] <LPCIBot> Project db-devel build #456: FAILURE in 4 hr 17 min: https://hudson.wedontsleep.org/job/db-devel/456/
[05:34] <jtv> lifeless: it's not just assignment, it's setattr as well.  Both encode both the per_thread variable and the reference at every instance.  And then a mix of getattr and get_relevant_feature_controller to read it.
[05:44] <StevenK> lp.services.job.tests.test_runner.TestTwistedJobRunner.test_timeout fails on db-devel on Jenkins again. :-(
[05:44] <wgrant> Yeah.
[05:45] <StevenK> jtv: Why createForPublication()? Every single other job uses create()
[05:45] <jtv> StevenK: this doesn't create a job though
[05:46] <jtv> it may create any number of jobs
[05:46] <jtv> So it deserves a different name from the existing create() method.
[05:47] <jtv> Also, I wanted to specify the relationship to the publication explicitly because it's not as simple as one might infer from just create().
[05:47] <StevenK> I note you don't actually create the job for distroseries
[05:48] <StevenK> You create jobs for direct children (which is fine), and the parent (which isn't)
[05:48] <jtv> Ah damn you're right
[05:48] <jtv> It should be the children and the distroseries itself.
[05:48] <StevenK> Right
[05:48] <jtv> Could you file a bug?
[05:48] <StevenK> I'll fix it
[05:48] <jtv> Thanks, and sorry
[05:50] <StevenK> And then test_createForPackagedPublication_creates_job_for_parent_series fails
[05:50] <StevenK> Which is broken, anyway
[05:52] <jtv> Yes, what I got wrong was what the code should do, not just the code itself.
[05:54] <StevenK> That test is far more broken, with a three-tiered distroseries on distroseries action
[05:56] <StevenK> But I can use that.
[06:22] <wgrant> jtv: I have three reviews for you now... or should I throw them at someone else?
[06:23] <StevenK> wgrant: I'll take one
[06:23] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-390543/+merge/53568 is the most pressing.
[06:23] <wgrant> Thanks.
[06:27] <StevenK> wgrant: I can understand the culling of the first 40 lines of checkwatches.txt. Why the rest?
[06:27] <wgrant> StevenK: I needed to move some of the bits further down, and switch DB users in a couple of places. So I changed the doctest to use the context manager.
[06:28] <wgrant> More readable and shorter.
[06:28] <StevenK> wgrant: This is a niggle, but you no longer test checkwatches oops use the 'CW' prefix
[06:30] <wgrant> StevenK: That was why I hadn't fixed this earlier. But I decided that I don't care enough about testing that to keep that exception around.
[06:30] <wgrant> Since no other script has a test like that.
[06:30] <StevenK> Right.
[06:30] <StevenK> wgrant: You could replace the login() call on 231 with 'with person_logged_in()' if you wished
[06:31] <wgrant> StevenK: I could.
[06:31] <StevenK> But I'm not certain how much of the rest of the doctest wants admin rights, so "Meh"
[06:31] <wgrant> Exactly.
[06:31] <StevenK> wgrant: r=me
[06:31] <wgrant> Thanks.
[06:32] <StevenK> How long I have waited to say that.
[06:32] <wgrant> StevenK: The others are pretty simple. Could you look at them too?
[06:32] <StevenK> wgrant: I dunno. What have you got to offer?
[06:33] <wgrant> https://code.launchpad.net/~wgrant/launchpad/bug-734573/+merge/53572 and https://code.launchpad.net/~wgrant/launchpad/bug-607954/+merge/53567 are the MPs in question.
[06:33] <wgrant> I am afraid I have no offering beyond the glory of reviewing them.
[06:34] <StevenK> No beer?
[06:34] <StevenK> Oh, that's right, you aren't old enough to buy it.
[06:36] <StevenK> wgrant: Ah, and some trailing whitespace fixed. r=me for the first.
[06:36] <StevenK> wgrant: https://code.launchpad.net/~wgrant/launchpad/bug-607954/+merge/53567 looks like it is errornously linked to bug 390543
[06:36] <_mup_> Bug #390543: Checkwatches shouldn't record an OOPS if there isn't an ExternalBugTracker for a given BugTrackerType <lp-bugs> <oops> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/390543 >
[06:37] <wgrant> StevenK: Ah, good catch. I was committing to the wrong branch when I was working on 390543, then removed the problematic revs but forgot to unlink.
[06:38] <wgrant> Fixed.
[06:39] <StevenK> wgrant: my only concern with the second is line 71. Why are you changing it to a set?
[06:40] <wgrant> StevenK: It eliminates duplicates, making queries more readable.
[06:40] <wgrant> Since in most cases the archive and distributions will all be the same.
[06:41] <wgrant> This will do 'id IN (1,)' instead of 'id IN (1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1)'
[06:41] <StevenK> wgrant: Could I beg for a comment, since that's quite elegant.
[06:41] <wgrant> I could do it in the callsite, but this is going to be useful everywhere.
[06:41] <wgrant> Will do.
[06:43] <wgrant> StevenK: Thanks.
[06:44] <StevenK> wgrant: You're welcome. Three critical fixes is awesome.
[06:45] <wgrant> That's eight for the day. Maybe I'll make it to 50 this cycle.
[06:45] <StevenK> Crumbs.
[06:45] <StevenK> Pity it is cheaper to file criticals than it is to fix them.
[06:48] <wgrant> Heh.
[06:48] <wgrant> Yeah.
[06:51] <wgrant> StevenK: sinzui unfortunately did a lot of CSS fixes for 11.03, so he nearly caught up to me :(
[06:51] <StevenK> Haha
[06:55]  * StevenK wields his nailgun and nails jtv to the Internet
[06:56] <lifeless> wgrant: how many did sinzui do?
[07:03] <wgrant> lifeless: 25 bugs in total :(
[07:06] <lifeless> wgrant: and you? what time period ?
[07:06] <lifeless> wgrant: what did I do ?
[07:07] <wgrant> https://launchpad.net/launchpad/+milestone/11.03
[07:07] <wgrant> I did 34, you 17.
[07:08] <lifeless> I should stop reopening, or doing bugtask:=index :> - if I cared about the sheer counts
[07:08] <wgrant> Heh, BugTask:+index is nearly under control.
[07:09] <wgrant> It helps that I handled a lot of tiny incident-critical fixes last months.
[07:16] <lifeless> helps both your stats, and the project :) winwin
[07:16] <wgrant> Well, it had better be a winwin, because those incidents are damn annoying. :)
[07:20] <wgrant> lifeless: I can has patch number for bug #715236?
[07:20] <_mup_> Bug #715236: Validate architecturetag <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/715236 >
[07:30] <lifeless> wgrant: stub should be around soon, if you want to optimistically grab one - do so from the wiki page
[07:30] <lifeless> wgrant: what needs changing ?
[07:30] <wgrant> lifeless: distroarchseries.architecturetag needs valid_name applied.
[07:30] <lifeless> as a check constraint ?
[07:31] <wgrant> Yes.
[07:31] <lifeless> kk
[07:37] <jtv1> wgrant: sorry, got distracted and forgot about your review.  What still needs reviewing?
[07:38] <wgrant> jtv1: StevenK did them all. :(
[07:38] <wgrant> So you are safe for now.
[07:38] <jtv1> whoops
[07:38] <jtv1> Terribly sorry about that.
[07:39] <wgrant> 'tis fine. StevenK was glad to exercise his new superpowers, I am sure.
[07:39] <jtv1> Ah yes
[08:04] <lifeless> wgrant: 'Note that adding new users requires manual DB reconfiguration' - security.py might want to detect and error clearly
[08:04] <poolie> i like the new loggerhead skin
[08:06] <wgrant> lifeless: Then we have DB upgrades failing instead of scripts.
[08:06] <wgrant> == bad
[08:06] <wgrant> And it's also really hard to detect that...
[08:06] <wgrant> I'm not sure if it's even possible.
[08:07] <lifeless> wgrant: security.py isn't part of the ddl scripts sequence
[08:07] <lifeless> wgrant: it runs after
[08:07] <wgrant> lifeless: True.
[08:07] <wgrant> But it's still not really feasible to detect.
[08:12] <lifeless> poolie: on b.l.n?
[08:13] <poolie> yes
[08:14] <lifeless> its quite nice
[08:14] <lifeless> I really want to ditch the b.l.n domain - incorporate loggerhead as routes within c.l.n.
[08:15] <lifeless> poolie: your timeout was an 11 second count
[08:15] <lifeless> poolie: something bong there
[08:15] <lifeless> poolie: given that there are only 4 matching bugs
[08:16] <wallyworld> poolie: bug 735202
[08:16] <wallyworld> it gives a 404 as expected when i try it locally
[08:16] <wallyworld> not sure why
[08:16] <poolie> http://pad.lv/735202
[08:16] <wallyworld> it works locally but fails on lp.net
[08:17] <wallyworld> perhaps someone already fixed it and it's not deployed yet?
[08:17] <poolie> are you sure you're using the same data situation?
[08:17] <wallyworld> i try and access a private bug
[08:17] <wallyworld> it gives 404
[08:17] <lifeless> wallyworld: using launchpadlib
[08:17] <wallyworld> when i mark it non-private, it returns the data
[08:18] <wallyworld> lifeless: i used curl to api.lp.dev like in the bug report
[08:18] <wgrant> wallyworld: Heh, that changed this morning.
[08:18] <lifeless> kk
[08:18] <wgrant> As of a few hours ago they 404.
[08:18] <wgrant> I should probably take that bug.
[08:18] <wallyworld> poolie: ^^^^^^^^^^^^^^
[08:18] <wallyworld> wgrant: i guess that may have been the case
[08:18] <wgrant> It was an unrelated change.
[08:18] <poolie> oh great
[08:18] <wgrant> Well, sort of related.
[08:18]  * wallyworld looks for another bug to fix
[08:18] <wgrant> But not raelly.
[08:19] <lifeless> deleting code good
[08:19] <lifeless> only another 300KLOC to go
[08:19] <wgrant> It's more than that.
[08:19] <lifeless> wgrant: lp ? yes, I don't want to delete lp. Just the fat.
[08:20] <wgrant> Heh.
[08:20] <wgrant> ~/launchpad/lp-branches/clean-devel$ find -type f -name '*.py' | xargs wc -l | tail -n 1 605989 total
[08:20] <wgrant> That's more than I expected :/
[08:21] <poolie> wallyworld, i filed a couple of similar ones
[08:24] <wallyworld> poolie: ok
[08:36] <stub> Urgh.... feels like the beginnings of tonsillitis :-(
[08:46] <lifeless> stub: :(
[08:50] <adeuring> good morning
[08:52] <jtv> hi adeuring
[08:52] <adeuring> hi jtv!
[08:53] <jtv> Do we have any reviewers here who are very familiar with feature flags?
[08:54] <jtv> lifeless: I thought stub can set feature flags?
[08:55] <stub> Power, yes. Understanding?
[08:55] <jtv> Na, who cares about understanding
[08:56] <jtv> Just the thing I needed to be saying at the exact point my boss walked into the room, at the opening of review season…
[08:57] <jtv> stub: I've got a patch up for review that, among other things, lets us disable scripts by feature flag (and the feature would also be suitable for tweaking log levels later).  I thought that would let us reduce losa interrupts, but according to lifeless it doesn't help much in that regard.
[09:00]  * bigjools waves at jtv
[09:01] <jtv> so you saw that then :)
[09:01]  * bigjools averts eyes
[09:03] <jtv> jml, are you into feature flags in a big way?  I need a reviewer for https://code.launchpad.net/~jtv/launchpad/bug-735319/+merge/53578
[09:04] <jtv> (Or if not a review, at least a tie-breaker—see comments :)
[09:04] <poolie> thanks for tackling that jtv
[09:04] <poolie> i'll have a look too
[09:04] <jtv> oh thanks
[09:08] <jtv> bigjools: I'd be a lot more comfortable with rewriting cron.publish-ftpmaster knowing that it was tested
[09:08] <bigjools> jtv: chicken/egg
[09:09] <bigjools> we can do manual testing easily on DF
[09:09] <jtv> But sounds like the first thing to do is figure out what it does, and write tests for that.
[09:09] <wgrant> "easily
[09:09] <wgrant> "
[09:09] <bigjools> yes, easily
[09:09] <bigjools> wgrant is so negative!
[09:09] <jtv> Given how people tend to say "trivial" for things that turn out to be a lot of work, "easy" really worries me as well.
[09:10] <bigjools> it's all relative jtv :)
[09:10] <bigjools> jtv: I can do a pre-imp about it with you
[09:10] <jtv> Oh nice, a pre-imp sprint.  Is next week good for you?
[09:11] <bigjools> only if you come here :)
[09:11] <lifeless> jtv: policy for FF changes is losas do
[09:11] <jtv> oic
[09:11] <lifeless> jtv: and, as I say its overloaded with the non-db style of killing, and we *must not* attempt a db-style disable during db-deploys.
[09:12] <jtv> OK, I'll take that bit out then.  Thanks for pointing it out.
[09:12] <lifeless> thanks
[09:13] <bigjools> lifeless: what makes bzr do a repack when I pull?
[09:13] <bigjools> and can I put it off to a time when it's not inconvenient to wait 30 minutes? :)
[09:14] <poolie> bigjools, if your local repository passes a certain size threshhold
[09:14] <poolie> urk
[09:14] <bigjools> ah thanks poolie
[09:14] <wgrant> bigjools: Mine has done that twice today :(
[09:14] <bigjools> I might file a bug about this, I think it should prompt/nag
[09:14] <lifeless> meep - 665  OOPS-1900K1319  Person:+contactuser
[09:15] <lifeless> bigjools: its an exponential backoff
[09:15] <lifeless> bigjools: 30 minute ones should be -extremely- rare, but you can make sure it never happens by putting 'bzr pack' into cron
[09:16] <lifeless> we could/should also permit backgrounding it automatically - packs don't block writers
[09:16] <lifeless> *packing does not*
[09:16] <bigjools> 30 mins might be exaggerating, but the last one on my desktop took 15-20, and I am now waiting for dogfood which has slow disks :(
[09:16] <wgrant> s/disks/everything/
[09:17] <bigjools> backgrounding/nag/prompt all good :)
[09:17] <wgrant> stub: Thanks.
[09:17]  * bigjools filez
[09:17] <bigjools> Gnome apps really stand out on my desktop, they're the only ones that don't restore their state and throw a million error dialogs.
[09:18] <wgrant> GNOME session saving used to work great.
[09:18] <wgrant> I think I last used it in 2002, though..
[09:18] <bigjools> I know :/
[09:23] <bigjools> I think I last used gnome in 2002 :)
[09:23] <wgrant> Hah.
[09:23] <bigjools> apart from you watching me flinch at that UDS when I tried it
[09:24] <wgrant> Yes, that was amusing.
[09:26]  * bigjools installed KDE4.6 yesterday, not a Unity in sight :)
[09:26] <StevenK> Yes, we know KDE isn't unified.
[09:27] <bigjools> bwahaha, you've seen the Gnome project? :)
[09:27] <StevenK> I was hoping you weren't going to point out the irony, but you did ...
[09:28] <wgrant> Unity has only crashed once this week!
[09:28] <bigjools> sorry, I wasn't aware Australians did irony
[09:28] <wgrant> And I actually quite like it now.
[09:28] <StevenK> bigjools: Isn't that some kind of metal?
[09:28] <poolie> jtv, ok, done
[09:28] <bigjools> StevenK: it's what your wife does
[09:28] <poolie> and so, goodnight
[09:28] <bigjools> nn poolie
[09:29] <poolie> if China wants to buy irony we'll sell it
[09:29] <StevenK> I can see this conversation going nowhere good.
[09:29] <poolie> oh, Blacktown? :)
[09:29] <bigjools> West Sydney
[09:29] <StevenK>  /ragequit
[09:29] <bigjools> lmao
[09:29] <poolie> :-P
[09:29] <poolie> good night gentlemen
[09:33] <bigjools> lifeless, poolie (if you're around), my bzr pull took 24 minutes :)
[09:33] <bigjools> I filed a bug anyway
[09:39] <lifeless> cool
[09:39] <lifeless> I filed 22 :P
[09:39] <lifeless> night all
[09:49] <wgrant> lifeless: :(
[09:53] <LPCIBot> Yippie, build fixed!
[09:53] <LPCIBot> Project db-devel build #457: FIXED in 4 hr 19 min: https://hudson.wedontsleep.org/job/db-devel/457/
[10:09] <wgrant> jtv: Want to review https://code.launchpad.net/~wgrant/launchpad/bug-715236/+merge/53576?
[10:09] <wgrant> Almost as trivial as they get.
[10:12] <StevenK> wgrant: r=me
[10:12] <jml> how did we get 18 new critical bugs over night?
[10:13] <StevenK> jml: One word: lifeless
[10:13] <wgrant> lifeless filed a bug for all the timeouts.
[10:13] <wgrant> StevenK: Thanks.
[10:13] <jml> do we have new timeouts?
[10:13] <wgrant> jtv: We now have a full list.
[10:13] <wgrant> Er, jml
[10:13] <jml> meh. I've been told that before
[10:13] <wgrant> jml: The OOPS reports used to only have the top 10, but lifeless fixed that.
[10:14] <jml> wgrant: ok. that gives some grounds for confidence.
[10:14] <wgrant> jml: So, we will still have missed some that only occur a couple of times a week, but there probably aren't too many of those.
[10:14] <wgrant> Hopefully.
[10:15] <jml> it's been so exciting watching the number of critical bugs go down this last week
[10:16] <wgrant> I've landed 10 fixes today... so we are only up by about 10.
[10:16] <jml> \o/
[10:23] <adeuring> jtv: could you please review a small MP: https://code.launchpad.net/~adeuring/launchpad/translation-branch-sync-return-to-referrer/+merge/53597 ?
[10:24] <jtv> adeuring: otp
[10:25] <adeuring> jtv: ?
[10:25] <jtv> on the phone
[10:37] <jml> bug 12345
[10:37] <_mup_> Bug #12345: isdn does not work, fritz avm (pnp?) <isdnutils (Ubuntu):Fix Released by doko> < https://launchpad.net/bugs/12345 >
[10:41] <bigjools> isdn!
[10:43] <jtv> adeuring: I'm back… still need that review?
[10:43] <adeuring> jtv: yes please
[10:47] <jml> can I url hack to change the batch size?
[10:51] <bigjools> jml: yes, lots of people do
[10:51] <jml> how do I do it?
[10:51] <bigjools> don't ask me to remember that sort of thing :)
[10:54] <jml> heh
[10:55] <jml> well, my immediate need has passed.
[10:56] <henninge> adeuring: Hi!
[10:56] <adeuring> hi henninge
[10:56] <jtv> adeuring: you have been reviewed
[10:56] <henninge> adeuring: Is that the ReturnToReferrer branch you are having reviewed?
[10:56] <bigjools> jml: lib/canonical/launchpad/doc/batch_navigation.txt
[10:56] <henninge> Hi jtv!
[10:56] <jml> bigjools: ta
[10:56] <jtv> henninge: have had.
[10:56] <bigjools> jml: fuck me, documentation :)
[10:56] <adeuring> henninge: well, jtv said so ;)
[10:57] <adeuring> and thanks, jtv!
[10:57] <henninge> adeuring: I put a card for that on the board but I'll leave the satisfaction of moving it to you ... ;-)
[10:57] <bigjools> basically ?batch=N
[10:58] <henninge> adeuring: and added bug 735960
[10:58] <_mup_> Bug #735960: Return to translation sharing details page <Launchpad itself:In Progress by adeuring> < https://launchpad.net/bugs/735960 >
[10:58] <adeuring> henninge: thanks for doing my bureaucracy :)
[10:58] <henninge> adeuring: I know how you loath^Wlove it.
[10:59] <jml> bigjools: thanks.
[10:59] <jml> looks like it's batch=FOO
[11:03] <bigjools> that's what I said :)
[11:04] <jml> bigjools: oops, I missed that.
[11:06] <jml> the standard library should have a tzinfo object for UTC.
[11:06] <deryck> Morning, all.
[11:07] <bigjools> jml: pytz.UTC ?
[11:08] <jml> bigjools: yeah, I'll use that, but it should be in the stdlib
[11:08] <bigjools> why do you think that?
[11:08] <jml> the Python documentation even has an example UTC object
[11:09] <jml> bigjools: because it would be convenient for many people, and doesn't have the ridiculous politically-imposed maintenance cost of other timezones
[11:09] <jml> (and because stacks of methods in datetime mention utc explicitly)
[11:10] <bigjools> fair reasons
[11:10] <jml> and, also,
[11:10] <jml> there's an example in the documentation! so they have to maintain the code anyway.
[11:15] <bigjools> heh
[11:49] <jml> http://paste.ubuntu.com/581050/ <- crit bug breakdown
[11:51] <wgrant> launchpad-buildd? Really?
[11:52] <wgrant> Huh, indeed.
[12:24] <leonardr> can someone point me to a real-life example of a bugtask with a conjoined master? i'm trying to qa bug 556515
[12:24] <_mup_> Bug #556515: OOPS when editing conjoined bugtasks via API <dhrb> <lp-bugs> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/556515 >
[12:27] <wgrant> leonardr: Anything on https://bugs.qastaging.launchpad.net/ubuntu/natty should do.
[12:36] <leonardr> wgrant: any idea why this happens?
[12:36] <leonardr> >>> series
[12:36] <leonardr> <distro_series at https://api.qastaging.launchpad.net/1.0/ubuntu/natty>
[12:36] <leonardr> >>> len(series.searchTasks())
[12:36] <leonardr> 0
[12:36] <wgrant> Hee hee hee.
[12:37] <wgrant> Try omit_targetted=False, or something like that.
[12:37] <wgrant> There's a bug.
[12:37] <StevenK> Just one?
[12:39] <wgrant> I can't find it.
[12:39] <wgrant> But I didn't really try very hard.
[12:39] <wgrant> Bug #320596
[12:39] <_mup_> Bug #320596: Series.searchTasks() always returns an empty collection <api> <lp-bugs> <qa-ok> <ubuntu-qa> <Launchpad itself:Fix Released by brian-murray> < https://launchpad.net/bugs/320596 >
[12:40] <wgrant> But it's meant to default to False.
[12:40] <wgrant> Hm.
[12:49] <leonardr> ok, now the proble
[12:49] <leonardr> m is i don't have permission to edit any of these tasks
[12:51] <wgrant> leonardr: You can set some things...
[12:51] <wgrant> leonardr: Anyone can set a bug from Triaged to New, for example.
[12:52] <wgrant> I can do just about anything, though, if you need more testing.
[12:52] <leonardr> wgrant: i think i just need you to answer my dumb questions about how these bugs work
[12:53] <leonardr> is this task conjoined? https://api.qastaging.launchpad.net/1.0/ubuntu/natty/+source/nvidia-graphics-drivers/+bug/711409
[12:53] <_mup_> Bug #711409: [MASTER] -nvidia broken after Jan 31st updates, because it does not yet support xserver 1.10 <i386> <natty> <nvidia> <ubuntu> <xorg> <nvidia-graphics-drivers (Ubuntu):Fix Released> <nvidia-graphics-drivers (Ubuntu Natty):Fix Released> < https://launchpad.net/bugs/711409 >
[12:53] <leonardr> i was able to edit its status
[12:53] <leonardr> _mup_ says that's the master
[12:53] <wgrant> leonardr: That's a conjoined slave.
[12:53] <wgrant> [MASTER] is in the summary.
[12:53] <wgrant> It doesn't indicate that it's a conjoined master.
[12:53] <leonardr> ah
[12:55] <leonardr> ok, so, i was able to edit a conjoined slave, which afaict shouldn't happen
[12:55] <wgrant> Er, wait.
[12:55] <wgrant> That is a *master*.
[12:55] <wgrant> Confusing terminology is confusing.
[12:55] <wgrant> The series task is the master, the distribution task is the slave.
[12:55] <wgrant> https://api.qastaging.launchpad.net/1.0/ubuntu/+source/nvidia-graphics-drivers/+bug/711409 (no natty) is the slave.
[12:55] <_mup_> Bug #711409: [MASTER] -nvidia broken after Jan 31st updates, because it does not yet support xserver 1.10 <i386> <natty> <nvidia> <ubuntu> <xorg> <nvidia-graphics-drivers (Ubuntu):Fix Released> <nvidia-graphics-drivers (Ubuntu Natty):Fix Released> < https://launchpad.net/bugs/711409 >
[12:56] <leonardr> i was also able to edit the slave
[12:56] <leonardr> let's see what happens on the website
[12:57] <wgrant> Erk.
[12:57] <wgrant> The slave's details are hidden from the web UI, but you can see them through the API.
[12:57] <leonardr> yeah, it says 'status tracked in natty'
[12:58] <leonardr> ok, got it!
[13:39] <deryck> jml: ping
[13:41] <jml> deryck: pong
[14:01] <deryck> henninge: ping for standup
[14:04] <henninge> deryck: oh yeah, coming
[14:29] <henninge> adeuring: for your search: files are placed in the import queue with a call to addOrUpdateEntry(FromTarball)
[14:30] <adeuring> henninge: thanks
[14:42] <henninge> abentley: I guess the job creation is not hidden behind a feature flag?
[14:42] <henninge> Should it be?
[14:43] <henninge> Is that even doable?
[14:43] <abentley> henninge: It's not.  I don't think it should be.
[14:43] <henninge> abentley: are the jobs being processed now on production?
[14:43] <abentley> henninge: Not yet, we need a config change.
[14:44] <henninge> abentley: https://code.launchpad.net/~henninge/launchpad/devel-735954-merge-job-display/+merge/53629
[14:49] <deryck> abentley: sorry it's taken me so long.  A few conversations developed.  But I have a good head around all the mocking we've done so far....
[14:50] <deryck> abentley: however, my call with henninge is in 10 minutes.  Shall we chat after that?
[14:50] <abentley> deryck: no worries.
[14:50] <abentley> deryck: after henninge's call makes sense.
[14:50] <deryck> abentley: great, thanks.  Chat soon then.
[14:50] <vila> jam, jelmer: care to join mumble to test my new setup ?
[14:51] <vila> meh wrong channel
[15:02] <deryck> henninge: coming.... sorry.  1-2 more minutes and I'll join you.
[15:02]  * henninge hurries to get there first ...
[15:03] <deryck> heh
[15:06] <jcsackett> deryck: i need some javascript help, and you seem to be the guy to talk to. :-)
[15:07] <jcsackett> got a few minutes?
[15:07] <jcsackett> oops, your otp.
[15:12] <deryck> jcsackett: yeah, call, sorry.
[15:12] <jcsackett> deryck: no worries, i should have been paying attention. :-P
[15:12] <deryck> jcsackett: np, really.  so you're right.  I am *the* guy ;)
[15:12] <deryck> jcsackett: however, you need to take a js-number :-)
[15:13] <deryck> jcsackett: I have a call with Aaron about js, and then we can chat :-)
[15:13] <jcsackett> deryck: sounds good. thanks. :-)
[15:15] <deryck> abentley: shall we chat now?  Mumble?
[15:15] <abentley> deryck: sure.
[15:42] <abentley> deryck: http://pastebin.ubuntu.com/581151/
[16:00] <deryck> abentley: so this works as I thought -- variable names are determined by var keyword.  function names are bound to the closure.  Which is why I was confused the first pass of the discussion. :-)
[16:01] <deryck> abentley: so a named function outside of a YUI block would be global, but because YUI blocks are closures, named functions are private to the closure.
[16:01] <abentley> deryck: Is var foo = function() equivalent to function foo() then?
[16:02] <deryck> abentley: inside a YUI block, basically yes.
[16:02] <deryck> abentley: it may be a bit slower to execute, but I can't say that for sure.  I would avoid assigning to var names inside yui.
[16:02] <jcsackett> deryck: i'm unavailable for the next hour, so don't worry about me for a bit if your chat with abentley ends before then. :-)
[16:03] <abentley> deryck: okay.
[16:03] <deryck> jcsackett: it ended 5 minutes ago, but I had the above follow up hacking. ^^  I'm done now, though.
[16:03] <deryck> jcsackett: but I assume we'll chat later?
[16:03] <jcsackett> deryck: yup. will you be free in about an hour?
[16:04] <deryck> jcsackett: actually, no.  I have team lead call top of the next hour.  After that?
[16:04] <jcsackett> deryck: sounds good.
[16:04] <deryck> jcsackett: ok, chat with you then
[16:06] <henninge> abentley: I replied to your review and pushed a new version. Thanks a lot. I have to leave now but I hope you can approve this now.
[16:07] <abentley> henninge: Okay, I'll have a look.
[16:12] <abentley> henninge: r=me
[16:12] <henninge> abentley: thanks a lot!
[16:24] <abentley> deryck[lunch]: could you comment on whether the YUI tests here should be Windmill tests? https://code.launchpad.net/~wallyworld/launchpad/inline-multicheckbox-widget/+merge/52943 (644-827)
[16:56] <bac> hi sinzui
[16:57] <sinzui> hi bac
[16:57] <deryck> abentley: just got off lunch and now tl call.  I'll look closely shortly.
[17:29] <deryck> abentley: I think that's a good YUI test.
[17:30] <abentley> deryck: Thanks for checking.
[17:30] <deryck> abentley: wallyworld had pinged me out of review about mocking, and I don't think we need a custom object there.  I think he can use Y.Mock to simulate the patch request.  Unless I'm missing something about Y.Mock.
[17:31] <deryck> abentley: but I'll reply to his mail to me about that.  Unless he sees this chat first ;)
[17:31] <lifeless> hmm
[17:31] <lifeless> slow librarian performance
[17:34] <lifeless> flacoste: I'm going to drop to 11 seconds today if the oops report looks good
[17:34] <lifeless> https://lpstats.canonical.com/graphs/OopsLpnetHourly/20110315/20110316/ suggests it will
[17:35] <lifeless> flacoste: if this concerns you , speak up now :) - we will have a full days data without index problems etc to work on
[17:36] <bigjools> lifeless: I am concerned about distrseries:+queue
[17:36] <lifeless> 3 /   10  DistroSeries:+queue ?
[17:37] <bigjools> it will become a bigger problem the closer we get to natty release
[17:37] <bigjools> it's not used much *now* but it will get more use
[17:37] <lifeless> bigjools: if it starts to spike, raise its timeout
[17:37] <jcsackett> deryck: you available?
[17:37]  * bigjools gets the same complaints every 6 months
[17:37] <lifeless> bigjools: ideally we'd fix it before then
[17:37] <bigjools> lifeless: that's why I am mentioning it now, it'd be great if you could look :)
[17:38] <lifeless> I think wgrant has been, I'll see if he's still doing so
[17:38] <deryck> jcsackett: oh, hello there again. ;)  sure.  mumble?
[17:38] <jcsackett> deryck: sure.
[17:38] <lifeless> I have been ignoring my ta stuff this last 5-6 work days and just going out and killing timeouts... I suspect I rather need to buckle up and focus :>
[17:39] <bigjools> lifeless: also, we'd like your input on doing background page updates via JS for some derived distros work,  rvba will grab you tomorrow (his time) which is later today for you if you're about
[17:39] <lifeless> sure
[17:39] <lifeless> you're thinking poll for now ?
[17:39] <rvba> yes
[17:39] <bigjools> lifeless: yes, same as the ppa page
[17:39] <lifeless> seems no worse than we have now
[17:39] <bigjools> but I wondered if thumper's work had changed any of that
[17:40] <lifeless> not AFAIK
[17:40] <bigjools> it would only poll until some state changes
[17:40] <lifeless> sure
[17:40] <lifeless> we can tolerate limited amounts of polling
[17:40] <lifeless> when we get a callback mechanism we'll need to roll it out $everywhere anyhow
[17:41] <bigjools> the other question is, exactly how much non-js fallback are we worried about these days
[17:41] <lifeless> + I don't expect derived distros to be huge (like e.g. bugs - 50% of our web pages)
[17:42] <bigjools> there's only one page that has JS but it has a lot of JS :)
[17:42] <lifeless> bigjools: so, google have ways to index js only content
[17:42] <bigjools> I can't remember why we wanted to do non-js fallback anyway
[17:42] <lifeless> I would talk to the stakeholders for this project
[17:42] <lifeless> w3m users :>
[17:43]  * bigjools has a 4 letter word forming
[17:43] <lifeless> bigjools: anyhow, all sounds fine to me; jml / the derived distro stakeholders are the ones to check about non-js support: its not a technical choice, but a political one :)
[17:44] <bigjools> yes exactly
[17:44] <bigjools> unless you count things like not being able to file bugs :)
[17:44] <lifeless> we fixed that :)
[17:47] <lifeless> \o/
[17:47] <lifeless> POFile:+translate is down by ~3 seconds on its 99th percentile
[17:48] <jml> bigjools: for the bug subscription work, we are deliberately doing js only. (at least, as of last time I spoke about it)
[17:48] <bigjools> jml: I think that's sensible
[17:48] <jml> bigjools: we don't have a general policy yet (we will soon), but if you want to proceed assuming that you don't need js fallback, I think that would be fine.
[17:48] <bigjools> although it does mean I need to learn JS again
[17:49] <bigjools> cool, thanks for clarifying
[17:49] <jml> bigjools: hey, deryck linked to a thing about that :)
[17:50] <deryck> JavaScript for people who know Python?  I recommended that to abentley too, who found it useful.
[17:50] <bigjools> what's the link?
[17:50] <bigjools> or should I JFGI :)
[17:50] <deryck> bigjools: http://pycon.blip.tv/file/4882883/
[17:50] <deryck> heh, no I didn't mind :-)
[17:51] <bigjools> ah cool, thanks deryck
[17:51] <deryck> bigjools: np
[17:51] <deryck> bigjools: and then read the YUI docs, please :-)
[17:51] <bigjools> ha :)
[17:52] <bigjools> oh 30 min video, I was hoping I'd know everything there is to know in 5 :)
[17:52] <deryck> if only :-)
[17:53] <bigjools> right, dinner's ready, good night all
[17:53] <jml> bigjools: perhaps we should arrange another two week training course?
[17:53] <bigjools> jml: **** *** *** *** *****
[17:53] <jml> :D
[17:53] <jml> bigjools: g'night
[17:53] <bigjools> ciao!
[17:54] <flacoste> lifeless: like i mentioned to you on Monday, i'm fine with that timeout drop (and thought it already happened, fwiw)
[17:55] <lifeless> flacoste: we dropped to 12
[17:55] <lifeless> flacoste: I wanted a clean, good signal before dropping to 11
[17:55] <jml> 11 is pretty exciting.
[17:56] <deryck> it goes to 11!
[17:56] <jml> it feels like not so long ago we were at 30
[17:56] <lifeless> flacoste: I was sure you'd be ok, I wanted to make sure you were not caught unawares *if* something goes wrong
[17:57] <flacoste> 11! right!
[17:57] <flacoste> that was the follow-up reduction you talked about
[17:57] <flacoste> still good with it
[17:57] <lifeless> yes
[17:57] <lifeless> + a lowering of soft timeout to 9
[17:57] <flacoste> exactly
[17:57] <lifeless> [if we drop hard to 11]
[17:58] <deryck> Why not make 10 louder?  And call that 11.
[17:59] <flacoste> deryck: i didn't know you were making amps in your spare time ;-)
[17:59] <deryck> heh
[17:59] <deryck> side business
[18:22] <jml> lifeless: I'm thinking again about how much I dislike layers and how much I'd like to use a non-Zope test runner.
[18:22] <lifeless> jml: \o/
[18:22] <jml> lifeless: I am thinking further of making a TestSuite that runs tests with layers properly
[18:23] <jml> as in, doing what z.testrunner does but in a more compatible way.
[18:23] <lifeless> that might be interesting
[18:23] <jml> it seems easier than moving away from layers
[18:24] <lifeless> jml: given that we're pretty close on fixtures, it might be better to just move on that
[18:24] <lifeless> jml: I don't think compatibility is the issue with layers, its hte contract: the reinvoking stuff, for instance
[18:25] <jml> lifeless: it's the compatibility issue that's tying us to test.py
[18:26] <lifeless> jml: yes
[18:26] <lifeless> jml: erm
[18:26] <lifeless> jml: no, its not
[18:28] <jml> lifeless: well, you'll have to explain why. also, I don't see a clear path from "improve fixtures" (presumably wrt the graphing stuff) to "run Launchpad tests without z.testing".
[18:29] <lifeless> jml: there are several different things hanging around here
[18:29] <lifeless> test.py
[18:29] <lifeless> z.testing
[18:29] <lifeless> requiring reinvoking to do ZCA testing
[18:30] <lifeless> the graph of dependencies is: reinvoking requires zope.testing requires a test.py script
[18:31] <lifeless> it is trivial to write a TestSuite wrapper than will obey a limited subset of the layers protcol - excluding reinvocation
[18:31] <jml> lifeless: I don't see why re-invocation would be that hard.
[18:32] <lifeless> so, (ignoring the bits of zope.testing that are harnesses for other bits of zope we use) to stop using zope.testing we need to fix the behaviour of our layers
[18:32] <lifeless> jml: let me ask you a different question. What problem are you trying to solve?
[18:32] <jml> (although I agree it would be better to not need to do it)
[18:34] <jml> lifeless: I am interested in removing friction from my development process.
[18:35] <lifeless> jml: The highest priority problem I see on our testing framework list is reinvocation - it costs substantial time and increases peak memory requirements a lot
[18:37] <jml> ok
[18:37] <flacoste> lifeless: you are talking about the support when NotImplementerError is raised in a layer teardDown method?
[18:37] <jml> oops. late for something.
[18:37]  * jml goes
[18:37] <lifeless> flacoste: yes
[18:37] <lifeless> flacoste: we have no good reason for raising that - its just a matter of code to fix the causes
[18:38] <flacoste> lifeless: agreed, especially since upstream isn't using it much anymore (at least not as part of the default ZCA tests)
[18:41] <sinzui> did someone delete ~launchpad-chr on late Friday or Saturday?
[18:41] <lifeless> matsubara did
[18:41]  * matsubara whistles awaya
[18:42] <matsubara> sinzui, hopefully that didn't break anything. AFAICT, it was used as an answer contact for  launchpad
[18:43] <sinzui> I think that is the event that broke team participation. I think merge with ~registry caused confusion in team participation. ~launchpad was a direct member of both teams
[18:44] <matsubara> sinzui, ah, ok. so it's a known bug but you wanted to know the root cause for it to be triggered?
[18:44] <sinzui> I still think we can fix immediate issue with a stealthy add/remove member combination. I just need to think which teams are involved
[18:45] <sinzui> I did not know that merge would corrupt TP. That is a new bug. I am trust trying to see my participation page (bug 733881)
[18:45] <_mup_> Bug #733881: +participation oops because membership and teamparticipation disagree <oops> <teams> <Launchpad itself:In Progress by sinzui> < https://launchpad.net/bugs/733881 >
[18:45] <matsubara> sinzui, not sure if it helps, but I have a list of ~launchpad-chr members before I deleted
[18:47] <sinzui> matsubara: I can see them on staging
[18:48] <matsubara> :-)
[18:48] <sinzui> I think I will co-opt my call with jcsackett to discussing our mutual dislike of TeamParticipation and Person.merge
[18:49] <sinzui> jcsackett: I think you should read https://bugs.launchpad.net/launchpad/+bug/733881 so that we can discuss it in 10 minutes
[18:49] <_mup_> Bug #733881: +participation oops because membership and teamparticipation disagree <oops> <teams> <Launchpad itself:In Progress by sinzui> < https://launchpad.net/bugs/733881 >
[18:55] <sinzui> matsubara: you used the delete team link right? Is this the message you saw: https://staging.launchpad.net/~launchpad-chr/+delete
[18:56] <sinzui> I wonder is delete handled pending members...well merge does not
[18:57] <matsubara> sinzui, yes, that's the message I saw.
[18:57] <matsubara> it took a couple of tries because the action timed out but eventually it did delete
[18:58] <sinzui> thanks. I will use staging then to diagnose what merge did wrong
[18:58] <jcsackett> sinzui: i already saw that bug on the tl report.
[18:58] <sinzui> jcsackett: I updated it a few minutes ago with what I see. I want to discuss the hack to make Lp put the data back, and the root cause in delete/merge
[19:04] <jcsackett> i hate TP.
[19:04] <jcsackett> i sort of dislike the whole team infrastructure, at this point. :-P
[19:06] <sinzui> TeamParticipation is easy to hate, but combined with merge rules, I think I have disconcerting feeling of both despair and delight.
[19:33] <maxb> Chex: Hi - regarding that question you just replied to - the problem is that Launchpad's code import service is broken in respect of SourceForge Mercurial repositories.
[19:34] <maxb> A third party proxying solution to assist the Launchpad code import service seems a bit of a weird solution, so I'm wondering if you misread the question at all?
[19:34] <Chex> maxb: ok, so its not just a matter of post issues, then?
[19:34] <maxb> post? port?
[19:34] <Chex> s/post/port/ sorry
[19:34] <maxb> SourceForge have chosen to use a non-standard port.
[19:35] <maxb> It is of course up to Launchpad to potentially refuse to support it, but it seems like an unlikely decision to make, given how popular SourceForge is
[19:36] <maxb> Actually, is there any concrete reason why the importds do not have unrestricted outbound TCP access to the internet?
[19:37] <lifeless> maxb: they did what?
[19:37] <lifeless> maxb: we don't trust vcs libraries to be bug tree and have no security vulnerabilities
[19:37] <maxb> who did what? SourceForge? They have chosen to run their Mercurial hosting service on a non-standard TCP port
[19:42] <Chex> maxb: its just a general policy we have for only allowing what would be typically used, for security
[19:42] <Chex> lifeless: for reference to what we are talking about: https://answers.launchpad.net/launchpad/+question/147288
[19:42] <maxb> inbound, totally. outbound, I guess my standards are more heavily pragmatic :-)
[19:43] <lifeless> Chex: need an rt for it? I think its fine to open it to sf
[19:44] <Chex> lifeless: I already have one, and the response was for a HTTP Proxy to be setup for this situation.
[19:44] <lifeless> Chex: thats crazy
[19:44] <lifeless> Chex: a) it would require significant special casing in the code import infrastructure
[19:45] <lifeless> Chex: b) it would permit trivial bypassing of our security policy (so we may as well just disable the outbound firewall if we were to do that)
[19:46] <Chex> lifeless: well, I can see your point on that
[19:50] <lifeless> Chex: whats the rt ?
[19:52] <Chex> lifeless: so we already have a HTTP proxy setup, we would just configure this address to point to the remote port, outgoing connection for you
[19:52] <Chex> lifeless: RT# 44626
[19:53] <lifeless> Chex: I don't see any benefit in using an http proxy for hg
[19:53] <lifeless> Chex: its all streaming data
[19:55] <lifeless> Chex: I've commented (just now) on the question
[19:55] <lifeless> Chex: I will do so on the rt too
[19:55] <Chex> lifeless: ok, great, thanks
[21:03] <leonardr> thumper, wallyworld: it would be great to get a review of https://code.launchpad.net/~leonardr/lazr.restful/entry-introduced-in-version/+merge/53704 sometime today
[21:03] <leonardr> i'm eod but i'll stick around if one of you wants to take it and ask quESTIONS
[21:03] <leonardr> or, abentley, if you want to take it
[21:03] <wallyworld> leonardr: i'll look but thumper will need to +1
[21:03] <abentley> leonardr: I'm EOD.
[21:10] <thumper> wallyworld: http://blogs.jetbrains.com/pycharm/2011/03/python-ides-panel-video-from-pycon-2011/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Pycharm+%28JetBrains+PyCharm+Blog%29
[21:11] <thumper> leonardr: mumble?
[21:12] <leonardr> thumper, 1 sec
[22:03] <sinzui> wgrant: mumble>
[22:03] <sinzui> mumble?
[22:03] <jcsackett> exit
[22:04] <wgrant> sinzui: Oh, right, half an hour earlier.
[22:04] <wgrant> Give me a sec.
[22:23] <sinzui> jcsackett: I think Person.deactivateAllMembers() is the issue, which is not really merge or the remove super team rule. It implements a separate TP cleanup
[22:23] <sinzui> And it does not handle recursion well
[22:25] <jcsackett> sinzui: it was at fault once before, but i thought we had cleaned it up.
[22:25] <jcsackett> this is more of the "we have too many ways to do the same thing."
[22:25] <sinzui> I recalled we wanted to unify the code, We have not. I think now is the time
[22:26] <jcsackett> sinzui: yeah, we need one blessed way to handle TeamParticipation.
[22:26] <sinzui> I can see that it will not know what to do in the case of multiple paths to a team
[22:26] <jcsackett> sinzui: we don't handle the multiple paths issue well anywhere. at best, we constrain things to where we ignore all but one path.
[22:26] <sinzui> This gives me hope because the fix looks like deleting code!
[22:27] <jcsackett> sinzui: did Edwin finish the _cleanParticipation work he was doing before he left?
[22:27] <jcsackett> he was working on making that the Right Way (TM), and if he did, we want to use that.
[22:27] <jcsackett> since he knew better than anyone on registry what needed doing there.
[22:28] <sinzui> TM's _cleanTeamParticipation does a recursive check to build a list of excludes. So I have some faith that wne the method tries to do the right thing, it will work deactivateAllMembers() is simple delete of everything
[22:28] <wgrant> (the blessed way is probably triggers)
[22:29] <jcsackett> wgrant: triggers were once a problem for us as well.
[22:29] <jcsackett> or rather, they complicated diagnosing the problem.
[22:31] <jcsackett> basically, management of TeamParticipation is a mess. :-P
[22:32] <mwhudson> neo4j!
[22:32]  * mwhudson hides
[22:32] <wgrant> jcsackett: That's why we should do it in one place that catches everything.
[22:33] <jcsackett> wgrant: i concur. we're on the same page here. i'm -1 on triggers, personally; having things fire off post changes with teams have failed us. i think adopting widespread use of Edwin's work is the way to go.
[22:34] <jcsackett> but i'm +1 on whatever, as long as we're consistent with it and cover all our bases.
[22:34] <wgrant> We already have a set of triggers to do exactly this sort of graph work, for packagesets.
[22:35] <jcsackett> sinzui ^
[22:35] <jcsackett> that i did not know.
[22:44] <lifeless> I'm neutral on triggers
[22:45] <lifeless> we use them
[22:45] <lifeless> but htey have significant downsides
[22:45] <lifeless> not the least of which is causing *more* db roundtrips
[23:16] <poolie> wgrant, was the bug you fixed recently one that can cause
[23:16] <poolie> 'SimpleViewClass from /srv/launchpad.net/production' object has no attribute 'status'
[23:16] <poolie> ?
[23:16] <wgrant> poolie: No, that's a lazr.restful bug.
[23:16] <wgrant> Which I believe is fixed now.
[23:16] <wgrant> poolie: When did you last see that/
[23:16] <poolie> OOPS-1901C853
[23:16] <poolie> overnight, from a cron job
[23:17] <wgrant> poolie: I think that was probably fixed by the first deployment this morning.
[23:17] <wgrant> I've been seeing a few each night too.
[23:17] <wgrant> It's lazr.restful failing to render a timeout error.
[23:18] <poolie> so i should just see if it goes away?
[23:18] <wgrant> Yes.
[23:18] <poolie> no need to file?
[23:18] <poolie> ok
[23:19] <wgrant> Bug 733293
[23:19] <_mup_> Bug #733293: API fails to render timeout errors <api> <qa-ok> <regression> <Launchpad itself:Fix Released by leonardr> <lazr.restful:Fix Released> < https://launchpad.net/bugs/733293 >
[23:19] <poolie> i thought it was familiar
[23:19] <poolie> thanks
[23:21] <poolie> biab
[23:30] <wgrant> lifeless: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1901C2059
[23:30] <wgrant> SQL time: 766 ms
[23:30] <wgrant> Non-sql time: 5938 ms
[23:31] <lifeless> wgrant: yeah, get a profile from qas
[23:31] <lifeless> I suspect its parsing or something similar
[23:31] <wgrant> Ah, forgot we could do that easily now.
[23:56] <lifeless> jml: https://dev.launchpad.net/LEP/ReliableDBDeploys when you have time
[23:56] <lifeless> flacoste: ^
[23:57] <lifeless> whee, http://webnumbr.com/.join(launchpad-oops-bugs.all,launchpad-timeout-bugs.all,launchpad-critical-bugs.all) really has quite a jump doesn't it