[00:01] <lifeless> jam: have you set a commit message?
[00:02] <wgrant> lifeless: Do qastaging OOPSes not sync very often?
[00:02] <lifeless> wgrant: sadly no
[00:03] <lifeless> jam: its on the way
[00:03] <wgrant> :(
[00:04] <jam> lifeless: thanks!
[00:04] <jam> wgrant: if they are in the rsync list, you can get them yourself
[00:05] <jam> rsync tellurium::codehosting-qastaging-logs/ is stuff I used quite a bit
[00:05] <lifeless> jam: the point is to get them into the lp-oops microsite
[00:05] <jam> lifeless: ah, so nicely formatted, rather than just raw oops
[00:05] <jam> sure
[00:05] <lifeless> formatted and analysed
[00:05] <jam> anyway, thanks for the submission, I'm off to have some family time
[00:05] <lifeless> ciao
[00:09] <wgrant> Yeah, lp-oops is far better at formatting and analysing than I.
[00:09] <wgrant> lifeless: Bug 721591
[00:09] <_mup_> Bug #721591: Please make *-backports not automatic starting with Natty <soyuz-publish> <Launchpad itself:New> < https://launchpad.net/bugs/721591 >
[00:09] <wgrant> I am wondering how we should restrict to >= Natty...
[00:09] <wgrant> It's a bit too permanent for FF.
[00:12] <lifeless> its a series thing right ?
[00:13] <wgrant> Yes.
[00:13] <wgrant> We could have a flag on distroseries.
[00:13] <wgrant> But it will probably be on forever.
[00:13] <lifeless> I've marked the bug incomplete
[00:13] <lifeless> it doesn't describe what it needs
[00:13] <wgrant> It does.
[00:14] <wgrant> What is incomplete about it?
[00:14] <lifeless> maybe you understan it
[00:14] <lifeless> but I read the spec
[00:14] <wgrant> The spec says what needs to be done:
[00:14] <lifeless> and it looks like LP doesn't need to change at all, its an APT and synaptic change.
[00:14] <wgrant>  - change soyuz to set NotAutomatic: yes in backports release files
[00:14] <wgrant>  - add "ButAutomaticUpgrades: yes" - don't install automatically, do upgrade automatically
[00:15] <lifeless> then put that in the bug in lp
[00:15]  * wgrant comments.
[00:15] <lifeless> bugs that say 'follow a spec over ->' when that spec is a wall of text, are pretty unapproachable
[00:15] <lifeless> wgrant: fix up the description
[00:15] <lifeless> thats more useful than a comment
[00:16] <wgrant> True.
[00:16] <lifeless> wgrant: so, the way I'd approach this general problem, if doing this greenfield would be:
[00:16] <lifeless> use the prototype pattern
[00:16] <lifeless> setup a 'template' distroseries
[00:16] <lifeless> and have 'make a new distroseries' use the template for that distro
[00:17] <wgrant> We already do that.
[00:17] <lifeless> anyhow, this seems specific to releases of Ubuntu, so its a series specific thing
[00:17] <wgrant> Right.
[00:17] <lifeless> I don't think a flag makes sense, its not 'server config' its data driven config
[00:18] <wgrant> It just seems sort of wasteful to have it as a flag on DS when there is just a single transition.
[00:18] <lifeless> s/flag/featureflag/
[00:18] <wgrant> Right.
[00:18] <lifeless> wekk
[00:18] <lifeless> I'm fine doing it however you like
[00:18] <lifeless> I will note:
[00:19] <lifeless>  - if its a config option somewhere, that implies that users may want to change it
[00:19] <lifeless>  - if they /will not/ or /must not/ then an option is wrong
[00:19] <lifeless>  - feature flags are things we want to change, as is launchpad-lazr.conf
[00:20] <lifeless> this in fact a suite rule note a series rule, now that I'm more awake.
[00:20] <wgrant> But it can't be hardcoded, because it is data-based.
[00:20] <lifeless> sure we can, if we want to hard code it.
[00:20] <wgrant> It can become a suite flag when we model suites.
[00:21] <lifeless> its less flexible, and might be a poor engineering choice to hard code it.
[00:21] <lifeless> but it might be a good choice to hard code it.
[00:27] <lifeless> I relaise that doesn't help you all that much
[00:29] <lifeless> man getCurrentSourceReleases seems a bit inefficient
[00:32] <wgrant> Convoluted, but it doesn't look toooo inefficient.
[00:32] <wgrant> Am I missing something?
[00:37] <lifeless> https://bugs.launchpad.net/launchpad/+bug/636158
[00:37] <_mup_> Bug #636158: BugTask:+index times out with many bug tasks/nominations (eg. Bug #1) <lp-bugs> <pg83> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/636158 >
[00:37] <lifeless> wgrant: its querying the same stuff from distro level then distroseries level according to my casual trace here
[00:39] <wgrant> Oh, completely forgot that it was used by Bugs.
[00:39] <lifeless> per nomination
[00:39] <lifeless> not nomination
[00:39] <lifeless> task
[00:39] <lifeless> anyhow
[00:39] <lifeless> it may be tolerable as a single lookup in a paeg
[00:39] <lifeless> but we're doing a fair few
[00:39] <wgrant> Do you have a modern qas OOPS for that?
[00:39] <wgrant> Oh.
[00:39] <wgrant> Mine has synced now.
[00:39] <lifeless> OOPS-1875D380 is prod yesterday
[00:39] <wgrant> Finally.
[00:40] <wgrant> Yes, but prod isn't fast yet.
[00:40] <wgrant> OOPS-1875QS36
[00:41] <wgrant> Hah.
[00:41] <wgrant> Longest statement is 319 ms. Not bad.
[00:42] <wgrant> Lots of repeated SPN and VPC queries :(
[00:42] <lifeless> yes
[00:42] <lifeless> I'm looking at SPN atm
[00:42] <wgrant> And Person itself.
[00:42] <lifeless> VPC will be some missing/incimplete eager loads
[00:42] <wgrant> Hmm.
[00:43] <wgrant> VPC is eagerloaded.
[00:43] <wgrant> But not completely, yeah.
[00:43] <lifeless> e.g. list(Person query) rather than PersonSet.eagerLoadPersonsByIds
[00:44] <wgrant> I wonder how expensive it would be to record tracebacks for queries.
[00:45] <lifeless> I'd like to do it on demand
[00:46] <lifeless> or when we're down to <50 queries on most pages
[00:46] <lifeless> it is nontrivial cost, but not terrible (unless doing 1000's of times :P)
[00:46] <wgrant> Sure, only on demand.
[00:46] <wgrant> Like ++oops++tracebacks or something like that.
[00:46] <lifeless> but the thing to remember is there is disk overhead in the oops, serialising etc.
[00:46] <lifeless> wgrant: +1
[00:46] <wgrant> Hmm.
[00:46] <wgrant> It's querying for people that don't make it into the final page.
[00:46] <wgrant> That's a bit odd.
[00:46] <lifeless> I would really be fine all the time, once we're down to sensible timeline counts
[00:47] <wgrant> eg the Thai Loco Team.
[00:47] <lifeless> wgrant: owners of messages perhaps
[00:49] <lifeless> we possibly want to turn memcache off too
[00:49] <wgrant> Ohh.
[00:49] <wgrant> I think it's doing the release targetting permission check.
[00:49] <wgrant> These are all product owners.
[00:50] <lifeless> let me guess, thats expressed in python?
[00:50] <wgrant> Of course.
[00:50] <wgrant> It's also buggy.
[00:50] <lifeless> persistence layer should make this -so- much nicer
[00:50] <wgrant> Perhaps the rewrite can fix both.
[00:51] <lifeless> memcache misses for all of it
[00:51] <lifeless> I think we should turn memcache off for this
[00:51] <wgrant> Er.
[00:51] <wgrant> Well, this is on ++oops++, so it is definitely going to miss :)
[00:51] <wgrant> But yes, I think the utility is extremely limited in general.
[00:52] <lifeless> also a few single bug subscroption lookups
[00:53] <lifeless> I bet its per question or something
[00:53] <lifeless> repeated lookups for totem
[00:53] <wgrant> It's nice that we have a pathological test case like this.
[00:53] <lifeless> )
[00:54] <lifeless> it does two __nonzero__ calls on bugwatches
[00:54] <lifeless> thats not cached by the resultset
[00:55] <wgrant> At least __nonzero__ isn't so bad now.
[00:55] <lifeless> depends on the query
[00:55] <lifeless> it may still materialize 50K rows
[00:56] <lifeless> classy
[00:56] <lifeless> we prejoin bugwatch
[00:56] <lifeless> then we directly query bugwatch
[00:56] <lifeless> twice
[00:56] <wgrant> We do similar things in lots of places.
[00:57] <lifeless> thrice
[00:57] <lifeless> and more
[00:57] <lifeless> I wonder if its a per-task check
[00:57] <wgrant>         if check_permission("launchpad.Driver", target):
[00:57] <wgrant> Yay, security adapters.
[00:57] <lifeless> its bracketed by milestone lookups
[00:58] <wgrant> See, tracebacks handy.
[00:58] <lifeless> browser/bugtask.py - line 3163
[00:58] <lifeless> wgrant: of course; I use them all the time ;)
[00:58] <wgrant> Also, LaunchBag needs to die.
[00:59] <wgrant> lifeless: A line number that high is illegal.
[00:59] <lifeless> I might work on redoing oops tools tomorrow
[00:59] <wgrant> On something searchable?
[01:00] <lifeless> theres a few bugs I'd like to address
[01:00] <lifeless> move the format to json
[01:01] <lifeless> make pageid a primary focus for it
[01:01] <lifeless> make it realtime
[01:01] <wgrant> lifeless: The targetting is not actually the expensive bit. It is just normal task attribute permission checks.
[01:01] <wgrant> Yay.
[01:01] <wgrant> Easily cachable.
[01:01] <lifeless> rabbitmq loading of oopses
[01:02] <lifeless> get rid of the on disk store; just keep em in the db
[01:02] <lifeless> [but make it properly searchable as a necessary condition]
[01:03] <lifeless> public project
[01:04] <lifeless> flacoste: I bet you're gone now
[01:09] <jml> I might fix the build tomorrow!
[01:09] <jml> so I can land jam & my branches.
[01:09] <jml> g'night.
[01:09] <wgrant> Night.
[01:11] <lifeless> night
[03:22] <LPCIBot> Yippie, build fixed!
[03:22] <LPCIBot> Project devel build (456): FIXED in 5 hr 22 min: https://hudson.wedontsleep.org/job/devel/456/
[03:22] <LPCIBot> Launchpad Patch Queue Manager: [r=adeuring][no-qa] Fix factory.makePOTMsgSet default sequence.
[05:28] <lifeless> SpamapS: hey
[05:29] <lifeless> SpamapS: if you're around... where is the cassandra stuff, and are there lucid builds
[07:43] <lifeless> jml: around?
[18:43] <lifeless> jml: hai
[23:40] <lifeless> jml: oh hai