[00:03] <sinzui> wgrant: mumble?
[00:10] <LPCIBot> Project windmill-devel build #111: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/111/
[00:33]  * wallyworld shakes fist at unity. check email shortcut has stopped working :-(
[00:37] <thumper> :(
[00:38] <wgrant> Ah! thumper!
[00:38] <wgrant> Why does my launcher not auto-hide now?
[00:38] <wgrant> And then when I start mumble the launcher goes into the background :(
[00:39] <wgrant> It's all your fault.
[00:39]  * thumper shrugs
[01:02] <LPCIBot> Project windmill-devel build #112: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/112/
[01:10] <wgrant> wallyworld: Are you going to be able to do the ML QA?
[01:11] <wallyworld> wgrant: sinzui said he was but it's probably past his EOD now. is the rev on staging yet? that's what the holdup was
[01:13] <wgrant> Ah, a good point.
[01:13] <wgrant> staging is mid-update.
[01:18] <lifeless> so how do you delete a blueprint ?
[01:18] <wgrant> Lalala
[01:18] <lifeless> ah
[01:19] <lifeless> definition obsolete
[01:20] <lifeless> man,
[01:20] <lifeless> some go back a -long- way https://blueprints.launchpad.net/launchpad/+spec/record-bzr-branch
[01:24] <wgrant> Should we garden or just disable the feature for LP?
[01:24] <lifeless> ok I'm officially blind
[01:24] <lifeless> https://blueprints.launchpad.net/launchpad/+spec/ui-roadmap
[01:24] <lifeless> I don't have a particular opinion
[01:24] <lifeless> we're not using it for planning
[01:24] <wgrant> Ahaha
[01:24] <lifeless> LEP + bugs seem to serve us well
[01:25] <wgrant> And that spec is only for Code...
[01:25] <cjohnston> create a blueprint to remove blueprints?
[01:26] <lifeless> noooo
[03:22] <wallyworld_> anyone know if it's possible to dynamically enable/disable the lp rss feed embedded as "<link rel="alternate" type="application/atom+xml" ..."? it seems that once the page loads and the browser has hooked up the rss button, only a page refresh will force an update?
[03:25] <wgrant> I'm not sure it's possible.
[03:25] <wgrant> And it's not going to be relevant for very long.
[03:25] <wallyworld_> ?
[03:25] <wgrant> No modern browser has the button any more.
[03:25] <wallyworld_> ff4 does
[03:25] <wallyworld_> and so does chrome
[03:26] <wgrant> Which Chrome?
[03:26] <wgrant> My Chromium doesn't.
[03:26] <wallyworld_> i'm running the latest google chrome beta
[03:26] <wallyworld_> why you running chromium and not chrome?
[03:26] <wgrant> I also don't see it in Firefox 3.
[03:27] <wgrant> Why would one run Chrome?
[03:27] <wgrant> s/Firefox 3/Firefox 4/
[03:27] <wallyworld_> it may not be visible by default but you can drag the button to your toolbar
[03:27] <wgrant> What benefits does Chrome provide, besides proprietariness and spying?
[03:27] <wgrant> And a PDF reader.
[03:27] <wgrant> Which I have a perfect good implementation of already.
[03:27] <wallyworld_> h.264 i think
[03:27] <persia> That's in chromium
[03:27] <wgrant> My Chromium does H.264.
[03:28] <wallyworld_> i read a while ago what the differences were but have forgotten
[03:28] <wallyworld_> i thought chrome offered something significant but am not sure now
[03:28] <persia> Chrome offers Android support, and chromium doesn't, but that's reaching a bit.
[03:29] <wallyworld_> i think chrome's pdf viewer in inline?
[03:29] <wallyworld_> is
[03:29] <wgrant> I don't understand why you'd want to run the proprietary variant from a company known to be information-hungry, without knowing about significant benefits :(
[03:29] <wgrant> It is, yes. Chrome has a proprietary inline PDF plugin.
[03:29] <wgrant> But I consider that a misfeature.
[03:29] <wallyworld_> that is important to me
[03:30] <persia> Oh, heh.  In January Chrome decided to drop H.264
[03:30] <wallyworld_> if i'm browsing, i hate external apps popping up
[03:30] <wgrant> I like my window manager to manage my windows.
[03:30] <wgrant> Rather than this stupid tabs thing.
[03:30] <persia> Chrome also has it's own built-in implementation of flash.
[03:30] <wallyworld_> you don't like tabbed browsing? i can't live without it
[03:31] <wgrant> wallyworld_: Tabbed applications are a workaround for inadequate window managers.
[03:31] <StevenK> It reminds me of IE embedding in Acrobat Reader, which just makes me twitch.
[03:31] <wgrant> (but I do use browser tabs)
[03:31] <wgrant> (because most contemporary window managers are inadequate)
[03:31] <wallyworld_> we'll have to have a pub discussion about that wgrant. i can't use a browser without tabs :-)
[03:31] <persia> most?
[03:32] <StevenK> Tomorrow, wgrant switches to twm
[03:32] <wgrant> wallyworld_: http://code.google.com/p/chromium/wiki/ChromiumBrowserVsGoogleChrome
[03:32]  * wallyworld_ looks
[03:32] <persia> wallyworld_, This is mostly because you don't have a window manager that makes it easy enough to track things that you don't need to have in-application implementations of window management to be able to cope.
[03:32] <wgrant> Right. If my applications have to manage their own windows, my window manager is not doing it sjob.
[03:32] <wallyworld_> persia: perhaps :-) but i sorta like all my web sessions together in the one window frame
[03:33] <persia> wgrant, On a completely different note, I was pointed to you last week to ask what was required to happen to sbuild in oneiric to not need a separate Soyuz implementation come Querelous Quahog (or whatever)
[03:33] <wgrant> persia: For multiarch?
[03:34] <wgrant> Or just in general?
[03:34] <persia> wallyworld_, Yes, one of the issues with current window managers is that they fail to track whether multiple windows come from the same application and sort it sensibly.
[03:34] <persia> wgrant, In general.
[03:34] <wallyworld_> yes. that applies to more than web browsing too of course
[03:35] <persia> Indeed, which is why there are N implementations of "tabbing" for N applications (which is "doing it wrong")
[03:35] <wallyworld_> sooo, with the rss stuff, i sadly fear i will have to force a page refresh whenever the user using inline ajax widget to change bug or branch privacy values :-(
[03:35] <wgrant> persia: Two hacks are still required: the one to copy DDEBs to ~/public_html (which we can possibly externalise if primary archive ddeb support doesn't get finished by a maintenance squad in the next few months), and the one to return extended status info (depwait/chrootwait/etc.)
[03:35] <wgrant> wallyworld_: That sounds like a major inconvenience for users for such a minor issue.
[03:36] <persia> So the first is easy with a post-build script.
[03:36] <wgrant> Right.
[03:36] <wgrant> The second required something like a 10 line patch.
[03:36] <wgrant> That I've just somewhere along the line.
[03:36] <wgrant> just lost.
[03:36] <wallyworld_> wgrant: yes, agreed :-( but without doing that, the bug is not considered fixed
[03:36] <wgrant> wallyworld_: Why not?
[03:37] <wgrant> wallyworld_: It's little worse than someone having a page open, someone else privatising the bug, and then the first person adding the RSS feed without refreshing.
[03:37] <persia> wgrant, And those should be sufficient?  What was your concern about multiarch?
[03:37] <wallyworld_> because curtis said so :-) plus it's possible to get an rss feed of a private bug if the page was loaded when the bug was public and the privacy changed inline
[03:38] <wgrant> persia: Well, once we have non-closed architectures through multiarch, I suspect we'll need to use an sbuild that has a multiarch-capable resolver.
[03:38] <wgrant> persia: Around a year ago I ported launchpad-buildd to then-current Ubuntu sbuild, and that was all that was required.
[03:38] <persia> distro sbuild (at least in oneiric) no longer uses the internal resolver by default: it defaults to apt.  Would we expect this to be sufficient?
[03:38] <wgrant> But then exams happened, and it bitrotted.
[03:38] <wgrant> I suspect so.
[03:39] <persia> Cool.  How large was the launchpad-buildd porting patch?
[03:43]  * persia found the bitrotten branch and investigates
[03:43] <persia> Thanks a lot for the pointers, and the prior work :)
[03:43] <wallyworld_> wgrant: i've figured out another solution - if they hit the rss button (because it is enabled when it shouldn't be) i'll just redirect back to the bug/branch page and display a notification. that will suffice
[03:45] <wgrant> wallyworld_: How can you know that?
[03:45] <wgrant> Does it request the feed?
[03:45] <wallyworld_> wgrant: yes, it makes a request to feeds.lp.net
[03:45] <wgrant> Hopefully it handles an error/redirect sanely.
[03:45] <wallyworld_> well i'm about to find out
[03:46] <wallyworld_> i don't know if it will work but it seems like the best thing to try and do
[03:46] <wgrant> persia: Apart from deleting sbuild, the diff isn't that bad... let's see.
[03:47] <persia> wgrant, I'm looking at http://bazaar.launchpad.net/~wgrant/launchpad/use-system-sbuild/revision/11151 now : looks smallish.  Needs forward-porting, of course, but it shouldn't be too bad.
[03:47] <wgrant> launchpad-buildd doesn't change much.
[03:47] <wgrant> I wonder if I still have that sbuild diff around somewhere.
[03:47] <wgrant> Otherwise I might try to write it again. It's pretty small.
[03:48] <wgrant> Just returning a different exit code depending on the failure stage.
[03:48] <persia> You left it on LP: http://bazaar.launchpad.net/~wgrant/ubuntu/lucid/sbuild/extended-result/revision/26
[03:48] <wgrant> Hm, the LP diff is only like 140 lines.
[03:48] <wgrant> Oh!
[03:48] <wgrant> I had completely forgotten about that.
[03:48] <wgrant> Thankyou for finding it.
[03:48] <wgrant> That makes things a bit easier.
[03:49] <persia> Yes.  We use distributed version control so that we don't need to use our brains.
[03:49] <wgrant> I was sure I must have had a diff somewhere.
[03:49] <persia> The goal is to acheive productive senescence.
[03:49] <wgrant> Since I had clearly deleted it at some point.
[03:49] <wgrant> I didn't consider I would have pushed a branch.
[03:49] <lifeless> wgrant: some users will use chrome though
[03:50] <persia> (or, to misquote someone, real men don't make backups: they just upload to the internet and other people mirror their code)
[03:53] <lifeless> wallyworld_: there is something I don't understand
[03:53] <lifeless> wallyworld_: why are you worried about the rss feed link; surely the problem is on the feeds page?
[03:54] <lifeless> wallyworld_: or perhaps I misunderstand whats going on here
[03:55] <wgrant> persia: So, I think it all works now except for ddebs.
[03:55] <wgrant> Which should be easy enough.
[04:04] <wgrant> Huh.
[04:04] <wgrant> test_handleStatus_OK_successful_upload just failed on lucid_db_lp too ;(
[04:04] <wgrant> :(
[04:04] <wgrant> Curse you, Twisted.
[04:07] <wgrant> wallyworld_: Looks like staging shoudl have your rev now.
[04:08] <wallyworld_> wgrant: ok. will quickly finish the mp i'm on first
[04:10] <wgrant> wallyworld_: Thanks.
[04:20] <persia> wgrant, You mean "all works now, with the identified patches" or "everything was merged while I wasn't looking except this bit"?
[04:22] <wgrant> persia: Neither of those branches are merged.
[04:22] <wgrant> They both must be.
[04:22] <persia> OK.  I am now unconfused :)
[04:28] <lifeless> mwhudson: what was the confusing bit about team participation / directory service ?
[04:46] <jtv> hi wallyworld_—I'm a bit late today
[04:47] <wallyworld_> jtv: hi, no reviews yet anyway
[04:47] <wallyworld_> but i'm about to finish a mp myself
[04:47] <jtv> then I'll take that
[04:47] <wallyworld_> :-)
[04:48] <jtv> And you can mentor me.  :)
[04:48] <jtv> Whoo, looks like I landed 3 branches overnight.
[04:57] <jtv> We do have a long-running buildbot failure though.
[04:57] <jtv> https://lpbuildbot.canonical.com/builders/lucid_db_lp/builds/966/steps/shell_6/logs/summary
[04:58] <nigelb> good morning
[05:00] <jtv> hello nigelb
[05:01] <nigelb> jcsacket was supposed to re-land this last night, can someone check if its done running through the tests? https://code.launchpad.net/~nigelbabu/launchpad/203478-meeting-sort/+merge/61623
[05:05] <StevenK> If it isn't marked as Merged, it either failed ec2 or failed PQM
[05:05] <nigelb> StevenK: It failed once. I fixed and he said he'd reland
[05:07] <lifeless> mwhudson: I've tweaked, see if its helpful ?
[05:07] <StevenK> nigelb: Did you get a mail from an ec2 instance?
[05:08] <nigelb> StevenK: Not yet. But I'm not sure its 4 hours yet.
[05:08] <nigelb> (Darn, I've had too less sleep :\)
[05:12] <StevenK> Right. Sadly, we can't check
[05:13] <nigelb> StevenK: Ah.
[05:15] <lifeless> sigh
[05:15] <lifeless> for attendance in self.context.attendances:
[05:15] <lifeless>     if attendance.attendee == self.user:
[05:15] <lifeless> whats wrong with this code
[05:15] <wgrant> Heh
[05:16] <lifeless> yes, you can break a sprint by having too many attendees
[05:16] <lifeless> but it will self limit: once we can't late evaluate in the signup form, it won't get worse
[05:19] <lifeless> ah, I lie. that is eager loaded, but still - should be a direct probe.
[05:19] <nigelb> that looks like somewhere around code I touched.
[05:20] <lifeless> Sprint.checkAuthenticated also makes me want to cry.
[05:20] <lifeless> I wonder if thats where the python time really is going
[05:20]  * lifeless hopes not
[05:21] <wgrant> Also I'm not quite sure how that makes sense.
[05:21] <lifeless> qastaging is down ?
[05:21] <wgrant> Working for me...
[05:22] <StevenK> Bwaha
[05:22] <StevenK> Perl 5.14 is out, and Debian/Ubuntu have yet to finish the 5.12 transition.
[05:22] <wgrant> Yup.
[05:25] <wgrant> armel caught up!
[05:25] <wgrant> The build queues are empty for the first time in two months :)
[05:26] <StevenK> Gasp!
[05:26] <persia> Already!  That's fairly early in the cycle.
[05:26] <lifeless> wgrant: check SprintMeetingExportView . initialize
[05:26] <lifeless> wgrant: and the cunning combination of passing domain filters in and in-python filtering.
[05:26] <lifeless> wgrant: I think we have lots of opportunities to make things better here
[05:27] <wgrant> lifeless: Oh, that is looooovely.
[05:28] <lifeless> (note that priority is not-null)
[05:28] <lifeless>     priority = EnumCol(schema=SpecificationPriority, notNull=True
[05:28] <nigelb> Blueprints are slated to go away in the distant future right? Would sprints go away with them?
[05:32] <lifeless> no
[05:32] <lifeless> the functionality is to be kept
[05:32] <lifeless> but the hard to justify split between blueprints and bugs is to go
[05:33] <nigelb> ah, okay.
[05:33] <StevenK> Blueprints and bugs turn into 'issues'
[05:33] <StevenK> Launchpad has issues
[05:33]  * StevenK smirks
[05:33] <wgrant> Yes.
[05:34] <nigelb> Launchpad has *lots* of issues :p
[05:36] <lifeless> hmm, I think we have two 'reload' helpers ><
[05:37] <wgrant> Probably.
[05:47] <lifeless> bulk has one
[05:47] <lifeless> and I think someone added one to testing
[05:47] <lifeless> (a broken one)
[06:38] <lifeless> can has revue ?
[06:40] <jtv> lifeless: wallyworld_'s on call.
[06:41] <lifeless> wallyworld_: oh hai - https://code.launchpad.net/~lifeless/launchpad/bug-784988/+merge/61697
[06:45] <wgrant> lifeless: Lies.
[06:45] <wgrant> lifeless: Lots of those are escalated.
[06:45] <wgrant> Freshly.
[06:45] <wgrant> SO they do not count for the goal that matters :)
[06:46] <StevenK> What was it before?
[06:46] <lifeless> the previous figure was 210
[06:46] <lifeless> wgrant is about to close a bunch
[06:46] <lifeless> and I'll update it then
[06:47] <wgrant> Indeed.
[06:47] <wgrant> Was just opening the page.
[06:48] <wgrant> Fail.
[06:49] <wgrant> Whole lot criticals landed on qastaging half an hour ago :(
[06:49] <lifeless> well, thats my critical for the day up for review
[06:50] <lifeless> see you all monday
[06:50] <wgrant> Night lifeless.
[06:54] <jtv> by lifeless!
[06:54] <jtv> *bye
[06:55] <jtv> StevenK, wgrant: is "<" a total ordering on debversions?
[06:56] <jtv> In other words, if not (x < y) and not (y < x), does that mean they're equal?
[06:56] <wgrant> No.
[06:56] <wgrant> There are some equivalent versions :(
[06:56] <wgrant> well.
[06:57] <jtv> Equivalent ain't so bad I guess; it's unordered version pairs that I'm worried about.
[06:57] <wgrant> Those equivalent debversions will compare identically, but the string representations differ.
[06:57] <jtv> wgrant: I don't think what you just said has any bearing on the question, come to think of it.
[06:57] <wgrant> jtv: Two different versions compare identically.
[06:58] <jtv> Yes, but I'm asking about the case where two versions do not compare as x < y or y < x.
[06:58] <wgrant> It depends what you mean by equal.
[06:58] <jtv> True.
[06:58] <wgrant> They will be equal, but not the same.
[06:59] <jtv> So does this imply that it _is_ possible to have an unresolved DSD where the versions are "equal"?
[07:00] <jtv> Or are the equivalent versions considered equal for all intents and purposes?
[07:00] <wgrant> It depends how the versions are compared.
[07:00] <wgrant> Some parts of Soyuz treat them the same.
[07:00] <wgrant> Some don't.
[07:00] <StevenK> Awww, only 217
[07:00] <jtv> This worries me somewhat.
[07:00] <wgrant> Fortunately such versions are rare.
[07:00] <wgrant> Yes.
[07:00] <wgrant> It causes non-deterministic domination.
[07:00] <wgrant> Which is rather unfortunate, quite unobvious, and entirely unhelpful.
[07:01] <StevenK> wgrant: You know how the versions are compared for DSDs, since we wrote The Plan
[07:01] <wgrant> StevenK: I don't.
[07:01] <wgrant> I know how the base version is calculated.
[07:01] <wgrant> I don't know how you compare the versions.
[07:03] <StevenK> if self.source_version == self.parent_source_version:
[07:03] <wgrant> What are they?
[07:03] <wgrant> debversions or strs?
[07:03] <wgrant> s/strs/unicodes/
[07:04] <StevenK> They are both debversions
[07:04] <wgrant> In Python?
[07:04] <jtv> Do we have a clear definition of the comparison operators for those?
[07:05] <StevenK> wgrant: No, the postgres type
[07:05] <wgrant> Bug #654878, for reference.
[07:05] <_mup_> Bug #654878: Should reject uploads with equivalent versions <boobytrap> <lp-soyuz> <soyuz-upload> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/654878 >
[07:09] <jtv> And is it possible for two versions to have no conclusive ordering at all?  In other words, where not x < y and not y < x but we're also not sure that they're equivalent?
[07:09] <wgrant> NAFAIK
[07:10] <wgrant> I think equivalence is defined here as !(x < y || y < x)
[07:10] <wgrant> Pretty much.
[07:18] <jtv> And people complain about SQL's 3-way logic... it's perfect for this sort of thing!
[07:22] <wgrant> Die, foul demon.
[07:22] <jtv> Come on, would you rather have a false certainty than an honest null?  Face the chasm, discard your illusions!
[07:22] <jtv> Meanwhile, I forget... did +localpackagediffs also show packages that are missing from, or specific to, the derived series?
[07:24] <StevenK> No
[07:24] <StevenK> There are seperate smaller pages for those
[07:25] <jtv> Then my check for "don't offer to sync packages that are newer in the child" doesn't need testing for the one-sided DSDTypes.
[07:26] <LPCIBot> Project windmill-devel build #113: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/113/
[07:41] <LPCIBot> Project db-devel build #565: FAILURE in 5 hr 13 min: https://lpci.wedontsleep.org/job/db-devel/565/
[07:42] <henninge> wgrant: Hi! What's not-pie-critical?
[07:42]  * StevenK smacks lifeless 
[07:42] <StevenK> Stop that!
[07:44] <jtv> wallyworld_: how's your MP coming?  Meanwhile I've got a small one of my own up that you could review (but someone else would have to mentor it, of course): https://code.launchpad.net/~jtv/launchpad/db-bug-783435/+merge/61703
[07:44] <wgrant> lifeless: Such a graph is not of significant value if it can be arbitrarily massively inflated by stakeholders. Newly escalated bugs shouldn't count as part of the tech-debt critical pile, or we will never get anywhere!
[07:45] <wallyworld_> jtv: stupid doc test giving me the shits. i'll look at yours first
[07:45] <jtv> wallyworld_: when in doubt, kill it off.  :)
[07:45] <jtv> The doctest that is, not my MP!
[07:45]  * jtv has seen wallyworld_ with a big scary rifle...
[07:45] <wgrant> (seeing the counter go backwards through no fault of ours is rather demotivating)
[07:46] <wallyworld_> jtv: i'm thinking about it
[07:46] <jtv> uh-oh
[07:59] <wallyworld_> jtv: do distro series packages always have numeric version numbers? like 1.0 1.1 etc?
[08:00] <jtv> wallyworld_: no, they're full Debian version strings such as 0.999c-ubuntu9
[08:00] <jtv> and they have their own comparison operators.
[08:00] <jtv> They may have multiple dots, too.
[08:01] <wgrant> eg. 1:1.2-3~beta2+really1.2-2~rc1+git20110223-2.3ubuntu4.5~hardy1+ppa1
[08:01] <wgrant> Which is depressingly not *that* contrived. :/
[08:01] <wallyworld_> jtv: perhaps the tests could use some version strings other than '1.0' to make that explicitly clear for noobs like me?
[08:02] <jtv> wallyworld_: this seems a bit of an arbitrary place to make that explicit, to be honest—I'd rather that the "oh this one's newer than that one" be instantly clear here.
[08:02] <wallyworld_> jtv: and will a simple < be the correct comparison operator?
[08:02] <jtv> Yes, because it's the most conservative comparison.
[08:03] <jtv> (C++ background helps here :)
[08:03] <wgrant>     parent_source_version = StringCol(dbName='parent_source_version',
[08:03] <wgrant>                                       notNull=False)
[08:04] <wgrant> That's not going to work.
[08:04] <wallyworld_> i know how < works in C++ but wasn't sure if the version strings would always start with a perfix that made sense to compare
[08:05] <wgrant> They may be debversions with a correct < in the DB, but in Python they are just strings.
[08:05] <jtv> I'm thinking not so much about how < works in C++, but how it is used: the less<> template, and its consistent use as the only comparison operator in ordered containers etc.
[08:05] <wgrant> You may want to use apt_pkg.VersionCompare.
[08:05] <wgrant> Or cast them to debversions in Python too.
[08:05] <jtv> wgrant: oh, they're not debversions in memory?
[08:06] <jtv> That's worrisome because I cribbed this from other code.
[08:06] <wgrant> jtv: No, they're normal stringcols.
[08:06] <wgrant> debversion in the DB is very new.
[08:06] <jtv> Or at least, I verified that other code also did straightforward comparisons.
[08:06] <wgrant> jtv: Yes, and lots of code is wrong :)
[08:06]  * jtv trembles with joy
[08:07] <wallyworld_> joy or something else :-)
[08:07] <jtv> wallyworld_: I think I'll try to contrive a test then where a string comparison would give the wrong answer.
[08:07] <nigelb> okay, the merge I was talking about earlier did land successfully :)
[08:07] <wgrant> nigelb: Great!
[08:07] <nigelb> That's 2 bug fixes in a week \o/
[08:08] <wallyworld_> jtv: that would make me happier since i get the impression there's a lot that could go wrong in this area
[08:08]  * wallyworld_ knows way too little about debian packaging :-(
[08:08] <jtv> wallyworld_: it seems there is.  This is where a C++ background is a bad thing because it instills far too much trust in the type system.  :)
[08:08] <wallyworld_> i hear you :-)
[08:09]  * wallyworld_ reboots. stupid unity :-(
[08:09]  * jtv ones worked at a project where a compiler upgrade from 4.x to 5.x revealed that the central object cache lookup had been comparing numeric ids to pointers all along
[08:09] <jtv> *once
[08:09] <jtv> Damn, I've gone dyslexic.
[08:10] <StevenK> Gone?
[08:10] <nigelb> hrm has the topic become stale? I see only 190 critical bugs
[08:11] <wgrant> nigelb: This is over all of launchpad-project.
[08:12] <wgrant> And there are a few private bugs.
[08:12] <wgrant> I see 196 critical bugs in the launchpad project itself.
[08:12] <wgrant> 214 bugs, 217 bugtasks in launchpad-project overall.
[08:13] <nigelb> ah
[08:13] <nigelb> I see 208 critical bugs now
[08:13] <nigelb> I'm curious, why is bug 500015 critcal?
[08:13] <_mup_> Bug #500015: IE js error in filebug <dhrb> <ie> <javascript> <lp-bugs> <oem-services> <story-ajaxify-dupe-finder> <Launchpad itself:Triaged> < https://launchpad.net/bugs/500015 >
[08:14] <wgrant> nigelb: It's a JS exception that would be an OOPS if we had a JS OOPS system.
[08:14] <nigelb> Ah.
[08:14] <wgrant> So it is an honorary beneficiary of ZOP.
[08:14] <nigelb> any more easy critical bugs left? ;)
[08:15] <wgrant> You could look for critical bugs tagged easy or trivial.
[08:15] <lifeless> wgrant: we don't accept all escalations, so its not arbitrarily inflated
[08:15] <wgrant> sinzui tagged a few earlier in the week, but most have since been squashed.
[08:15] <wgrant> lifeless: It is uncontrollable reversal of the countdown.
[08:15] <wgrant> That is silly.
[08:16] <lifeless> anyhow, my issue is much more pragmatic
[08:17] <wgrant> We're just about always going to have *something* in the critical queue. I think the burndown should track the backlog.
[08:17] <lifeless> I don't have a query to get the 'right' count (whatever that may be defined as - and I don't want to debate it right now - family time) with any reasonable ease
[08:17] <wgrant> Or what's the point?
[08:17] <wgrant> Perhaps.
[08:17] <lifeless> theres a few factors and we should talk about it more on Monday
[08:17] <lifeless> gotta run
[08:17] <wgrant> Night!
[08:18] <jtv> bye again lifeless
[08:20] <nigelb> is it just me or is the wording in bug 659184 complicated?
[08:20] <_mup_> Bug #659184: IntegrityError: duplicate key value violates unique constraint "ticketmessage_message_ticket_uniq <email> <lp-answers> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/659184 >
[08:20] <nigelb> I can't make head or tail of what's said there.
[08:21] <wgrant> It's also a duplicate.
[08:21] <wgrant> I understand what's going on there, but is it easier if you read the dupe?
[08:21] <wgrant> s/dupe/master/
[08:22] <nigelb> okay
[08:23] <nigelb> heh, the master has copy paste of what's said in the dup :p
[08:23] <wgrant> Bah.
[08:23] <wgrant> Well.
[08:24] <wgrant> MessageSet.fromEmail looks up the message ID and content, and checks if there's an existing identical Message in the DB.
[08:24] <wgrant> If there is, it just links it in as a comment (with a BugMessage or QuestionMessage) rather than creating a new Message object and linking that.
[08:25] <wgrant> But there is a UNIQUE constriant on BugMessage(bug, message) and QuestionMessage(question, message).
[08:25] <wgrant> If it receives an identical email twice to the same bug or question, it will try to link the same Message twice, and run afoul of that constraint.
[08:25] <nigelb> and the solution is?
[08:27] <wgrant> Possibly just ignoring a second attempt to link a message to a bug.
[08:29] <nigelb> this needs more read of code that I'm capable right now.
[08:29] <nigelb> will read at home.
[08:40] <adeuring> good morning
[08:41] <StevenK> wgrant: What's fiera used for?
[08:41] <StevenK> I can't recall
[08:41] <jtv> wallyworld_: having some lock problems with that branch.  Hope to have an updated diff in a few minutes.
[08:42] <wgrant> StevenK: It's buildd-manager.
[08:42] <wallyworld_> jtv: ok. i just got my tests passing so will finish the mp. but i may have to cook dinner first
[08:42] <jtv> OK
[08:43] <StevenK> Ah
[08:44] <StevenK> wgrant: Perhaps it needs to go the way of the lucille DB user :-)
[08:44] <wgrant> StevenK: Indeed, but I broke production for a few minutes with that one, so I am a bit more wary now.
[08:44] <StevenK> Whee
[08:46] <StevenK> wgrant: Wait, with lucille or fiera?
[08:46] <wgrant> StevenK: lucille
[08:46] <jtv> wallyworld_: diff has updated.
[08:46] <StevenK> wgrant: Clearly she didn't want to die
[08:47] <LPCIBot> Project windmill-devel build #114: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/114/
[08:47] <wallyworld_> jtv: ack. will look after cooking. just typing up mp and will light the bbq after hitting submit :-)
[08:47] <jtv> wallyworld_: by all means don't multitask while lighting stuff on fire.  :)
[08:48] <StevenK> Unless it's Soyuz code
[08:49] <jtv> No, even then.
[08:55] <nigelb> heh
[08:57] <mrevell> Hello
[10:00] <bigjools> stub: can I have a db patch number please?
[10:01] <stub> 2208-72-0. Can you give me a two word description for my notes?
[10:02] <bigjools> stub: ta. converting textual version columns in DistroSeriesDifference into debversion types
[10:03] <stub> ta
[10:06] <bigjools> stub: sorry, scratch that.  jtv told me porkies, they are already debversions...
[10:06] <wgrant> It's in Python that they're just strings.
[10:06] <bigjools> yes
[10:07] <jtv> I managed to get different results from DSD.source_version < DSD.parent_source_version than from Version(DSD.source_version) < Version(DSD.parent_source_version).
[10:07] <wgrant> Sure.
[10:07] <wgrant> In the DB they are debversions.
[10:08] <wgrant> But they come back Python as normal strings.
[10:09] <bigjools> apt_pkg.VersionCompare is what we need
[10:09] <jtv> Anybody willing to mentor wallyworld_'s review?  I've got a conflict of interest on this one: https://code.launchpad.net/~jtv/launchpad/db-bug-783435/+merge/61703
[10:09] <jtv> (Thanks Ian)
[10:10] <jtv> bigjools: if it gets this subtle, I'd definitely like to have a DSD.child_is_newer or something along those lines.
[10:10] <bigjools> jtv: +1
[10:10]  * jtv has to be off now
[10:10] <bigjools> thanks jtv
[10:11] <jtv> wallyworld_: won't be able to finish that review now... mind if I put it off?
[10:11] <stub> Consider adding a psycopg2 type conversion hook to give you some sort of version object instead of a string. I think documentation may even exist now!
[10:12] <jtv> bigjools: I think you've got enough new work to keep you happy for a bit.  :)  I can pick it up Monday, but also won't be offended if you grab another reviewer.
[10:13] <bigjools> jtv: well approve with changes recommended? :)
[10:13] <jtv> OKOKOK
[10:15] <jtv> Good weekend everyone!
[10:16] <bigjools> StormBase classes have @cachedproperty invalidation working, right?
[10:16] <bigjools> ah yes
[11:18] <gmb> danilos: Does the test failure for the latest build make any sense to you? It looks like a translations thing but it could just be noise as far as I know: https://lpbuildbot.canonical.com/builders/lucid_lp/builds/965/steps/shell_6/logs/summary
[11:18] <danilos> gmb, looking
[11:19] <gmb> Ta
[11:19] <danilos> gmb, that's not a translation test (test_handleStatus_OK_successful_upload in test_sourcepackagerecipebuild)
[11:20] <danilos> gmb, translation tests do spit out some nonsense there which seems not to be parsed out by the test handler
[11:20] <gmb> danilos: Ah, right. I was seeing all the references to lp.translations and reaching the wrong conclusion. Okay, thanks.
[11:21] <wgrant> gmb, danilos: That's failed twice on lucid_lp and once on lucid_db_lp today. poolie touched it a few days ago; you may want to disable it for now.
[11:22] <wgrant> Or work out why it's not working.
[11:22] <gmb> wgrant: I'll try (2) but I suspect (1) is what I'll end up doing.
[11:22] <gmb> Looking now.
[11:22] <rvba> stub: Hi! Could you please review this db-patch when you get a chance: https://code.launchpad.net/~rvb/launchpad/dsp-order/+merge/61727
[11:22] <rvba> stub: I'm very sorry to submit these db patches bits by bits like this ... but I confess I am figuring this whole thing bits by bits as well ;).
[11:23] <wgrant> gmb: It's not reproducible locally.
[11:23] <wgrant> gmb: At least not when run in isolation.
[11:23] <wgrant> gmb: It may be using a constant path that has been polluted on the slaves.
[11:23] <gmb> wgrant: Ah, okay. Disabling seems sane then.
[11:23] <gmb> For now at least.
[11:23]  * gmb goes to work
[11:23] <wgrant> :( more Criticals :(
[11:24] <wgrant> Thanks.
[11:24] <gmb> wgrant: Less pie for Jono.
[11:24] <bigjools> Jono is not allowed to file Critical bugs :)
[11:26] <gmb> :)
[11:30] <stub> rvba: looking
[11:32] <poolie> nigelb: congratulations on your landing!
[11:33] <rvba> stub: Julian suggested to change the index to "btree(derived_series, ordering)"
[11:43] <stub> rvba: Yes, that will be better. If you list the columns in that order, the index still allows fast lookups just by id.
[11:43]  * gmb -> early lunch
[11:43] <stub> rvba: The existing index can also be used to lookup rows just by derived_series (no ordering), but it is slower.
[11:44] <rvba> stub: Just pushed the correction. Not sure I understand how this index affects lookups by id. Would you care to explain it to me?
[11:45] <stub> This index does not affect lookups by id. Lookups by id will use the implicit index created for the primary key (distroseriesparent_pkey)
[11:46] <stub> I'm talking about a query like 'SELECT * FROM DistroSeriesParent WHERE derived_series=42 ORDER BY ordering'.
[11:47] <rvba> Ah ok, I get it now.
[11:48] <stub> (I suspect we won't use the index at all because I doubt there will be more than half a dozen parent series)
[11:48] <nigelb> poolie: Thanks!
[11:49] <rvba> stub: I suppose you are right ... but God knows what OEM will do with this (I'm paraphrasing Julian here).
[11:49] <poolie> nigelb, there was another one recently touched which is vaguely similar
[11:50] <poolie> which is just to have a "delete this project" button that takes you to a help page explaining you should open a support request
[11:50] <poolie> or i guess that's also a bit like what mrevell did recently
[11:50] <stub> rvba: We keep the new index though, because it *might* be useful and it makes another one redundant, so we don't lose much space or write performance.
[11:50] <nigelb> poolie: I saw that bug last night when looking for next candidate
[11:52] <rvba> statik: Understood. Thanks a lot for your explanation.
[11:53] <rvba> oops ... s/statik/stub/
[11:53] <stub> approved
[11:54] <cjohnston> henninge: https://code.launchpad.net/~chrisjohnston/launchpad/197793/+merge/61053
[11:55] <henninge> cjohnston: would you like me to land that? (Although I thought somebody was already doing that)
[11:55] <cjohnston> I don't think anyone has gotten to that one.... If you would that'd be great.
[11:57] <henninge> cjohnston: what about this one? https://code.launchpad.net/~chrisjohnston/launchpad/483373/+merge/61042
[11:57] <henninge> cjohnston: it just needs one line.
[11:57] <henninge> icon='edit'
[11:58] <bigjools> wgrant: can you think of anything clever we can do to make >, < and = DTRT on versions, without having to remember apt_pkg?
[12:01] <stub> bigjools: Storm column type. Even register the type with psycopg2 to get a custom object for non storm code.
[12:01] <cjohnston> henninge: done.. sorry.. been a busy week
[12:01] <bigjools> yeah we'd at least need a new type so we can define operators
[12:03] <henninge> cjohnston: ok, cool. I'll do that after lunch.
[12:03] <cjohnston> :-
[12:03] <cjohnston> )
[12:06] <stub> bigjools: Looks like you define a variable, per storm/variables.py and a SimpleProperty per storm/properties.py - both look pretty trivial actually. And your custom class defining __str__ and __cmp__ and friends of course.
[12:12] <bigjools> stub: coolio
[12:19] <stub> rvba: Just added a fresh column to that MP. I believe the new index should be UNIQUE
[12:22] <stub> rvba: Except that will make reordering a pain in the bum I guess.
[12:23] <rvba> stub: makes sense ... I must say I hesitated to make the index unique. Reordering is exactly the reason why I decided not to do it :).
[12:23] <bigjools> make the default 10
[12:23] <bigjools> should then be obvious how to re-order :)
[12:23] <stub> rvba: Yer. Maybe we should keep it the way it is for practicality.
[12:24] <rvba> stub: agreed.
[12:25] <rvba> stub: Besides, the reordering will be done in a fancy js UI. It will be tricky (but possible) to manage transaction from there.
[12:25] <rvba> s/transaction/transactions/
[12:26] <stub> You still need to swap two rows using a temporary value since you can't defer the UNIQUE check until the transaction end.
[12:27] <rvba> stub: Good point. I'll be careful when doing the js part..
[12:29] <lifeless> rvba: you are -so- not going to manage transactions from js.
[12:29] <rvba> lifeless: sure, I'll do the reordering thing inside a view.
[12:29] <lifeless> rvba: perhaps you mean something very different to what it reads as.
[12:29] <lifeless> rvba: much saner :)
[12:30] <rvba> lifeless: ;)
[12:32] <lifeless> *yawn* night all
[12:35] <rvba> lifeless: good night.
[13:07] <bac> morning adeuring
[13:07] <adeuring> morning bac!
[13:08] <LPCIBot> Project windmill-db-devel build #298: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-db-devel/298/
[13:24] <LPCIBot> Project windmill-devel build #115: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/115/
[13:42] <bigjools> I get so excited when I see lots of red in a merge proposal diff
[13:43]  * jml too
[13:56] <nigelb> hehe
[14:16] <LPCIBot> Yippie, build fixed!
[14:16] <LPCIBot> Project db-devel build #566: FIXED in 5 hr 15 min: https://lpci.wedontsleep.org/job/db-devel/566/
[14:49] <adeuring> bac: could you please review this mp: https://code.launchpad.net/~adeuring/launchpad/bug-739065-2/+merge/61768 ?
[14:50] <bac> adeuring: yes, i'll get right on it
[14:50] <adeuring> bac: great, thanks!
[14:57] <bac> adeuring: do you really need to specify the main store or should you use the store of the object?
[14:58] <adeuring> bac: right, I can use Store.of(self.distroseries)
[14:58] <adeuring> (self itself is not a Storm object)
[14:58] <adeuring> erm, DistroSeriesSourcePackageRelease is not a storm object
[15:04] <bac> flacoste: you're probably unaware but you're sending out html email again with a tiny font
[15:04] <flacoste> bac: shit, thanks for telling me
[15:05]  * flacoste curses kmali
[15:05]  * bac puts his glasses away
[15:08] <adeuring> bac: thanks for the review!
[15:09] <bac> np
[15:30] <deryck> flacoste, Aren't security bugs always marked critical?
[15:31] <flacoste> deryck: i think they should yeah
[15:32] <deryck> flacoste, should I update the BugTriage wiki page then?
[15:32] <flacoste> deryck: yes, please
[15:33] <deryck> ok, will do.
[15:48] <danilos> adeuring, bac: anyone got time to take on https://code.launchpad.net/~danilo/launchpad/bug-772763-remove-unmute-dialog-part1/+merge/61775?
[15:48] <adeuring> danilos: sure, I'll look
[15:48] <danilos> adeuring, thanks
[15:51] <danilos> adeuring, let me know if you've got any questions
[16:11] <adeuring> danilos: the last line in test_bug_mute_self_view_unmutes_bug() looks odd: self.assertTrue(self.bug.isMuted(self.person)) Since the bug is unmuted, shouldn't this be assertFalse()? Or am I simply confused?
[16:11] <danilos> bac, I know you're jealous that adeuring picked that one up first, so I've prepared one for you as well: https://code.launchpad.net/~danilo/launchpad/bug-772763-remove-unmute-dialog/+merge/61780 :P
[16:12] <bac> danilos: :)
[16:12] <bac> be glad to look at it
[16:12] <danilos> adeuring, checking
[16:14] <danilos> adeuring, the create_initialized_view actually submits the form
[16:14] <danilos> bac, thanks
[16:15] <adeuring> danilos: yes, but that's an unmute operation, right? So, afterwards, the bug shoulld be unmuted, I think
[16:15] <danilos> adeuring, good point, let me check
[16:18] <danilos> adeuring, indeed, you've found a buggy test, thanks; the form action should be "field.actions.unmute", not "field.actions.mute"
[16:18] <adeuring> danilos: ahh, I missed this detail ;)
[16:19] <danilos> adeuring, incremental diff: https://pastebin.canonical.com/47682/
[16:19] <danilos> adeuring, not at all, you've seen an inconsistency :)
[16:20] <adeuring> danilos: in line 250 of the diff, you mention a bug. Isn't this worth an XXX?
[16:21] <danilos> adeuring, I believe that's not "my" code, that bug is in progress (landed then reverted)
[16:22] <danilos> adeuring, the reversion caused the issues, I'll remove that from my branch
[16:22] <adeuring> danilos: ah, ok.
[16:28] <adeuring> danilos: r=me. thanks for the additional change!
[16:28] <danilos> adeuring, thanks, very much appreciated!
[16:30] <jcsackett> henninge: i'm looking at bug 504062, about the "used in" link for deactivated templates. the oops for it is no longer there, so i was wondering if you could point me to where this error actually occurs?
[16:30] <_mup_> Bug #504062: External suggestion "used in" links to disabled template <404> <lp-translations> <oops> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/504062 >
[16:31] <danilos> bac, I'll be running out in a few, since it's basically gary_poster's branch, I am sure you can defer to him for the questions as well; I hope you don't mind me not really being around for the OCR, and if you do, I apologize!
[16:48] <bac> np, danilos
[16:54] <LPCIBot> Project windmill-db-devel build #299: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-db-devel/299/
[16:58] <bac> just used my newly minted powers to hide bug comment spam.  felt good.  thanks green squad!
[17:04] <jcsackett> bac: You're welcome!
[17:29] <poolie> mrevell: still here?
[17:30] <mrevell> Hello poolie
[17:31] <poolie> i was just contemplating a blog post to celebrate the landings from nigelb, and um charles
[17:31] <nigelb> poolie: chris?
[17:31] <poolie> sorry, chris
[17:31] <nigelb> heh
[17:32] <poolie> chris is the other non-core contributor who got patches in this week
[17:32] <poolie> oh i see
[17:32] <mrevell> poolie, If you have something in mind already I think that would make a great blog post. If you're not offering to write it then I can do so next week.
[17:33] <poolie> :) i might
[17:33] <poolie> it is somehow easier to write praise of projcets other than your own
[17:33] <mrevell> :)
[18:08] <bigjools> night folks, have a good weekend
[18:11] <poolie> nigelb: was that in fact your first landing?
[18:13] <nigelb> poolie: which one?
[18:14] <nigelb> poolie: I've had 2 landings so far, one I believe is already in production, one I just qa'd on qastaging
[18:16] <bac> nigelb: nice blog post about your initial lp work!
[18:16] <nigelb> bac: :)
[18:21] <nigelb> bac: Not sure if you remember, but I think I sat next to you for the opening keynote :p
[18:22] <nigelb> (it just clicked how your nick was familiar)
[18:22] <bac> nigelb: ah yes.  you, me, jane i believe
[18:22] <nigelb> yup :)
[18:22] <bac> was nice to meet you
[18:22] <nigelb> you too :)
[18:39] <nigelb> Bah, this isn't right.
[18:40] <nigelb> Meeting attendees should be sorted by display name https://bugs.edge.launchpad.net/bugs/203478 You received this bug notification because you are a bug assignee.
[18:40] <_mup_> Bug #203478: Meeting attendees should be sorted by display name <easy> <lp-blueprints> <qa-ok> <sprints> <ui> <Launchpad itself:Fix Committed by nigelbabu> < https://launchpad.net/bugs/203478 >
[18:40] <nigelb> Got this in my mail.  shouldn't the edge link be deprecated?
[18:49] <sinzui> Edge is deprecated.Users are accessing it via bookmarks and offsite links. We will shut it off in a few weeks
[18:51] <nigelb> sinzui: I got a link to edge in my mail
[18:52] <sinzui> Because someone used edge. Mail came from that server
[18:52] <nigelb> PQM!
[18:52] <sinzui> No, more likely the tagging api script
[18:53] <sinzui> PQM does not know about any website
[18:54] <nigelb> sinzui: "Launchpad QA Bot (lpqabot)" is what assigned the bug to me
[18:55] <sinzui> yep, Ursinha-afk  lpqabot will break when we turn edge off
[19:11] <nigelb> sinzui: heh, I thought it was a bug I could fix
[19:14] <sinzui> nigelb: there is not a formal definition of trivial verses easy, but many of use mean trivial is fixable in an hour and may not need a test. easy means fixable in a day
[19:16] <nigelb> sinzui: aha, I've been fixing the easy ones, I didn't know trivial were easier than that ;)
[19:17] <sinzui> When I start a bug that is labeled trivial, but realise it is not, I stop work and update the bug about why the work is more complicated
[19:28] <LPCIBot> Project windmill-db-devel build #300: STILL FAILING in 47 min: https://lpci.wedontsleep.org/job/windmill-db-devel/300/
[19:48] <LPCIBot> Project devel build #739: FAILURE in 20 min: https://lpci.wedontsleep.org/job/devel/739/
[20:28] <jcsackett> sinzui: i'm looking at bug 252172, but i'm not sure it's entirely accurate anymore. i don't see any control as described in the bug.
[20:28] <_mup_> Bug #252172: Changing a branch's status/privacy isn't obvious <confusing-ui> <disclosure> <easy-ui> <privacy> <Launchpad itself:Triaged> < https://launchpad.net/bugs/252172 >
[20:29] <UrsulaJ> sinzui, why is that? (lpqabot break when we turn edge off)
[20:29] <jcsackett> UrsulaJ: i believe sinzui determined that qatagger was using edge based links.
[20:29] <jcsackett> see nigelb's comments above.
[20:30] <sinzui> UrsulaJ: As reported in the scrollback, nigelb got email from edge. A person or a bot used edge to update the bug. It looks like the bot
[20:30] <UrsulaJ> hm, qatagger doesn't send email
[20:30] <UrsulaJ> it might be using edge api instance
[20:30] <sinzui> No, it updates a bug, then the server sees the update and sends an email
[20:31] <UrsulaJ> sinzui, edge api is the problem then
[20:31] <sinzui> If it is not used edge api, then all is goof
[20:31]  * UrsulaJ goes fix
[21:59] <nigelb> ahoy
[22:00] <nigelb> can someone help me figure out where is the painpoint to fix bug 90628?
[22:00] <_mup_> Bug #90628: Subscribers to a spec are randomly arranged <easy> <lp-blueprints> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/90628 >
[22:00] <nigelb> I've been looking at the source for an hour or so and I'm still lostt
[22:00] <nigelb> *lost
[22:09]  * sinzui looks
[22:09] <sinzui> nigelb: is that still true?
[22:10] <nigelb> sinzui: being lost? yes
[22:10] <sinzui> we do not sort the subscribers by displayname?
[22:10] <nigelb> nope, not on BPs
[22:10] <nigelb> https://blueprints.launchpad.net/loco-directory/+spec/community-o-loco-directory
[22:10] <nigelb> its sorted by order subscribed.
[22:10] <sinzui> excellent.
[22:11] <nigelb> and I just noticed another bug, where if you subscribe a team, LP thinks the person is invalid.
[22:11]  * sinzui looks for SpecificationSubscription, or something like that
[22:14] <sinzui> nigelb: um, I have a nasty suspicion that there is no code to manage this, so that is why we see order by db id. We might be able to define an order in the Specification Model, or we want to create a property to get them ordered.
[22:14]  * sinzui looks further
[22:15] <nigelb> sinzui: that's what I felt too.  take a look at subscriptionnavigation
[22:15] <nigelb> erm
[22:15] <nigelb> SpecificationNavigation rather
[22:16] <sinzui> nigelb: Things are not that bad. I am looking at line 184 in model/specification.py
[22:16] <nigelb> *whee*
[22:17] <sinzui> There is subscriptions and subscribers. The former is by id, the later is right
[22:17] <sinzui> The portlet must be using the first one
[22:17] <sinzui> well I hope it is
[22:18] <nigelb> yeah, it is
[22:18] <nigelb> I saw that bit in the template and I couldn't figure where it was getting that
[22:18] <sinzui> I wonder if it does that because it wants to know something about the subscription and not the person
[22:19] <sinzui> That markup is nasty
[22:19] <sinzui> It dates from the Lp beta I think.
[22:19] <sinzui> lets see if we can make subscriptions ordered
[22:21] <nigelb> okay!
[22:27] <sinzui> This is ancient code. This is a pretty easy query to construct in storm, but I have not worked with this SQLObject code in a long time. I think we need to change the subscriptions attribute from a MultiJoin to a property that returns the subscription (and precaches the person)
[22:27]  * sinzui looks up SQLMultipleJoin
[22:27] <lifeless> sinzui: hi
[22:27] <sinzui> hi lifeless
[22:28] <lifeless> sinzui: precaching the persons on subscription?
[22:28] <lifeless> sinzui: will interact with https://code.launchpad.net/~lifeless/launchpad/bug-784988/+merge/61697 which is playing in ec2 now
[22:28] <sinzui> the person because we need the subscriptions
[22:29] <lifeless> if you're going to show all the people anyway, sorting in python is ok
[22:29] <lifeless> if you're not, then sorting in the db is definitely preferred
[22:30] <nigelb> sinzui: do you want me to look at how sprint attendees in sprint and try and reuse that code here?
[22:30] <nigelb> *sprint functions
[22:30] <lifeless> sinzui: the interaction I'm thinking of is that we don't want to eager-load the people twice - once per spec, and once for the entire group
[22:30] <sinzui> nigelb: I think you need to delay working on this since the code is different. I do not see how Specification gets a .subscriptions attr now
[22:30] <lifeless> sinzui: shouldn't be hard to avoid
[22:30] <nigelb> sinzui: wait for Monday? :)
[22:32] <lifeless> sinzui: you mean that _subscriptions is a multi join, but there is no 'subscriptions' property-or-join?
[22:32] <sinzui> lifeless: how did you *not* break specification-portlet-subscribers. It is referencing that attr on Specification
[22:32] <lifeless> sinzui: I may have, ec2 will tell me.
[22:33] <lifeless> hah, that was not meant to be committed
[22:33] <lifeless> I was going to add a cachedproperty there
[22:33]  * lifeless backs that out promptly :)
[22:34] <nigelb> heh
[22:34] <nigelb> sinzui: I'll head to bed now then, and be back Monday/Tuesday to tackle this again :)
[22:34] <sinzui> goodnight nigelb
[22:35] <lifeless> sinzui: thanks for noticing that
[22:35] <nigelb> night sinzui, thanks for looking into this :)
[22:35] <sinzui> np, It is nice that we talk about these things before the code is commited
[23:36] <LPCIBot> Project windmill-devel build #116: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/116/