[00:04] <thumper> mwhudson: it seems to me that the submit branch and email should be extracted correctly without any extra setup by me...
[00:05] <mwhudson> thumper: where from?  they're currently set by locations.conf for local paths
[00:05] <thumper> nope
[00:05] <thumper> hmm
[00:05] <mwhudson> so if the path is some launchpad url...
[00:05] <mwhudson> can you put a regex in locations.conf?
[00:06] <thumper> don't know
[00:06] <mwhudson> you could probably set something up to work magically, but you're unlikely to have it set up now
[00:07] <thumper> is it  --pqm-public-location that I need
[00:07] <thumper> I'm finding the help not helpful with this respect
[00:07] <mwhudson> no, not that
[00:07] <mwhudson> --pqm-submit-location
[00:08] <mwhudson> oh, maybe you don't need that actually
[00:08] <thumper> mwhudson: it says it should default to devel
[00:08] <mwhudson> thumper: right
[00:08] <mwhudson> maybe it's just the submit address you need to set?
[00:09] <thumper> there isn't an option for that :(
[00:13] <mwhudson> yeah
[00:14] <mwhudson> i guess you can set it in the global config while you run the command>
[00:14] <mwhudson> ?
[00:14] <mwhudson> and file a bug
[00:14] <thumper> hmm
[00:24] <thumper> mwhudson: I hacked ec2test :)
[00:24] <thumper> mwhudson: I should submit the fix
[00:24] <mwhudson> hehe
[00:24] <mwhudson> yeah
[00:25] <thumper> spm: it seemed that the email for devel r8980 didn't get sent out
[00:26] <thumper> spm: around to help chase?
[00:26] <spm> thumper: hmmm. not good - I assume you're suggesting the branch scanner? or?
[00:26] <thumper> spm: no, it *should* be in the logs for the revision mailer
[00:27] <spm> 'k, looking
[00:27] <thumper> I can't remember where that job runs
[00:27] <thumper> probably on the same machine as the scanner
[00:27] <mwhudson> loganberry i think
[00:27] <thumper> maybe
[00:27] <thumper> syncing the logs with devpad would be a start
[00:29] <thumper> spm: sendbranchmail on loganberry
[00:29] <thumper> spm: srv/launchpad.net-logs/scripts/loganberry-bzrsyncd is where it goes
[00:30] <spm> thumper: yeah, that log is not terribly helpful for informing on if a specific XYZ worked tho :-(
[00:31] <thumper> :(
[00:31] <thumper> ok, db queries here we come
[00:31] <spm> is syncing atm...
[00:31] <spm> fwiw
[00:31] <mwhudson> look for oopses too?
[00:33] <spm> gah. going blind. didn't notice the diff between sendbranchmail.log & the dir sendbranchmail
[00:34] <spm> mwhudson: thumper: https://pastebin.canonical.com/20506/
[00:35] <thumper> spm: ah
[00:35] <thumper> spm: this is the fix that abentley has landed
[00:35] <thumper> spm: we should look to get that cherry picked somehow
[00:35] <thumper> yay for fixes already landed :)
[00:35] <spm> heh
[00:38]  * thumper afk to get Maia
[02:01] <mwhudson> lunchtime
[03:19] <thumper> for an api write operation does the changed object get streamed back to the launchpadlib client?
[03:20] <thumper> also, is the vocabulary checked?
[03:20] <thumper> hmm...
[03:21] <wgrant> A Choice argument is checked server-side.
[03:21] <wgrant> And client-side in really new launchpadlibs.
[03:21] <wgrant> And IIRC the object does get given back in response to a PATCH, but I'm not sure why you care.
[03:22] <thumper> wgrant: IBranch.setOwner
[03:22] <thumper> wgrant: changes the state of the branch
[03:23] <thumper> wgrant: and possibly the branch name if there is a clash
[03:23] <wgrant> Oh dear.
[03:23] <wgrant> That's awkward.
[03:23] <thumper> wgrant: I'm wondering what gets sent back to the client
[03:23] <thumper> ideally I'd like it to just work
[03:23] <wgrant> It should.
[03:24] <wgrant> Because launchpadlib just looks at self_link to work out the name.
[03:24]  * thumper looks in registry/interfaces/person.py
[03:25] <wgrant> I know one good way to find out.
[03:27] <thumper> wgrant: which is?
[03:28]  * thumper broke buildbot
[03:28] <wgrant> thumper: Use launchpadlib on launchpad.dev.
[03:28]  * thumper broke the build, not buildbot
[03:28] <wgrant> buildbot doesn't seem to need people to break it.
[03:28] <thumper> heh
[03:35] <mwhudson> thumper: a http redirect gets sent back if the url has changed, i think
[03:35] <thumper> mwhudson: hmm...
[03:36] <mwhudson> yeah
[03:36] <thumper> mwhudson: http://pastebin.ubuntu.com/235582/
[03:36] <thumper> mwhudson: for my testfix :(
[03:37] <mwhudson> lazr.restful/src/lazr/restful/_resource.py:1099 and tharabouts
[03:37] <thumper> mwhudson: what is the meaning to the client though?
[03:37] <mwhudson> thumper: r=me with a side of 'ya doctests'
[03:37] <mwhudson> thumper: it will go to the new url and presumably get the new version of the object
[03:37] <mwhudson> i guess
[03:37]  * thumper hopes
[03:37] <mwhudson> i dunno, like wgrant says, try it, i guess
[03:38] <mwhudson> thumper: in some sense, it's not so different to any other modifying operation, is it?
[03:38] <thumper> mwhudson: well... this one will change the canonical_url of the branch
[03:39] <mwhudson> thumper: oh right
[03:41] <thumper> mwhudson: generate_entry_adapter -- hmm, I wonder if lazr is gaining adapters
[03:42] <mwhudson> there are certainly adapters all over
[03:42] <mwhudson> thumper: about your testfix, are you sure that that's the only test that is broken?
[03:45] <thumper> yes
[03:45] <mwhudson> cool
[03:45] <thumper> almost
[03:45] <thumper> pretty sure
[03:45] <thumper> 99.9%
[03:45] <thumper> can I pqm-submit a branch on LP without a local copy?
[03:52] <mwhudson> you can write the submit mail by hand i guess
[03:52] <mwhudson> bzr pqm-submit --dry-run in some other branch, copy paste into email client, change, send
[03:57] <mwhudson> spm: you'd think in the 1hr10 since i pinged you, i could have written the queries :)
[03:57] <mwhudson> but no
[03:57] <thumper> oh the irony
[03:57] <thumper> bzr branch lp:hg-git
[03:58] <thumper> I just approved the import
[03:58] <spm> mwhudson: heh. "no comment"
[03:59] <mwhudson> spm: select distinct 'https://code.edge.launchpad.net/' || unique_name from codeimportresult, codeimport, branch where codeimportresult.code_import = codeimport.id and codeimport.branch = branch.id and codeimportresult.log_excerpt like '%extant%';
[03:59] <mwhudson> spm: staging is fine
[03:59] <thumper> oh FFS
[04:00] <spm> mwhudson: timed? or results?
[04:00] <mwhudson> spm: results
[04:06] <thumper> ok
[04:06] <thumper> got jml's branch in pqm
[04:13] <thumper> spm: do you know if our buildbot is smart enough to check the commit log before saying testfix mode?
[04:13] <thumper> spm: although I have a feeling our commit regex won't allow [testfix] through until we are in testfix right?
[04:14] <spm> thumper: off hand I don't know - I suspect it's a mix of pqm'isms vs buildbot'isms working in new and interesting ways.
[04:14]  * thumper waits until buildbot complains before submitting the testfix
[04:16] <spm> thumper: the not-thinking-hard-eyeballing suggests that being in testfix won't matter to the RE
[04:16] <spm> as in both the success and failure configs look for testfix
[04:17] <thumper> really?
[04:17] <thumper> spm: so I could submit a [testfix] now?
[04:17] <thumper> spm: does [testfix][r=xxx] with no [ui work?
[04:19] <spm> thumper: to devel? no. db-devel - I believe! will
[04:19] <thumper> gah
[04:56]  * thumper is shepharding his 7th landing
[05:07]  * thumper waits for buildbot to crap itself to submit testfix...
[05:08] <thumper> spm: what is the regex for devel in failure mode?
[05:08] <spm> thumper: commit_re=(?is)^\s*\[testfix\]\s*\[(?:release-critical|rs?=[^\]]+)\]
[05:09] <thumper> spm: ta
[05:27] <thumper> mwhudson: a start -- https://dev.launchpad.net/Code/PostThreeDotO
[05:30] <wgrant> Mmmm. Sphinx.
[05:30] <thumper> maybe...
[05:31] <wgrant> Only maybe? Sad.
[05:31] <thumper> we need to get the entire idea approved first
[05:31] <thumper> but I'd like to see it happen
[05:31] <thumper> I think it has a good chance as far as any site hosting goes
[05:32] <thumper> my thoughts are that we'd have an option of "No processing" or "Sphinx it" on the contents of a branch
[05:32] <thumper> to host the content
[05:32] <thumper> although we should also support existing documentation in a subdirectory of an existing branch
[05:32] <thumper> hence the other task
[05:32] <wgrant> Right.
[05:33] <thumper> that was basicly a brain dump from Monday
[05:33] <thumper> I've been meaning to write it up
[05:33] <thumper> I'm sure it isn't complete
[05:33] <thumper> as I said, doesn't count any bug work
[05:33] <thumper> nor general UI improvements
[05:33] <thumper> and some tasks are way too big
[05:34] <mwhudson> thumper: do you think 'crack of the day' ppas need any work from our side?
[05:35] <thumper> mwhudson: possibly
[05:35] <thumper> I'd need more understanding of how it'll hang together
[05:53] <rockstar> Ah man, who broke the build?
[05:55] <thumper> me
[05:56] <thumper> testfix submitted already
[05:56] <rockstar> You da man.
[05:56] <rockstar> I always panic just a bit when I end up on the buildbot blamelist
[06:00] <rockstar> I can never remember where the "Subscribe" link on wiki pages is.
[06:00] <wgrant> I looked this morning and couldn't find it.
[06:01] <wgrant> Is it actually there?
[06:01] <wgrant> The source suggests not.
[06:02] <rockstar> wgrant, yeah, I can't find it, but I'm sure I'm subscribed to some pages.
[06:02] <wgrant> You can always do it manually from UserPreferences.
[06:03] <lifeless> is lp still hot?
[06:03] <wgrant> It was 24 hours ago.
[06:05] <wgrant> It is.
[06:06] <thumper> lifeless: why?
[06:07] <lifeless> thumper: I'm about to setup a test environment for faster commit with iter changes, and lp is a half decent test case
[06:07] <lifeless> but I want the code today
[06:07] <thumper> lifeless: herb has a tar ball
[06:07] <thumper> lifeless: somewhere
[06:08] <lifeless> its ok
[06:08] <wgrant> http://people.canonical.com/~herb/
[06:09] <lifeless> too late:P
[06:09] <lifeless> my link is already streaming down bzr+ssh goodness, saturated link, kgo
[06:10] <wgrant> Ah.
[06:11] <wgrant> Is LP still hot just because nobody has cooled it yet, or is there still load?
[06:12] <lifeless> I don't believe we even tested bzr+ssh scaling
[06:12] <lifeless> while bzr has http bugs the request rate is hundreds, or even thousands of times higher than it should be
[06:12] <lifeless> so load can be extremely deceptive here
[06:13] <wgrant> HTTP 2a does seem pretty sucky.
[06:13] <wgrant> But a bzr+ssh push of no new revisions seems to eat about 1MB too.
[06:13] <wgrant> (of LP, that is)
[06:14] <lifeless> probably tags
[06:14] <lifeless> maybe a regression causing it to send the adjacent (thus tip) inventory again as well
[06:15] <lifeless> how much was the db-devel branch? 130MB or something?
[06:16] <wgrant> Disk- or transfer-wise?
[06:20] <lifeless> disk
[06:20] <lifeless> 53M transferred so far
[06:21] <wgrant> 220ish MB, I think.
[06:21] <wgrant> The wiki says 150MB, but I've never seen it that small.
[06:21] <lifeless> probably nearly 30% overhead :P
[06:22] <wgrant> Overhead on top of what?
[06:22] <lifeless> its what happens when you request 500 byte windows :P
[06:22] <lifeless> vs bzr+ssh
[06:22] <wgrant> Ah.
[06:22] <wgrant> it was 280MB over HTTP.
[06:22] <wgrant> Ended up as a bit more than 220MB on disk.
[06:22] <lifeless> ah
[06:23] <wgrant> My local non-shared branch is being very slow, but just crossed 210MB.
[06:23] <wgrant> 237MB.
[06:27] <lifeless> 90M
[06:28] <wgrant> I hope that's not finished.
[06:28] <lifeless> no, not yet
[06:28] <lifeless> but soon
[06:29] <wgrant> Odd definition of 'soon'.
[06:29] <wgrant> Or you have too much faith in 2a.
[06:31] <lifeless> 2a is seriously good
[06:31] <lifeless> http bugs aside
[06:31] <wgrant> It is.
[06:32] <wgrant> I'm really pleasantly surprised at how well it works with LP.
[06:32] <wgrant> It's actually pretty fast, apart for no-op pushes.
[06:32] <spiv> lifeless: feel free to update the size estimate on the wiki... I added the 150M based on what an lp dev said on this channel, but I guess they were wrong...
[06:32] <lifeless> wgrant seems to have concrete figures :P
[06:32] <wgrant> spiv: It was updated on release night with my 280MB figure, in addition to the 150.
[06:33] <lifeless> spiv: I'm getting choppy performance
[06:33]  * wgrant disappears.
[06:33] <lifeless> dropping down to 60K and back up, sometimes even lower
[06:33] <lifeless> we should debug and fix
[06:35] <spiv> wgrant: oh, right.  Thanks.
[06:35] <spiv> lifeless: yeah.
[06:36] <spiv> lifeless: if you have a hpss log of it maybe dump it in a bug when it's done?
[06:36] <lifeless> I don't
[06:36] <lifeless> its running on my games machine; my laptop is too small to benchmark (disk space, not cpu/memory)
[06:37] <lifeless> mwhudson: so while you look at cscvs
[06:37] <lifeless> I asked a question on launchpad-code a few days back
[06:38] <lifeless> about an import that is being killed, but seems to be not a cscvs bug when I downloaded the [massive] log
[06:38] <lifeless> for gnutella
[06:38] <lifeless> sorry, not gnutella, but limewire
[06:38] <mwhudson> oh yes, the cvs logs are ridiculously enormous :(
[06:39] <lifeless> anyhow
[06:39] <lifeless> is there some way to say 'really, just let this one go'
[06:40] <mwhudson> lifeless: it's failing with memoryerror?
[06:40] <lifeless> I don't remember the problem offhand
[06:40] <lifeless> I put it all in the question
[06:40] <mwhudson> it looks like it
[06:41] <lifeless> oh yeah
[06:41] <lifeless> so
[06:41] <lifeless> I'm not sure what to do about it
[06:41] <mwhudson> lifeless: i don't understand your question, it's clearly a memory error?
[06:41] <lifeless> wgrant: completed
[06:41] <lifeless> mwhudson: is there anything that can be done?
[06:42] <mwhudson> lifeless: i guess we could do the import on some beefier machine
[06:42] <mwhudson> updates presumably won't be so crazy
[06:42] <lifeless> It should be a one time pain
[06:42] <mwhudson> i don't suppose we have big-ram machines just lying around the dc unused though
[06:42] <lifeless> wgrant: 33 minutes to download, 176MB on disk.
[06:43] <lifeless> mwhudson: how big are the machines the imports run on?
[06:43] <lifeless> are they ulimited?
[06:43] <mwhudson> no ulimit
[06:43] <mwhudson> i think they have 2 gigs
[06:43] <lifeless> whee
[06:43] <lifeless> hungry hungry hippo
[06:44] <jtv> hi folks
[06:45] <mwhudson> uh, strange, they all report different 'total' amounts in free: 4152600, 4087172, 4927824
[06:46] <mwhudson> lifeless: i see the last failure was a while, we could try again, maybe the machines got upgraded
[06:46] <mwhudson> (not sure though)
[06:46] <lifeless> please
[06:46] <lifeless> thats a fairly cheap experiment
[06:46] <lifeless> also, bzr+ssh, 6 times faster than http. FTR.
[06:46] <lifeless> maybe more
[06:47] <mwhudson> oh good, it started on nemayer
[06:47] <mwhudson> not galapagos which has a 1.1 gig bzr-git import going
[06:47] <jtv> I've been unlucky with my connections to the DC all day... is everyone downloading the launchpad source or is it just me?  (I tried different providers, different hardware, different DSL lines)
[06:47] <lifeless> heh
[06:47] <mwhudson> https://code.edge.launchpad.net/~vcs-imports/9p-linux/trunk -> 2009-07-29 05:44:31 INFO    fetching revisions 35908/155568
[06:47] <lifeless> jtv: its just you
[06:47] <jtv> of course.  evil eye.  :(
[06:47] <lifeless> jtv: even at peak lp code downloads would likely have not shown up :)
[06:47] <mwhudson> that's a lot of revisions
[06:47] <lifeless> mwhudson: and a metric fuckload of branches
[06:48] <jtv> my ping is well <.5 seconds, packet loss <5%, but bzr seems really picky
[06:48] <lifeless> jtv: 5% is huge packet loss
[06:48] <lifeless> tcp goes shite before that
[06:48] <jtv> lifeless: not in the rain season crossing both major oceans :)
[06:48] <lifeless> that said, if you're pulling from lp:launchpad, you'll be doing http, and that will fail hugely.
[06:49] <lifeless> because bzr makes thousands of requests at the moment, its fairly certain you'll get failures to connect and things like that.
[06:50] <jtv> It's going over http now?
[06:50] <lifeless> if you use an lp: url for launchpad yes
[06:50] <lifeless> its a temporary measure, but it has the effect, due to bzr bugs (and http not being as efficient as bzr+ssh) of being slower and more fragile
[06:51] <jtv> hmm... that could have interesting consequences with the whole censorship infrastructure inbetween.
[06:51] <lifeless> give it explicit bzr+ssh urls
[06:59] <mwhudson> lifeless: the limewire import just hit a gig resident
[07:01] <lifeless> woo
[07:01] <lifeless> 1.3 seconds to 0.3 seconds with this patch
[07:01] <lifeless> for commit sourcecode/Makefile
[07:16] <wgrant> lifeless: Huh. I wonder if mine needs to be repacked.
[07:16] <wgrant> It was an HTTP checkout, I guess.
[07:18] <wgrant> Oh dear, I'm in the blame list.
[07:21] <lifeless> its all your fault
[07:21] <wgrant> I do that.
[07:36] <noodles775> Morning ppl
[07:38] <wgrant> Morning noodles775.
[07:39] <noodles775> Afternoon wgrant.
[07:41] <noodles775> wgrant: how are things going? have you found any specific features you're keen to work on (or ideas of your own?) It's been great seeing the contributions you've been making already!
[07:42] <wgrant> noodles775: If development wasn't going in the direction it is now, I'd fix some UI stuff, but there's probably not much point now.
[07:43] <noodles775> wgrant: what do you mean? which direction is it going that you don't like? Or did I misunderstand?
[07:44] <wgrant> noodles775: Lots of UI changes going on, I believe.
[07:44] <wgrant> Not that I don't like it.
[07:44] <noodles775> wgrant: yes, but why does that stop you from fixing UI stuff (only if you wanted to of course)
[07:45] <noodles775> ah, you mean small ui bugs that will be fixed or cease to exist as part of larger UI changes?
[07:45] <wgrant> noodles775: Exactly.
[07:45] <wgrant> They'll presumably be noticed and resolved as people go over pages.
[07:46] <noodles775> wgrant: well, if you're keen (and only if you want to), you can join in the larger UI refactorings too...
[07:46] <wgrant> noodles775: I may be tempted once I see what is actually happening.
[07:46] <noodles775> I'm trying to ensure that the things I'll be working on will be all openly planned etc., then divided up into small bugs (associated with a blueprint) etc. etc.
[07:47] <wgrant> As it's not at all clear at the moment.
[07:47] <wgrant> How many pages are actually being redesigned rather than just transitioned to the new base layouts which seem to be the same?
[07:48] <noodles775> wgrant: OK, so some pages (pages which don't have portlets on the side etc.) can just be updated to the new templates and not much will change (other than the navigation etc. which is also not finalised)
[07:49] <wgrant> But other pages (eg. the project page) seem to be getting completely redone.
[07:50] <noodles775> But many will needto be re-designed to match the new 3-0 layout - the biggest factor that I see there is that portlets/info in the side bar are restricted to a defined set of info (actions etc.)
[07:50] <noodles775> exactly.
[07:50] <wgrant> I'm glad that use of portlets is becoming well-defined.
[07:50] <wgrant> As it's all a bit stupid at the moment.
[07:50] <noodles775> wgrant: within soyuz, the main pages we've identified that will need to change are the archive index (well, ppa index), as you should have seen from my previous email...
[07:50] <noodles775> Yes, it'll be good for it to be consistent rather than just "oh this will fit here".
[07:51] <wgrant> Well, on some pages (eg IBuild:+index), I have to wonder how anybody ever thought that.
[07:51] <wgrant> But I suppose that page has evolved.
[07:52] <wgrant> And slowly grown all of the information in the portlet.
[07:52] <noodles775> Yep... often the reason ... exactly. and the reason gets lost... which is why I'm trying to start some permanent use-case information on each page.
[07:52] <wgrant> A good idea.
[07:52] <noodles775> So as we go to work on a bug or feature that involves the UI, we have a standard reference (that can of course be updated).
[07:52] <noodles775> So for example, https://dev.launchpad.net/SoyuzBuildersIndexPage
[07:52] <wgrant> Particularly if that information is public, so the users can make their use cases known.
[07:53] <noodles775> is very empty, because I don't yet the real use-cases for this page, and so I couldn't go much further with a mock design.
[07:53] <noodles775> Exactly.
[07:53] <noodles775> I'm also drafting: https://dev.launchpad.net/SoyuzDistroSeriesQueuePage
[07:54] <noodles775> but again, there are a lot of unanswered questions for me for the queue page... I'll be trying to get some input from people who use the queue later today so we can start doing some mocks there too.
[07:55] <wgrant> The queue page is a lot less painful than the console scripts, as the console scripts have to initZopeless every time, which takes forever :(
[07:55] <noodles775> wgrant: except the UI for the queue doesn't get used much as it's also broken from the archive admins p.o.v.
[07:56] <noodles775> (I'll paste in the info from historical emails into that page...)
[07:56] <wgrant> noodles775: Right.
[07:59]  * mwhudson no longer here
[08:06]  * maxb is a bit surprised that the contributor agreement process doesn't ask you to specify your LP id when filing your agreement
[08:12] <wgrant> Has the Continue button in the popup help gone bad recently for anybody else?
[08:13] <wgrant> It is missing its text in at least two browsers I've tried.
[08:13] <wgrant> (the HTML seems clearly wrong)
[08:13]  * noodles775 tries the help on ppa page...
[08:14] <noodles775> wgrant: yep, looks like it has... worth a bug to lp-foundations? (I think?)
[08:15] <wgrant> And a patch when I get home, methinks.
[08:16] <noodles775> :)
[08:19] <noodles775> wgrant: OK, I've added https://dev.launchpad.net/SoyuzDistroSeriesQueuePage/Inputs
[08:19] <noodles775> (with a link from the parent page), if/when you're interested.
[08:26] <al-maisan> Good morning!
[08:27] <noodles775> G'day al-maisan :)
[08:27] <al-maisan> Tach noodles775 :)
[08:31] <adeuring> good morning
[08:35] <al-maisan> moin adeuring
[08:36] <adeuring> hi al-maisan!
[09:19] <mrevell> Hi!
[09:22] <bigjools> morning
[09:23] <mrevell> yo dude
[09:23] <al-maisan> mrevell and bigjools: good morning
[09:23] <mrevell> guten morgen
[09:46] <wgrant> Evening.
[09:48] <wgrant> bigjools: Thanks.
[09:49] <bigjools> wgrant: okay!  What for? :)
[09:50] <wgrant> bigjools: Landing my branch.
[09:50] <bigjools> ah, you're on the ball
[09:51] <wgrant> Well, there was an email from Launchpad sitting in my inbox.
[10:16] <wgrant> Hm, that's a bit unfortunate.
[10:17] <wgrant> All these devel commits show up without the MP metadata.
[10:17] <wgrant> As the merges were proposed to db-devel.
[10:32] <bigjools> wgrant: fancy looking at a mockup of the new DSP page?
[10:34] <wgrant> bigjools: Sure.
[10:34] <bigjools> http://people.canonical.com/~ed/dsp_mockup.png
[10:35] <bigjools> ignore the crap sample data!
[10:35] <bigjools> I gimped most of it
[10:36] <wgrant> bigjools: Where is that expander expanded from?
[10:36] <bigjools> it's  bodged from the same XHR done with the PPA rows
[10:37] <wgrant> bigjools: I mean, what's it doing there?
[10:37] <bigjools> hang on, phone
[10:59] <deryck> Morning, all.
[11:09] <bigjools> wgrant: ok I am going to tweak the image a bit, but basically the expander will open for each package version on the page, giving you more detail about it and linking to other pages.
[11:09] <wgrant> bigjools: Each version being those in the pocket listing?
[11:09] <wgrant> That sounds good.
[11:09] <wgrant> Particularly if that also applies to +publishinghistory.
[11:09] <bigjools> yep
[11:10] <bigjools> wgrant: well that's a separate page, I'll come to that later
[11:10] <bigjools> wgrant: but I wanted your feedback on the basic direction of the design, and whether you think it needs more/less data.
[11:14] <wgrant> bigjools: I'm not terribly pleased about the removal of the almost-changelog, but that is probably more effectively replaced with a batched +publishinghistory.
[11:15] <wgrant> And it's not too bad, since the latest upload in each pocket is just a click away.
[11:18] <wgrant> Upstream associations would be nice, but they suck at the moment so it's no loss.
[11:23] <bigjools> wgrant: you'll get the "almost" changelog in the expander sections, just not for all versions any more, which we want to move to +publishinghistory
[11:23] <bigjools> the description will be the upstream's BTW
[11:23] <bigjools> including the logo
[11:24] <wgrant> bigjools: Ah, useful.
[11:25] <bigjools> to fix https://bugs.edge.launchpad.net/soyuz/+bug/73116
[11:25] <mup> Bug #73116: Source package pages don't describe what the package is for <pkg-nav-redesign> <ui> <Soyuz:Triaged> <https://launchpad.net/bugs/73116>
[11:25] <wgrant> Yep.
[11:25] <wgrant> I wondered how you were going to do that.
[11:26] <bigjools> it depends on the packaging linkage of course
[11:26] <wgrant> Yep.
[11:26] <wgrant> I think initialiseFromParent needs to be taught to copy those.
[11:26] <wgrant> Or it's going to be pretty bad.
[11:26] <bigjools> interesting idea
[11:27] <bigjools> file a bug about it and start some conversations
[11:27] <wgrant> It's a bit silly to have to redo them for every series.
[11:27] <bigjools> agree
[11:27] <wgrant> Although it'd be even better if the productreleasefinder would work for more products, and compare against .orig.tar.gzs in the distro.
[11:36] <wgrant> bigjools: Is that a Registry or Soyuz bug?
[11:36] <bigjools> wgrant: registry
[11:37] <bigjools> wgrant: although file on launchpad itself and matsubara or Ursinha will triage it
[11:42] <bigjools> wgrant: reload that mockup
[11:44] <wgrant> bigjools: You need a link to the SPR as well as to expand the expanders. You also need a link to the product, and to move the publishing history link above the PPAs.
[11:44] <bigjools> wgrant: heh, you can argue with beuno about the latter
[11:45] <wgrant> bigjools: It's only one line now.
[11:45] <wgrant> But I shall prepare for an epic battle.
[11:46] <bigjools> remember that the PPA section is unexpanded by default
[11:46] <wgrant> True.
[11:46] <wgrant> But still.
[14:04] <gary_poster> maxb: looks like https://edge.launchpad.net/~gary/launchpad/zbuildout already is subscribed to by Launchpad Hackers, which is what I would have expected to be necessary.  Can you access it now?  Am I right in assuming that you are a member of Launchpad Hackers?
[14:05] <maxb> I can't access it. I'm a member of ~launchpad-dev
[14:07] <noodles775> Wow... who can I thank for the ec2test speedup?
[14:07] <noodles775> Total: 23717 tests, 0 failures, 0 errors in 160 minutes 21.996 seconds.
[14:10] <salgado> noodles775, jml, I think. he landed a change to disable staggered retries on pagetests
[14:10] <noodles775> Sheesh... that's a huge time difference! Well done jml :)
[14:14] <jml> well, I also changed the default instance type to one that was twice as fast
[14:14]  * jml isn't actually here
[14:15] <noodles775> ah, cprov just mentioned that might have happened. Thanks jml - and enjoy your evening!
[14:15] <mars> x1.large?
[14:15] <mars> nm, I'll just check the source
[14:17] <cprov> c1.xlarge
[14:20] <bac> noodles775: my last run of ec2test was on thursday and it took 158 minutes using c1.xlarge.  so it looks like the tests didn't speed up at all it's just the larger instance by default.
[14:21] <noodles775> bac: yes, seems so (I hadn't used the large instance before)
[14:21] <bigjools> tests are faster for me locally
[14:21] <bigjools> 185m -> 160m
[14:21] <bac> bigjools: really?  since when?  was it jml's change?
[14:22] <bac> wow, that's great.
[14:22] <bigjools> could be!
[14:22] <bigjools> or a new storm?
[14:24] <mars> I think you are supposed to conceive of a hypothesis before the experimental speedup, not the other way around...
[14:25] <bac> mars: but it's not our experiment.  we're just bystanders trying to figure out what happened.  :)
[14:30] <maxb> gary_poster: If you go to https://code.edge.launchpad.net/~gary/launchpad/zbuildout/+edit do you have a "Keep branch confidential" checkbox you can untick ?
[14:32] <gary_poster> maxb: yes, which I unticked immediately after subscribing launchpad-dev, so now you are doubly permitted. ;-)
[14:32] <maxb> aha
[14:33] <gary_poster> maxb: last I checked, the tests were not starting, so I'll have some work on this to get it back up.  I suspect I won't be back on this till tomorrow at the earliest.  That said, don't worry, there's plenty of internal pressure on this being done too. ;-)
[14:34] <maxb> Is having ~launchpad-dev subscribed going to send push notifications to the mailing list?
[14:35] <maxb> gary_poster: No problem, I'm attacking the issue from the other end anyhow. I have a LP running on Python 2.5 that works, and a quite a lot of the tests pass straight away
[14:36] <gary_poster> maxb: push notifications: good question, probably.  Python2.5: good.  I hope you have been coordinating with barry, then?
[14:37] <maxb> push notifications: ok, I'll unsubscribe the team then. coordinating: no. I've been loitering here and mentioning it but no one has mentioned anyone I might want to talk to other than yourself
[14:38] <maxb> I've documented what I've done on http://dev.launchpad.net/LaunchpadOnKarmic
[14:38] <gary_poster> maxb: ah ok.  yeah, barry had a branch and was doing what you are doing.  He and I both have been busy with some other tasks; he is off today, I think.
[14:40]  * maxb sets /notify barry :-)
[14:42] <mars> maxb, you may want to start a thread on the dev list, let everyone know about your instructions, and cc barry on it
[14:42] <gary_poster> maxb: wiki page: awesome!  mm...would you be willing to send an email to launchpad-dev mentioning your work and its existence, and the fact that you are trying to coordinate with me and Barry Warsaw, just so more people know of your efforts?  I think the team ought to know about this, and that's also another way of pinging Barry.
[14:42] <gary_poster> The other person who will want to know/coordinate is my boss, Francis Lacoste (probably flacoste here) who is not available till late next week.
[14:43] <mars> yeah, what gary said :)
[14:45] <maxb> sure - I'll email launchpad-dev@ this evening then
[14:46] <mars> gary_poster, awesome, debian has a command for proxying stuff into xvfb: xvfb-run: http://www-linux.gsi.de/cgi-bin/man2html?xvfb-run+1
[14:46] <mars> that means I can do this in ec2test-remote.py:
[14:46] <mars> xvfb-run -s "screen 1024x768" make jscheck
[14:47] <mars> no messing around with hand-hacked init files, or with starting and stopping xvfb in the runner
[14:48] <gary_poster> mars: wow!  so...that means that your job suddenly becomes a lot easier?
[14:48] <mars> oh yes :)
[14:48] <gary_poster> awesome!
[14:50] <mars> gary_poster, is it easy to add a new buildbot stream?
[14:50] <mars> or slave?
[14:50] <gary_poster> mars: no, not at the moment.  It requires a new image ATM.
[14:51] <mars> a new buildbot image?
[14:51] <gary_poster> mars: a new slave image, yes
[14:51] <mars> ok
[14:51] <mars> then I should look at landing the image builder script
[14:51] <mars> and adding a slave generator to it
[14:52] <gary_poster> mars: but you know, effort is relative.  but adding a slave is something that francis usually schedules, rather than being a "hey would you please..." kind of task.
[14:52] <mars> heh
[14:53] <mars> what is the most difficult part of setting it up?
[14:53] <gary_poster> mars: slave generator would be cool.  I also want to change buildbot to be able to use latent buildslave images that are generic.  To do that requires changes to buildbot master and slave code, using the twisted perspective broker stuff, so it would be cool but potentially time consuming to figure out.
[14:54] <gary_poster> that would mean that you wouldn't need new images for new slaves
[14:54] <gary_poster> just for updates
[14:54] <gary_poster> and you would only need one slave image for the update
[14:54] <gary_poster> instead of one per slave, as it is now
[14:55] <mars> gary_poster, could the ec2 slave code go into an s3 bucket, and be run from there?
[14:55] <mars> nm, guess not
[14:55] <mars> you are right
[14:56] <mars> you need to have a custom configuration somewhere that tells each slave instance "You are testing foo.  Here's how"
[14:56] <mars> and that configuration needs to stick between slave restarts
[14:57] <gary_poster> mars: most difficult: probably the slave image.  Other than that, it's just a slow process to test, and restarting the master is a pain because it throws our whole test/merge process into a dither.
[14:57] <mars> ah
[14:58] <gary_poster> mars: the description of how to test is already contained in the master, not the slave
[14:58] <gary_poster> mars: this is a "simple" problem of authentication
[14:58] <gary_poster> mars: usually (non-latent slave) a slave says to the master, "hi, I'm the slave named foo and my password is bar.  What would you like me to do?"
[14:59] <gary_poster> mars: the latent slave story needs to be able to say "hi, slave.  You are named foo.  I don't care about a password.  Now here's what to do."  or similar.
[15:00] <mars> ah, ok
[15:01] <gary_poster> It's a further refinement of the work I already did.  It wasn't necessary for buildbot to launch last year, so we postponed.
[15:01] <mars> pragmatism :)
[15:02] <gary_poster> yup :-)
[15:02] <bac> reviewers meeting now in #launchpad-meeting.
[15:22] <mars> bigjools, IIRC, barry and I talked about making our code standards a bit more public: the Launchpad Code Guidelines, or LCG for short
[15:22] <bigjools> yes, we should definitely do that
[15:22] <mars> because they are well-developed, go a bit beyond PEP008
[15:22] <mars> and they cover js, and component design
[15:23] <bac> hi kfogel
[15:24] <noodles775> sinzui: sorry if you already responded (my connection dropped), but is there any news on when we can start landing simple templates that update to the 3-0 base layout?
[15:25] <sinzui> noodles775: most the the template/macro/css is in trunk now
[15:25] <sinzui> noodles775: There is a small css issue that breaks the side portlets in main_side. I have it fixed in a branch I am working on
[15:25] <noodles775> sinzui: great! Though the other day you mentioned structured headings being the problem. Is that sorted now?
[15:26] <sinzui> noodles775: I can merge my fix into the edit work that beuno was looking at. I hope to land it today.
[15:26] <sinzui> the heading is in trunk...
[15:26] <sinzui> The heading is incompatible with the h1 edit tite widget
[15:27]  * sinzui has a fix for that too
[15:27] <mars> gary_poster, can ec2test.py use an already-running instance?
[15:27] <beuno> sinzui, https://code.edge.launchpad.net/~beuno/launchpad/finally-fix-forms/+merge/9427
[15:27] <beuno> sinzui, all yours
[15:27] <gary_poster> mars: no
[15:27] <mars> could I hack it so it does? :)
[15:27] <sinzui> beuno: fab
[15:28] <gary_poster> mars: ...yes, probably, assuming that the instance has already been set up the way that the script expects.
[15:29] <sinzui> beuno: Should I send my edit page changes for review today? Are there any issues you want me to fix with annoucement and project modification pages?
[15:29] <beuno> sinzui, let me take a quick look over them again knowing that the forms are now fixed
[15:31] <gary_poster> bigjools: do you happen to remember that issue we had with a function that returned a security-proxy wrapped object, and we felt it was unnecessary, and we got it changed?  If so, could you job my memory as to what the function did?  I'm trying to write up how we use security, per ye olde reviewers meeting action item of mine.
[15:31] <bigjools> one sec, phone
[15:31] <gary_poster> bigjools: np, thanks
[15:35] <mrkid> can somebody help me?
[15:35] <mrkid> i wanna setup launchpad on my hardy server
[15:36] <bigjools> gary_poster: it was something that returned the view in a menu class
[15:36] <gary_poster> bigjools: ah right, thanks, perfect
[15:36] <bigjools> views are not proxied anywhere else
[15:36] <gary_poster> right cool
[15:36] <mars> mrkid, well, we can help you set up a development instance.  have you checked the instructions on http://dev.launchpad.net/Getting ?
[15:37] <bigjools> gary_poster: welcome!
[15:37] <mars> :/
[15:40] <mrkid> mars: yes, but there are some errors
[15:40] <mrkid> i try : bzr --no-plugins cat http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/utilities/rocketfuel-setup > rocketfuel-setup
[15:41] <mrkid> but i got: bzr: ERROR: Unknown branch format: 'Bazaar Branch Format 7 (needs bzr 1.6)\n'
[15:41] <mrkid> how can i fix it
[15:41] <mars> are you using at least bzr 1.16.1?
[15:41] <rockstar> mrkid, you'll need to upgrade bzr
[15:42] <mrkid> thanks all, i will try
[15:43] <mars> mrkid, the instructions are on the /Getting page, in the "Overview" section
[15:43] <mrkid> thanks
[15:43] <mrkid> i got it
[15:49] <sinzui> beuno: join #launchpad-reviews
[15:50] <mrkid> #launchpad-reviews
[16:03] <sinzui> bac: ready for our call
[16:06] <bac> sinzui: yes
[16:29] <NCommander> wgrant, ping?
[16:53] <kfogel> bac: hey
[17:07] <noodles775> Night all.
[18:14] <sinzui> beuno: cprov help. I do not know how to get the version and date for the Packages in distribution portlet in this design: https://devpad.canonical.com/~curtis/LP_projectdetail.png
[18:15] <cprov> sinzui: let me check.
[18:15] <sinzui> beuno: cprov: I really do not know what kind of object I am looking at this this design
[18:16] <cprov> sinzui: I think you can follow the Packaging table to get the corresponding SPN.
[18:17]  * sinzui looks
[18:18] <cprov> sinzui: actually you find the ancestry SPs (sourcepackagename + series) in the Packaging table, then you can expand it up (good it doesn't make any sense explained that way)
[18:18] <mrevell> Okay guys, speak to you tomorrow :)
[18:19] <sinzui> cprov: can you provide a url or a template name? I am truly lost
[18:19] <bigjools> sinzui: look at the existing distribution source package page
[18:19] <bigjools> it has packaging stuff at the top
[18:20] <cprov> sinzui: okay, let's say the bazzar upstream product was package in dapper, edgy and feisty as 'bazzar' and since gutsy it was packaged as 'bzr' ... You will have 2 entries in Packaging for that product [(bazzar-SPR, dapper), (bzr-SPN, gutsy)]
[18:20] <bigjools> distributionsourcepackage-index
[18:21] <sinzui> okay, that helps. The code looks like I was getting a SourcePackage...no distro
[18:22] <cprov> sinzui: SP == (SPN, DistroSeries)
[18:23] <cprov> sinzui: none of the widgets we have atm does the right thing with Packaging records, i.e. it's not expanded properly.
[18:24] <cprov> sinzui: see `Product.sourcepackages`
[18:24] <sinzui> well, package/version is gives me nothing. Either sampledata is invalid, or I do not have the right objects
[18:24] <sinzui> cprov: that is indeed what I am iterating over, but the version is always nothing
[18:25] <cprov> sinzui: most likely sampledata is crap
[18:25] <sinzui> \o/
[18:25] <cprov> sinzui: but even if it was good the result won't be expanded to newer series as we want it to be.
[18:25]  * sinzui looks for something other than sample firefox
[18:31] <cprov> sinzui: https://launchpad.dev/netapplet is satisfactory
[18:32] <sinzui> cprov: thanks. I am still not getting a version from the Product.sourcepackages, but I at least know I should be able to do it
[18:32] <cprov> sinzui: SPs do not have a version, one sec
[18:33] <sinzui> cprov: okay, this is what I was thinking...we want to show something *different* on the page, or the designer did not know that SP and DSP are not the same.
[18:33] <cprov> sinzui: SP.distinctreleases ... have
[18:35] <sinzui> plural? Again this lead me back to the moment I asked for help. This design is flawed, it does not represent how things work in launchpad. cprov looking at that picture, does the packaging make sense?
[18:35] <cprov> sinzui: in some extent SP & DSP are pretty much the same, they are just bound to different contexts (distroseries vs. distribution). They both do not have version, but instead 'versions'
[18:36] <cprov> sinzui: it does, you will have multiple versions under 'gnome-panel in Ubuntu Gutsy'
[18:37] <cprov> sinzui: or better, if you want to be accurate with the mockup, use the latest version
[18:37] <sinzui> cprov: currentversion?
[18:38] <cprov> sinzui: it's not implemented by SP
[18:40] <cprov> sinzui: SP and DSP both implement 'currentreleases' but it also return multiple releases corresponding to each pocket.
[18:40] <sinzui> yuck. This design is flawed. I will ignore this line until beuno can specificy what he wants.
[18:42] <bac> kfogel: hi, again
[18:42] <cprov> sinzui: okay
[18:43] <kfogel> bac: hello
[18:58] <bigjools> gary_poster: do you know what "belt and suspenders" means in British English? :)
[19:00] <rockstar> bigjools, I'm curious as to what it means, especially since it's you pointing it out.
[19:01] <bigjools> rockstar: suspenders here are what women use to hold up stockings
[19:01] <bigjools> belt & suspenders has entirely different connotations
[19:02] <rockstar> bigjools, ah, we call those garter belts.
[19:03] <bigjools> braces == suspenders, for future reference :)
[19:03] <gary_poster> bigjools: oh. :-)  oops.
[19:04] <bigjools> just don't use the word "fanny" here ok?
[19:04] <gary_poster> bigjools: lol, ok
[19:04] <bigjools> :)
[19:06]  * rockstar goes to eat a foods.
[19:35] <sinzui> cprov: sp.distinctlreases is indeed what we want, it just does not work as the designer intended. I will use it and explain why.
[19:37] <cprov> sinzui: okay. Are we continuing with the unexpanded-packaging issue ?
[19:38] <sinzui> cprov: The design suggests that I use a dt, dt pair. Since I can have multiple dd per dt, I just iterated over them. I am not showing the pocket information
[19:40] <cprov> sinzui: I mean 'expanded' in the model domain, not the UI, sorry. I was referring to the `Product.sourcepackages` issue.
[19:41] <cprov> sinzui: it's unrelated to the UI, redesign, so ignore me for now we can talk about it later.
[19:41] <sinzui> I think I will solve that another day, after speaking to distro people about what they expect. For now I want to get the UI complete
[19:42]  * cprov nods
[21:18] <mwhudson> BjornT: congrats on r9000 :)
[21:31] <beuno> thumper, are we still on in 30 min?
[21:41] <beuno> wooo, deryck really nailed description editing
[21:44] <thumper> beuno: yes
[21:47] <kiko> beuno, really?!
[21:47] <beuno> kiko, yes
[21:47] <beuno> I have an amazing branch here
[21:47] <beuno> there's a few small UI tweaks to be done
[21:47] <beuno> but it's minor
[21:47] <beuno> he claims the code needs cleaning up as well
[21:47] <beuno> but it works as mocked up
[21:48] <beuno> the UI is not even interaction, he nailed those
[21:48] <beuno> it's layout
[21:51] <mwhudson> morning
[21:51] <thumper> mwhudson: morning
[21:52] <thumper> mwhudson: https://code.edge.launchpad.net/~vcs-imports/xizero/master
[21:52] <mwhudson> thumper: i saw, briefy
[21:52] <thumper> mwhudson: the git import had an invalid sha1
[21:52] <mwhudson> thumper: guess a bzr-git bug
[21:52] <thumper> mwhudson: I'm wondering when we rolled out the fix to cache the sha1 map
[21:53] <thumper> rockstar: can I line you up for a call after the standup?
[21:53] <mwhudson> oh right, it failed a while a go
[21:53] <rockstar> thumper, yessir!
[21:53] <thumper> rockstar: ta
[21:55] <mwhudson> thumper: i trashed the copy of the import
[21:55] <thumper> mwhudson: ok, lets see if that fixes it
[21:55] <mwhudson> yeah
[22:07] <wgrant> NCommander: Hi.
[22:17] <rockstar> mars, ping
[22:17] <mars> hi rockstar
[22:18] <rockstar> mars, so BjornT has introduced LP.client.ErrorHandler.  Have you seen it?
[22:18] <mars> rockstar, nope - have a screenshot?
[22:18] <mars> or some way to play with it?
[22:18] <rockstar> mars, it doesn't really have any UI for it.  I've just barely started using it.
[22:19] <rockstar> mars, although Bugs has been using it.  deryck pointed it out to me.
[22:19] <mars> what does it do?
[22:19] <abentley> thumper: skype?
[22:20] <rockstar> mars, so you create it, define some methods to tell it how to deal with an error, and then on failure of Y.io calls, have it call the error handler.
[22:20] <thumper> abentley: on with beuno right now
[22:20] <rockstar> mars, basically, I think we need to unify on the error handling story, because we all seem to be doing different things.
[22:20] <rockstar> mars, we may need to consult the great and powerful beuno.
[22:21] <mars> agreed - I'm glad to see someone went ahead and wrote something
[22:21] <mars> do you know what bugs have the error handling routines do?
[22:22] <rockstar> mars, they are using overlays to display the error itself, which I partially disagree with.
[22:22] <rockstar> mars, but I've just been calling alert() with a generic message, and then Y.log-ing the error itself.
[22:26] <mars> I don't really have an idea for either
[22:26] <mars> save for turning the broken component red, with a link to the word "Oops!" on it, that pops up the error window :)
[22:27] <mars> think of it as a non-interrupting error
[22:27] <mars> otherwise, if anyone has seen how other sites handle AJAX errors, I'd like to hear about it
[22:28] <rockstar> mars, so, Facebook's (which I see WAY too often) puts up a bit too technical of a message, but having a little overlay telling me something went wrong is nice.
[22:29] <rockstar> mars, but overlays are a bit intrusive.  I'll raise it for the next UI meeting.
[22:34] <mars> rockstar, here's a test for what Y! does, at least at the business logic level
[22:34] <mars> visit http://m.www.yahoo.com/
[22:34] <mars> click the first left item, "View Yahoo! Sites"
[22:35] <mars> And then click on the blue + beside "Addresses"
[22:35] <mars> and you get an overlay
[22:35] <mars> which is part of their global page error handling structure
[22:35] <mars> the div is already present in the DOM
[22:41] <rockstar> mars, yeah, that's pretty good.  I'll bring that up in the next UI meeting, and maybe we'll incorporate that in the 3.0 stuff.
[23:30] <beuno> sinzui, I've pushed the bold label change, would you approve the branch on the MP?  https://code.edge.launchpad.net/~beuno/launchpad/finally-fix-forms/+merge/9427
[23:31] <sinzui> beuno: it is approved
[23:32] <beuno> sinzui, danke
[23:34] <Ursinha> mwhudson, hiz
[23:34] <Ursinha> er, hi
[23:34] <mwhudson> Ursinha: hello
[23:34] <mwhudson> Ursinha: what have i broken now? :)
[23:34] <Ursinha> mwhudson, lol
[23:34] <Ursinha> mwhudson, are you aware of https://bugs.edge.launchpad.net/launchpad-code/+bug/406410
[23:34] <mup> Bug #406410: Trying to look to the merge proposals details makes edge and staging platforms of lp to timeout <merge-proposal-review> <timeout> <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/406410>
[23:35] <thumper> who is going to fix the testfix?
[23:35] <mwhudson> Ursinha: i was not, but i bet i know what the problem is
[23:36] <Ursinha> mwhudson, better than being aware and not knowing what the problem is :)
[23:36] <Ursinha> mwhudson, what's that?
[23:36] <mwhudson> Ursinha: it's a huuuge diff and streaming it from the librarian takes ages
[23:36] <mwhudson> Ursinha: you can see that the sql time is pretty low
[23:36] <Ursinha> mwhudson, oh. I see
[23:37] <Ursinha> mwhudson, indeed, I saw that
[23:37] <mwhudson> there's a bug about this, which i am currently entirely failing to find
[23:37] <rockstar> thumper, http://www.fsf.org/blogs/community/savannah
[23:38]  * mwhudson slaps launchpad
[23:38] <mwhudson> get faster!
[23:38] <wgrant> I noticed that launchpad.dev is nice and fast.
[23:38] <Ursinha> lol
[23:38] <Ursinha> mwhudson, searching for it
[23:39] <mwhudson> Ursinha: https://bugs.edge.launchpad.net/launchpad-code/+bug/401554
[23:39] <mup> Bug #401554: branch merge proposal pages should limit how much diff they show <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/401554>
[23:39] <mwhudson> wgrant: yes, <1ms network latency and a small database sure help
[23:39] <wgrant> mwhudson: Yep.
[23:40] <mwhudson> Ursinha: do you want to make the new bug as a duplicate or shall i?
[23:40] <Ursinha> mwhudson, I'm doing that now
[23:41] <mwhudson> cool
[23:41] <Ursinha> mwhudson, thanks for finding that so quickly
[23:41] <mwhudson> Ursinha: np
[23:42] <mwhudson> Ursinha: i guess we should milestone it
[23:42] <mwhudson> thumper: what do you think to fixing https://bugs.edge.launchpad.net/launchpad-code/+bug/401554 soon?
[23:42] <mup> Bug #401554: branch merge proposal pages should limit how much diff they show <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/401554>
[23:42] <Ursinha> mwhudson, that would be great
[23:42] <thumper> yeah, we should fix that
[23:43] <thumper> mwhudson: if you have it open, target for 2.2.8
[23:43] <mwhudson> thumper: done
[23:43] <thumper> ta
[23:44] <Ursinha> thanks guys
[23:44] <mwhudson> np
[23:44]  * rockstar walks the dog
[23:44] <mwhudson> i wonder why we're seeing this problem so much more now
[23:44] <mwhudson> it's been around as long as review diffs
[23:44] <mwhudson> i guess people must actually be using our software more!
[23:52] <thumper> beuno: still around?