[00:05] <thumper> mwhudson: LP's bzr-git is missing 44 revisions from trunk :(
[00:05] <mwhudson> thumper: !?
[00:05] <mwhudson> thumper: time for an upgrade i guess?
[00:06] <thumper> yes, I think so
[00:06] <thumper> mwhudson: does that sound like a build engineer task?
[00:06] <mwhudson> thumper: not especially...
[00:07] <mwhudson> otoh, i'm not actually doing much else now
[00:07] <thumper> :)
[00:07] <thumper> mwhudson: don't we just have to push it through ec2 with a different bzr-git?
[00:07] <thumper> mwhudson: something like that?
[00:08] <mwhudson> thumper: i guess landing the branch will still run all the tests in pqm
[00:08] <thumper> mwhudson: does it?
[00:08] <thumper> well
[00:08] <thumper> pqm isn't doing much else right now
[00:08] <mwhudson> this is true
[00:08] <thumper> although we will want to land a fix for the registry breakage
[00:16] <thumper> mwhudson: I'm going to fix the failing test
[00:16] <thumper> mwhudson: I may get you to review the expected one line fix
[00:16] <mwhudson> thumper: okidoke
[00:17]  * thumper makes
[00:17]  * thumper taps fingers while make makes
[00:19] <mwhudson> oh yay, jelmer rebased dulwich trunk again
[00:19] <spm> mwhudson: didn't we register a bug against that particular problem? ;-)
[00:20] <mwhudson> yeah
[00:20] <mwhudson> (in Quotes)
[00:20] <spm> "where" doesn't matter so long as "did"
[00:39] <thumper> mwhudson: http://pastebin.ubuntu.com/266368/
[00:39] <thumper> mwhudson: it fixes the failure
[00:40] <mwhudson> thumper: +1, with a sigh on the side
[00:40] <mwhudson> thumper: please submit it as a [testfix] now
[00:40]  * thumper nods
[00:44] <thumper> mwhudson: submitted
[00:44] <mwhudson> thumper: thanks
[00:50] <jelmer> mwhudson: hmm?
[00:51] <jelmer> mwhudson: I haven't touched dulwich in a while
[00:51] <mwhudson> jelmer: we haven't updated the version we used in even longer it seems :)
[00:52] <jml> jelmer, hello
[00:52] <jml> mwhudson, spm, thumper, et al: hi
[00:52] <jelmer> hey jml
[00:52] <spm> hey jml
[00:53] <jml> all of my discipline in waking up on time has vanished with my 8am daily call :)
[00:58] <mwhudson> jml: oops
[00:59] <mwhudson> jml: adapting yourself to london time, one hour a day?
[01:00] <jml> mwhudson, heh
[01:03] <jml> mwhudson, how's buildbot looking?
[01:03] <mwhudson> jml: reasonably terrible, no worse than usual
[01:03] <mwhudson> jml: it's building, at least
[01:04] <jml> mwhudson, that's something, I guess.
[01:05] <mwhudson> we'll all be surprised if the build doesn't fail though
[01:05] <jml> mwhudson, I did a test run last night on devel -- there are failing tests
[01:05] <jml> mwhudson, https://bugs.edge.launchpad.net/launchpad-foundations/+bug/425113 might interest you
[01:06] <mup> Bug #425113: Some tests can fail without detection <build-infrastructure> <Launchpad Foundations:New> <Twisted:Unknown> <https://launchpad.net/bugs/425113>
[01:06] <mwhudson> jml: which ones?
[01:06] <jml>   lib/lp/registry/browser/tests/productseries-views.txt
[01:07] <mwhudson> jml: oh god
[01:07] <mwhudson> (the bug)
[01:07] <mwhudson> jml: thumper fixed that one already
[01:07] <jml> glad to hear it :)
[01:07] <jml> mwhudson, yeah, the bug is going to require some patches to Twisted, I think.
[01:08] <mwhudson> though i don't know where his fix went
[01:08] <mwhudson> thumper: did your submission fail?
[01:08] <thumper> mwhudson: :(
[01:08] <thumper> yes
[01:08] <thumper> forgot the ui tag
[01:08] <mwhudson> hee
[01:08] <thumper> as it isn't needed in normal testfixes
[01:08] <thumper> but is for fake test fixes
[01:11] <jml> thumper, btw, bug 425399 is yet another bug in the cluster of "tighter review integration"
[01:11] <mup> Bug #425399: too many clicks to get to important review <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/425399>
[01:12]  * thumper nods
[01:12] <thumper> jml: I saw it
[01:14] <jml> cool.
[01:16] <jml> thumper, btw, something interesting came up on the weekend -- would be keen to chat about it with you
[01:17] <thumper> jml: ok, heating pizza now, how about in 10 minutes?
[01:17] <jml> thumper, sounds good :)
[01:25] <thumper> jml: if you don't mind hearing me munching, we can talk now
[01:25] <jml> thumper, cool
[01:28] <MTeck> jml: looks like I lost a group member - but I think we can still do the project just fine
[01:28] <MTeck> jml: I've been thinking about it more
[01:29] <jml> MTeck, cool
[01:29] <jml> MTeck, how many does that leave you with?
[01:30] <MTeck> jml: 3 total
[01:31] <jml> MTeck, ahh, that's plenty :)
[01:31] <MTeck> jml: should be plenty for it
[01:31] <MTeck> ya :P
[01:32] <jml> MTeck, so you've been thinking about it?
[01:32] <MTeck> I'm planning on it
[02:03] <mwhudson> jml, spiv, thumper: https://pastebin.canonical.com/21867/ (for bug 424136)
[02:03] <mup> Bug #424136: Cannot upgrade stacked branches from 1.9 to 2a on Launchpad <branch-puller> <Launchpad Bazaar Integration:Confirmed> <https://launchpad.net/bugs/424136>
[02:04] <mwhudson> hm, why did i use canonical pastebin?
[02:04] <mwhudson> habit i guess
[02:04] <mwhudson> http://pastebin.ubuntu.com/266396/
[02:05] <thumper> mwhudson: extra carriage return between tests, but other than that r=thumper
[02:06] <mwhudson> oh yeah
[02:06] <mwhudson> guess i should fix the lint too
[02:07] <mwhudson> thumper: thanks
[02:08]  * mwhudson lunches
[02:10] <spiv> mwhudson: looks good at a glance
[02:14] <jml> mwhudson, looks good to me.
[02:19] <MTeck> jml: I was thinking - I could probably make my own specs easily enough - any chance you'd prefer do it? I know you mentioned something about talking to people this week.
[02:20] <jml> MTeck, I'm not quite sure I follow.
[02:21] <jml> MTeck, I reckon that any specs you'd do would have to be a collaborative effort between you & whoever on the team was looking after that area
[02:22] <MTeck> jml: I just meant however you guys would expect it to work
[02:22] <MTeck> I'm guessing a lot like SSH keys and another drop down in the bug report
[02:25] <jml> MTeck, yeah, it'd probably be something like that.
[02:25] <MTeck> jml: sorry - I just want to make sure you guys get what you want - but when I think about it more, it's pretty hard to not make it fit in sensibly
[02:25] <jml> MTeck, heh
[02:25] <jml> MTeck, nothing to apologize about. :)
[02:28] <jml> MTeck, I guess it's probably a good idea to send through a rough spec & some notes on the project to the launchpad-dev list
[02:28] <jml> MTeck, don't spend too much time on it though.
[02:28] <MTeck> yup - I'll enjoy this project
[02:28] <jml> since discussion will definitely follow :)
[02:34] <MTeck> jml: any issues with me using the LP Wiki?
[02:35] <jml> MTeck, none at all.
[02:35] <jml> unless it's locked :)
[02:35] <MTeck> ok - I'll do it all there then - then you can all take a peak
[02:55] <jml> thumper-afk, lp:~cprov/launchpad/bug-424797-buildd-manager-test-failure  ⇒ lp:launchpad/devel  is appearing on my personal +activereviews page.
[02:55] <jml> thumper-afk, under "Approved to land"
[02:55] <jml> thumper-afk, I'm not sure it should
[02:57] <MTeck> jml: so - https://dev.launchpad.net/Bugs/UpstreamForwarding sound like a good url for us to use?
[03:15] <jml> MTeck,
[03:15] <jml> yes.
[03:18] <jml> mwhudson, when everything is settled, could you please review a branch for me?
[03:19] <mwhudson> jml: request away
[03:19] <jml> https://code.edge.launchpad.net/~jml/launchpad/ec2test-karmic-bug-424197/+merge/11265
[03:19] <jml> yay ajax bugs
[03:20] <mwhudson> that was easy
[03:20] <jml> mwhudson, I'm full of easy patches these days :)
[03:20] <MTeck> I tried to do 'bzr push bzr+ssh://bazaar.launchpad.net/~mteck-devs/launchpad/UpstreamBugs/' but it didn't like me :(
[03:20] <jml> mwhudson, it turns out that there's a fairly big number of useful easy things to do.
[03:21] <jml> MTeck, what was the error?
[03:22] <jml> mwhudson, thanks.
[03:23] <MTeck> http://pastebin.ubuntu.com/266417/
[03:24] <jml> MTeck, upgrade your branch to 2a
[03:24] <jml> MTeck, 'bzr upgrade --2a' should do it.
[03:25] <jml> (bzr ought to give you a way to push without stacking if the remote host has a defaut stacking branch set, but it doesn't)
[03:25] <MTeck> You guys just completely lost me
[03:26] <MTeck> stacking and --2a... lost
[03:26] <jml> MTeck, ahh, I see.
[03:27] <jml> MTeck, they are both implementation details of bzr
[03:27] <jml> MTeck, bazaar branches have formats. normally, this doesn't matter, since bzr is normally able to interoperate between different format branches.
[03:27] <jml> MTeck, one such format is '2a'. It has a feature that makes it incompatible with the default format.
[03:28] <jml> MTeck, this feature is called "rich root support"
[03:28] <jml> MTeck, Launchpad branches are all in the 2a format, since it's going to be the new default format.
[03:29] <jml> MTeck, 'stacking' is a technical term for a particular way that one branch can share data with another branch.
[03:30] <jml> MTeck, Launchpad has settings that hint to Bazaar that branches pushed to a project should be stacked on the trunk branch of the project.
[03:30] <jml> MTeck, We do this to save us space and you time on the network.
[03:30] <jml> MTeck, Normally it's just an implementation detail that you don't need to care about.
[03:31] <MTeck> oh
[03:31] <jml> MTeck, but in this case, you are trying to stack your branch on a branch in an incompatible format.
[03:31]  * MTeck keeps learning more and more about bzr
[03:31] <wgrant> How was a non-2a Launchpad branch obtained?
[03:31] <jml> MTeck, so Bazaar gives you an error.
[03:31] <MTeck> --2a made it all better :)
[03:32] <jml> MTeck, Bazaar could do better at this, but no one has had the combination of motivation, time and energy.
[03:32] <jml> MTeck, I told you it would :)
[03:33] <MTeck> so, the stacked piece is the part of the project part in ~team/project/branch ?
[03:33] <jml> not quite.
[03:33] <MTeck> am I close?
[03:34] <jml> if a project has a development focus set, then branches will be stacked by default on that branch.
[03:34] <MTeck> oh - over 24hr no sleep now :P
[03:34] <jml> so, in Launchpad's case, lp:launchpad
[03:34] <MTeck> oh!
[03:37] <MTeck> jml: thanks for teaching me more yet :)
[03:38] <MTeck> I'm curious - how do you have so many people developing LP but keep conflicts down?
[03:39] <wgrant> 30 devs over Python 500KLOC isn't very large.
[03:39] <MTeck> kloc?
[03:40] <MTeck> oh...
[03:40] <MTeck> k loc :P
[03:45] <spiv> kLoC ;)
[03:46] <MTeck> So - how should I start developing on this piece
[03:47] <jml> MTeck, tbh, I would look for an easy, unrelated bug to fix and do that first.
[03:47] <mwhudson> the main weapon in the fight against conflict is short lived branches
[03:48] <jml> https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=trivial&field.tags_combinator=ANY
[03:48] <MTeck> that's a lot
[03:48] <jml> MTeck, you don't have to do all of them :)
[03:48] <jml> (although it'd be nice)
[03:49] <MTeck> :P
[03:49] <wgrant> I wish that would tell me what criteria it used, although it's easy enough to work out.
[03:49] <jml> mwhudson, I'm not sure whether "short lived" or "single purpose" is more important.
[03:50] <mwhudson> jml: "small, in some sense"
[03:50]  * mwhudson displays his mathematical background
[03:50] <jml> heh
[03:50] <jml> wgrant, https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=trivial&field.tags_combinator=ANY
[03:50] <jml> sorry
[03:50] <jml> wgrant, https://bugs.edge.launchpad.net/malone/+bug/325982
[03:50] <lifeless> Watch out, LINKS INCOMING
[03:50] <mup> Bug #325982: Search URL is long and hard to paste <trivial> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/325982>
[03:51] <lifeless> oh the irony
[03:52] <wgrant> jml: Yep.
[03:54] <MTeck> It's confusing that there's not just one branch that has all the code needed to develop
[03:54] <wgrant> It's much better than the alternative (edge not updating for half of the month)
[03:56] <MTeck> Isn't bzr supposed to be coming up with sub-branches so you can have one big branch with minor branches below it?
[03:56] <wgrant> Oh, you're talking about the deps?
[03:57] <MTeck> I'm not sure - it was metcalfe that mentioned it to me
[03:58] <jml> I'm going off IRC for a while to try to focus a bit better. ping me via skype or xmpp if you need my attention.
[03:58] <MTeck> http://bazaar-vcs.org/NestedTreeSupport
[03:58] <MTeck> jml: ^ This is what I was thinking of
[03:58] <MTeck> and he goes away so I can't annoy him :P
[03:58]  * mwhudson stabs the aws console through the lungs
[03:59] <MTeck> that brings offtopic thoughts to mind (annoying people)
[05:15] <thumper> jml: if you reviewed it, it is going to show (now)
[05:15] <thumper> jml: as your personal active reviews page shows the reviews you need to do
[05:15] <thumper> jml: and are doing
[05:15] <thumper> jml: would you expect to see it drop off?
[05:17] <mwhudson> jtv: do you know anything about this bug? https://bugs.edge.launchpad.net/launchpad-foundations/+bug/47511
[05:17] <mup> Bug #47511: pagetests add ghost new lines to textareas <build-infrastructure> <Launchpad Foundations:Triaged by bjornt> <https://launchpad.net/bugs/47511>
[05:17] <mwhudson> jtv: carlos reported it, which is why i'm asking you
[05:17] <jtv> mwhudson: ohhh
[05:18] <jtv> that sounds like it's related to ye aulde problem of some browsers adding newlines at the beginning/end of what's in a textarea.
[05:21] <jtv> mwhudson: have you tried running the test he attached?
[05:21] <mwhudson> jtv: it looks a bit old school, i don't know if it will still run
[05:21] <mwhudson> i guess i should just tyr
[05:21] <jtv> You _may_ also have to disable whitespace normalization...
[05:24] <jtv> mwhudson: the test looks old-school, but prima facie I don't see anything that shouldn't work any more
[05:38] <kfogel> mwhudson: on devpad:
[05:38] <kfogel>  bzr branch lp:~kfogel/+junk/lpcc trunk
[05:38] <kfogel> Permission denied (publickey).
[05:38] <kfogel> bzr: ERROR: Connection closed: Unexpected end of message. Please check connecti\
[05:38] <kfogel> vity and permissions, and report a bug if problems persist.
[05:38] <kfogel> mwhudson: this is something I must have neglected to set up on devpad, but what?  a keyfile somewhere?
[05:38] <mwhudson> kfogel: agent forwarding?
[05:39] <kfogel> mwhudson: er, do I need that to check out a public branch?
[05:39] <mwhudson> kfogel: over ssh, yes
[05:39] <mwhudson> kfogel: and you must have run bzr launchpad-login at some stage on devpad
[05:39] <kfogel> mwhudson: maybe.  but my command is "bzr branch lp:..."
[05:39] <kfogel> why would that do ssh, or at least, why wouldn't it fall back to http??
[05:40] <sinzui> How do I solve this build problem:
[05:40] <sinzui>     Getting distribution for 'zc.buildout==1.5.0dev-gary-r103553'.
[05:40] <wgrant> sinzui: Is your download-cache up to date?
[05:41] <sinzui> I claims to be for the last 48 hours
[05:42] <spiv> kfogel: it would do ssh if you've previously run bzr launchpad-login (because it then assumes that ssh will work, and ssh is almost certainly faster because of the smart server).
[05:42] <wgrant> What's the actual error?
[05:42] <mwhudson> kfogel: bzr doesn't know that the ssh connection isn't going to work
[05:42] <sinzui>   Bootstrapping.
[05:42] <sinzui>   Getting distribution for 'zc.buildout==1.5.0dev-gary-r103553'.
[05:42] <sinzui> Error: Couldn't find a distribution for 'zc.buildout==1.5.0dev-gary-r103553'.
[05:42] <sinzui> Getting distribution for 'zc.buildout==1.5.0dev-gary-r103553'.
[05:42] <sinzui> make: *** [bin/buildout] Error 1
[05:42] <sinzui> make: Leaving directory `/home/curtis/Work/launchpad/rocketfuel'
[05:42] <spiv> kfogel: it doesn't fallback because bzr doesn't really make it easy for that to work :(
[05:42] <mwhudson> kfogel: it could catch and retry i guess, but the logic is all a bit upside down for that to be easy
[05:42] <kfogel> mwhudson: it certainly knows that it fails :-).  But anyway, I'm not sure what the fix is.  I just need to check out some bzr branches.
[05:42] <mwhudson> kfogel: log out, ssh -A devpad
[05:42] <kfogel> mwhudson: yeah, catch and retry is what I was expecting I guess.
[05:42] <kfogel> spiv: ^^
[05:42] <kfogel> mwhudson: thanks
[05:43] <kfogel> spiv: too bad about the code arrangement :-(
[05:43] <sinzui> download-cache/dist is empty again. bzr says nothing is wrong
[05:43] <mwhudson> sinzui: bzr up download-cache fixed that for me
[05:43] <mwhudson> sinzui, kfogel: what the heck are you guys doing onine
[05:43] <jml> thumper, yes, I'd expect it to drop off, since I can't do anything about it, and I don't really have responsibility for it.
[05:43] <sinzui> download-cache
[05:43] <sinzui> Tree is up to date at revision 9354.
[05:43] <wgrant> bzr st
[05:43] <mwhudson> sinzui: that's wrong
[05:43] <jml> thumper, otoh, I guess if it were a patch from someone who can't land, then it should really appear there
[05:43] <kfogel> mwhudson, spiv: the "ssh -A" worked, thanks.
[05:43] <kfogel> mwhudson: I just wanted to get a cron job going before I went to bed.
[05:43] <jml> thumper, which is starting to sound maybe a little too intelligent
[05:44] <mwhudson> there's no way download-cache is at rev 9354
[05:44] <thumper> jml: :)
[05:44] <jml> thumper, what do you think?
[05:44] <jml> kfogel, hi
[05:44] <kfogel> jml: hey!
[05:44] <mwhudson> kfogel: use an http url?
[05:44] <wgrant> mwhudson: A very good point.
[05:44] <jml> MTeck, yeah, bzr should have nested trees
[05:44] <kfogel> mwhudson: mmm, I could have constructed that, yeah
[05:44] <jml> MTeck, atm, Launchpad uses three ways to manage dependencies
[05:44] <kfogel> mwhudson: but I wanted my strawberries and cream and "lp:" goodness
[05:45] <kfogel> jml: https://dev.launchpad.net/Contributions
[05:45] <jml> kfogel, yeah, I saw :)
[05:45] <kfogel> jml: (as per our discussion)
[05:45] <kfogel> jml: ah good
[05:45] <jml> kfogel, oh, my privmsgs got silently lost
[05:45] <jml> :(
[05:45] <wgrant> That's a pretty depressing page.
[05:45] <kfogel> wgrant: it is a bit lopsided :-)
[05:45] <jml> kfogel, I love the new ToC
[05:45] <kfogel> jml: yay freenode
[05:45] <jml> wgrant, depressing for whom exactly?
[05:46] <kfogel> jml: cool.  we under-use the "<<Anchor(foo)>>" syntax in moin I think.
[05:46] <wgrant> jml: Everyone. There are practically no contributions.
[05:46] <jml> wgrant, it's way more than I was anticipating.
[05:46] <kfogel> wgrant: a month or so after the first release of a difficult-to-build hosted service?  I wish for more contributions too, but this isn't bad.
[05:47] <kfogel> wgrant: remember maxb is in the pipeline now
[05:47] <wgrant> kfogel: Mm, I guess.
[05:47] <wgrant> That's true.
[05:47] <jml> wgrant, but I'm very keen to see more contributors.
[05:47] <jml> wgrant, got any ideas for how we could get more?
[05:47] <wgrant> jml: Not restrict everything to Ubuntu.
[05:47] <wgrant> Debian would be easy, but PPAs don't do Debian.
[05:48] <kfogel> wgrant: +1 +1 +1
[05:48] <kfogel> I completely agree.
[05:48] <mwhudson> a bug!
[05:48] <kfogel> Debian, and then other distros too.
[05:48] <kfogel> wgrant: our dependency setup is our Achilles' heel.
[05:49] <wgrant> jml: I count four types of deps.
[05:49] <wgrant>  - Debian packages
[05:49] <wgrant>  - sourcecode
[05:49] <wgrant>  - bzr checkouts
[05:49] <wgrant>  - eggs
[05:49] <wgrant> Hm. Wait. Maybe I split something there.
[05:49] <wgrant> They confuse me, anyway.
[05:49] <jml> wgrant, 'bzr checkouts'?
[05:49] <jml> wgrant, sourcecode, debs & eggs -- that's it, I think.
[05:50] <wgrant> jml: Mm, right, the bzr checkouts are sourcecode.
[05:50] <jml> wgrant, it's confusing
[05:50] <jml> and I don't see us dropping to one kind any time soon
[05:57] <jtv> mwhudson: still working on patching up that test
[05:57] <wgrant> Has anybody tried to run LP on Debian or other derivatives yet?
[05:58] <kfogel> wgrant: I thought someone had...
[05:58]  * kfogel looks
[05:58] <mwhudson> jtv: ok, don't sweat it too much
[05:58] <wgrant> kfogel: I know somebody was considering trying it some weeks ago.
[05:59] <kfogel> wgrant: oh, no, no record of success yet
[05:59] <wgrant> But I don't recall hearing any results.
[05:59] <jtv> mwhudson: the holdup is setupBrowser not being defined.
[05:59] <jtv> Ahhh, stupid.  Got the trouble
[06:00] <jtv> fixed
[06:01] <ajmitch> wgrant: I see you've managed to get quite a few branches landed, well done
[06:01] <jml> ajmitch, your turn :)
[06:02] <wgrant> ajmitch: I've about another five sitting around, too.
[06:02] <ajmitch> jml: Once I replace my dying laptop, I'll be able to look at it again
[06:03] <wgrant> kfogel: How do you determine the author? Looking at the MP, or the latest revision, or something even more inventive?
[06:04] <wgrant> Ah, there is code.
[06:04]  * wgrant looks.
[06:10] <mwhudson> jtv: does the test pass?
[06:11] <jtv> mwhudson: still patching it up...  having to set up layers for every run is the big bottleneck
[06:12] <kfogel> wgrant: one thing that hurts is that I can't (yet) determine the person who made the landing request.  That's due to everything looking like ~launchpad-pqm; we should find someplace for PQM to hang that information, and have the script look there.
[06:12] <wgrant> kfogel: Right.
[06:12] <wgrant> (and we should stop sticking metadata in revision messages!)
[06:12] <kfogel> jml: okay, cron job on devpad updates the Contributions page every 10 min now.
[06:12] <jml> kfogel, sweet.
[06:13] <jml> one day, it'll be just as easy to update it in response to events
[06:13] <kfogel> wgrant: well, yes, ideally.  bzr has the right kind of properties to handle this already, I think, no?
[06:13] <wgrant> kfogel: It does.
[06:14] <kfogel> jml: "events" like (say) maxb updating deps, or did you mean something else?
[06:14] <wgrant> And the emails that Launchpad sends out already show the [r=foo][ui=bar] in another way.
[06:14] <ajmitch> kfogel: you expect new contributions every 10 minutes?
[06:14] <kfogel> wgrant: hmmm.  the script could parse that too... but I kind of think it's better that it show what the msg actually looks like
[06:14] <jml> kfogel, I mean, update in response to an actual commit, rather than polling
[06:14] <kfogel> ajmitch: no, but I never know *which* 10 minutes one will come in.
[06:14] <kfogel> jml: ah, yes, that would be ideal!
[06:15] <jml> doing that now would mean listening for email, which kind of sucks.
[06:15] <wgrant> So, why is all that metadata in the revision message?
[06:15] <kfogel> jml: yah, I'd rather Not Go There.
[06:15] <jml> wgrant, pqm checks it.
[06:15] <kfogel> wgrant: because we're unimaginative in our use of bzr properties?
[06:15] <jml> wgrant, it forces submissions to match a regex
[06:15] <wgrant> jml: I know.
[06:16] <wgrant> jml: i mean why is it *in the revision message*.
[06:16] <wgrant> And not in properties.
[06:16] <jml> wgrant, limitations in PQM.
[06:16]  * wgrant headdesks.
[06:16] <ajmitch> sounds like something just waiting to be improved
[06:16] <jml> wgrant, I'm not trying to be difficult, sorry.
[06:17] <kfogel> wgrant: nice verb, I think I'm going to have occasion to use that in the future.
[06:17] <wgrant> jml: Oh, I know.
[06:22] <mwhudson> jml: should https://code.edge.launchpad.net/~jml/lp-dev-utils/bzr-plugin/+merge/7427 be a launchpad branch now?
[06:23] <jml> mwhudson, I'm not sure what to do with that now.
[06:24] <jml> mwhudson, utilities/ is a pretty crappy place to keep a bzr plugin.
[06:25] <mwhudson> jml: you could say it's a pretty crappy place to keep any software
[06:25] <kfogel> jml: I'm not sure the fact of being a bzr plugin is any more relevant than, say, being written in sh instead of py.
[06:25] <jtv> mwhudson: I don't think I can patch up that test and be sure it tests what it was meant to.  :(
[06:26] <mwhudson> jtv: oh well
[06:26] <kfogel> jml: bzr is just one of many tools the script uses to do its job.  I don't think that affects its appropriateness for being in the utilities/ dir.
[06:26] <jml> mwhudson, kfogel: you can run a script from utilities without any installation step or env variable setting, you can't do that for a bzr plugin
[06:27] <kfogel> jml: is that true of all the scripts in there?  I'd never realized it was a qualification for being in utilities.  It's about to be violated again when I move lpcc.py  (the thing that updates the Contributions page) over to utilities/, since that requires editmoin.py which we currently don't ship in utilities (nor should we, probably).
[06:28] <jml> kfogel, well, it's not, I guess.
[06:28] <jml> kfogel, but it's a nice property, I think.
[06:29] <kfogel> jml: "meh", I guess.  If it is a req, we should document it, but I don't feel strongly it is a req.
[06:29] <jml> ok.
[06:29] <kfogel> jml: ah, maybe a more positive way to say it:
[06:29] <kfogel> jml: "something can be in utilities if it's useful for developing or running launchpad"
[06:30] <kfogel> er, "and has no other home" :-)
[06:30] <jml> heh
[06:30] <jml> well, I can try to redeem the bzr plugin branch.
[06:30] <jml> but it's pretty low priority for me (it wouldn't have been six weeks ago)
[06:30] <kfogel> bedtime here.  You can run wild, I won't be around to argue.  Go nuts :-).
[06:31] <jml> kfogel, heh
[06:32] <jml> mwhudson, https://code.edge.launchpad.net/~jml/lp-dev-utils/moved-dev-tools/+merge/11237 -- want to approve that?
[06:33] <mwhudson> jml: ok
[06:34]  * jml is experiencing doc writing fail
[07:00] <thumper> spm: what's up with the buildbot?
[07:02] <spm> thumper: I just bounced it - is it ded?
[07:02] <spm> belh. yes.
[07:02] <thumper> spm: I'm gettign 503
[07:02] <thumper> spm: had it succeeded?
[07:02] <thumper> spm: why was it bounced?
[07:02] <spm> thumper: I thought it had, but clearly not; should be good now;
[07:03] <spm> mwh was doing some testing
[07:03] <spm> dur. try again. mwh was doing some buildbot changes and testing thereof.
[07:03] <thumper> it's up now
[07:03] <mwhudson> thumper: it succeede
[07:03] <mwhudson> d
[07:03] <thumper> need to kick db_lp
[07:03] <thumper> \o/
[07:04] <mwhudson> well, there should be a stable -> db-devel merge soon
[07:04] <mwhudson> but yes, probably need to kick db_lp anyway
[07:04]  * thumper forced db_lp
[07:04]  * thumper wanders of for dinner time activities
[07:04] <thumper> off
[07:04]  * mwhudson eods
[07:04] <thumper> d'uh
[08:30] <adeuring> good morning
[08:38] <bigjools> morning all
[09:17] <mrevell> Good Monday :)
[09:18] <bigjools> eyup mrevell
[09:59]  * wgrant grumbles a bit at the lack of Debian support in PPAs.
[10:44] <allenap> bigjools: fmt:link dunt work for a distroseries. Is there any reason I shouldn't add one?
[10:44] <allenap> mrevell: Morning :)
[10:44] <bigjools> allenap: weird, it should
[10:44] <danilos> jtv: I guess IRC woes continue
[10:45] <danilos> jtv: btw, what's the status on translations-person-3.0-mechanical branch?
[10:45] <mrevell> hey there allenap
[10:45] <bigjools> allenap: how are you doing it?
[10:45] <allenap> bigjools: series/fmt:link
[10:46] <jtv> danilos: that one got stuck in EC2 trouble before I left, so I'll be submitting.  (I reverted the changes to the main page, as you asked).
[10:46] <bigjools> allenap: <a tal:replace="structure series/fmt:link"/> ?
[10:46] <jtv> danilos: I did land the 3 bugfixes from Vientiane
[10:47]  * jtv checks... it's a bit of a "cold boot"
[10:47] <danilos> jtv: Vientiane?
[10:47] <jtv> The capital of Laos.
[10:47] <allenap> bigjools: Yeah, basically that.
[10:48] <allenap> bigjools: I get: NotImplementedError: No link implementation for <canonical.launchpad.webapp.tales.ObjectFormatterAPI object at 0x83d1a10>, IPathAdapter implementation for <DistroSeries at 0x83d90d0>
[10:51] <danilos> jtv: ok, cool
[10:52] <allenap> bigjools: Bizarrely, fmt:url works fine.
[10:52] <bigjools> allenap: yeah it uses canonical_url IIRC
[10:52] <allenap> bigjools: Ah, okay.
[10:52] <bigjools> stick wid dat unless you want more work :)
[10:53] <allenap> bigjools: Okay, will do :)
[10:53] <bigjools> although distroseries is registry now, Curtis might have something to say
[10:56] <allenap> bigjools: I'll send him a quick email.
[11:23] <bigjools> wgrant: around?
[11:23] <wgrant> bigjools: I am.
[11:23] <bigjools> do you know the use cases for the related-software page?
[11:23] <bigjools> eg https://edge.launchpad.net/~wgrant/+related-software
[11:24] <bigjools> I remember fixing bugs on it but I've never seen a canonical set of use cases
[11:24] <wgrant> bigjools: There are no really important use-cases for that page in particular (apart from general interest), but its children are important.
[11:25] <bigjools> okay
[11:25] <bigjools> so in theory that page could be junked?
[11:25] <wgrant> In theory, but it is useful.
[11:25] <bigjools> ok :)
[11:25] <bigjools> it's a grey area in terms of application ownership
[11:26] <wgrant> Indeed.
[11:26] <wgrant> Although I'd say it was Soyuz.
[11:26] <bigjools> it's my last set of pages to convert to 3.0
[11:27] <bigjools> and as curtis so eloquently put it: nightmare
[11:29] <wgrant> Why? Not just mechanical changes?
[11:29] <bigjools> the nav menu needs to be dismantled
[11:29] <wgrant> Oh, right.
[11:29] <wgrant> Forgot that bit.
[11:29] <bigjools> and it's a two-tier one
[11:29] <bigjools> and it's a mix of registry and soyuz templates :/
[11:30] <wgrant> bigjools: Just link the section headings?
[11:30] <wgrant> Or add a "View all maintained packages" link at the right like new main-content portlets have?
[11:31] <bigjools> yeah - I could convert to an action menu
[11:32] <wgrant> Don't those end up down the bottom, so are impossible to find?
[11:32] <bigjools> top right
[11:33] <bigjools> related-pages appear at the bottom
[11:33] <wgrant> Hm. I'm not sure I've seen non-indices with action menus.
[11:33] <bigjools> well, in fact they appear where I put them :)
[11:34] <bigjools> hmmm yeah that would fall foul of the guidelines
[11:34] <bigjools> I've seen related pages links under action menus though, so if there's no action menu it can appear at the top right
[11:35] <wgrant> It seems odd to have that as the only thing on the right -- it's a bit of a waste.
[11:35] <bigjools> indeed
[11:35] <bigjools> can you see why it was labelled nightmare now?
[11:35] <wgrant> Yes.
[11:36] <wgrant> My current favourite is the convention of having "View all <whatever>" links in the top right. But that might not work for a page like that where the sections are the primary content.
[11:37] <wgrant> Top right of the relevant portlet, that is.
[12:08] <wgrant> bigjools: Any great ideas?
[12:08] <bigjools> wgrant: my only idea is not great, and that's to have a side bar
[12:09] <wgrant> bigjools: :(
[12:09] <wgrant> And both the 3.0 UI gods are absent?
[12:09] <bigjools> yep
[12:14] <wgrant> That seems like suboptimal timing.
[12:16] <bigjools> only 1 day for curtis
[12:16] <bigjools> and knowing him I bet he's around anyway :)
[12:17] <wgrant> Ah, right.
[12:49] <wgrant> Well, that was disappointingly uneventful (getting LP running on Lenny).
[15:58] <al-maisan> Hello there, I added this merge proposal earlier today but no email was sent out: https://code.edge.launchpad.net/~al-maisan/ubuntu/karmic/pristine-tar/gendelta-fix/+merge/11303
[15:58] <al-maisan> Is that normal?
[16:00] <al-maisan> abentley: Can you please take a look ^^ ?
[16:01] <abentley> al-maisan: I'd be happy to look tomorrow, but I'm off today.
[16:01] <al-maisan> abentley: sorry .. I did not know.
[16:01] <abentley> al-maisan: no problem.
[17:19] <bigjools> sinzui: are you lurking?
[17:20] <sinzui> I am
[17:20] <bigjools> I knew I could count on you
[17:20] <bigjools> sinzui: being a nice guy, I thought I'd start on the +related-software 3.0 change
[17:20] <bigjools> this is in no way me feeling guilty for moving two of my templates into registry today
[17:20] <sinzui> bigjools: That is very generous.
[17:21] <sinzui> Which templates?
[17:21] <bigjools> productseries-packaging and ... /me looks
[17:22] <bigjools> sourcepackage-packaging
[17:22] <sinzui> Yes, I agree they belong
[17:22]  * sinzui was wondering why there were so few sp templates to convert
[17:22] <bigjools> sinzui: my question is, I thought I'd use related-pages to put the mess of menus in a sidebar portlet
[17:23] <bigjools> I started, but the context menu is for IPerson and that's not what I want, how do I use a different one?
[17:23] <sinzui> That wont pass beuno's inspection because the menu is not a top-level collection
[17:23] <sinzui> bigjools: I had a similar problem...
[17:23] <bigjools> argh
[17:23] <bigjools> ok
[17:23]  * sinzui tries to remember what he did.
[17:23] <bigjools> how about an action menu?
[17:24] <sinzui> bigjools: I remember adding a <ul class="horizontal"> of links below the narrative on a page
[17:24] <sinzui> bigjools: It is the same way links are formatted on the product page...
[17:25] <sinzui> and then I realised that I had reinterpreted the black bar as a white bar
[17:27] <bigjools> that's fabulously low-tech
[17:28] <sinzui> bigjools: I hard coded it too, no nav menu
[17:28] <sinzui> bigjools: but you can keep the menu since I think it already has what you expect to see
[17:28]  * sinzui chooses the fastest way to get the page landed
[17:28] <bigjools> indeed, I just need to repeat the links in the tal then
[17:29] <bigjools> ok, I'll attack this tomorrow
[17:29] <sinzui> bigjools: I will welcome the distraction from CHR
[17:29] <bigjools> there's no description on any of those pages though
[17:29] <bigjools> so the links will appear right at the top
[17:30] <bigjools> can tal iterate over those menus so I don't have to hard-code the link names?
[17:34] <sinzui> bigjools: maybe the lack if description is why I do not understand what the pages are for or who uses them. I suspect teams have different uses case than users (seeing the bug reports by persia)
[17:34] <bigjools> yeah - one of the uses I am aware of is reviewing someone's contributions when they want to become a MOTU
[18:32] <mrevell> night all
[20:45] <bigjools> sinzui: still around?
[20:46] <sinzui> yes
[20:46] <bigjools> sinzui: check this out lp:~julian-edwards/launchpad/related-software-30
[20:46] <bigjools> browse to https://launchpad.dev/~mark/+related-software
[20:58] <sinzui> bigjools: this looks good
[20:59] <bigjools> sinzui: better than I'd thought it would
[20:59] <bigjools> what's with the weird breadcrumbs lately?
[20:59] <sinzui> I ponder the uses of 'See also' and 'Full listing' Maybe the page doesn't need them
[21:00] <sinzui> yes, I saw the breadcrumbs on Friday
[21:00] <sinzui> bigjools: happily they are not your problem
[21:01] <bigjools> sinzui: right, the extra text was an afterthought
[21:01] <sinzui> Full listings is helpful.
[21:02] <sinzui> I am just surprised by the See also. I understand why you need to change the label
[21:03] <sinzui> bigjools: I think the <h1> and page title should either both include 'Summary', or both not use it
[21:03] <bigjools> yeah, we could do with barry's heading branch landing ;)
[21:04] <sinzui> bigjools: Actually, I am surprised that the heading and title are not the same
[21:04] <bigjools> sinzui: coz it's a hack job
[21:05] <sinzui> bigjools: the constant "Realated project" vs. "Projects related" looks like two different people working on the page.
[21:06] <bigjools> sinzui: yeah I didn't attempt to do much with the headings/titles, I just wanted to visualise the new layout
[21:06] <sinzui> bigjools: I do not have any suggest about how to fix this
[21:07] <bigjools> well won't barry's branch reverse the title anyway?
[21:07] <sinzui> the layout is a nice improvement. The links are easy to see now. This is a nice imrovement for users
[21:09] <sinzui> bigjools: I do not this it will do that in the first round. I am not sure how that can be done since the page title would have to be generated from the breadcrumbs. The crumbs are not good english
[21:10] <bigjools> okay, I'll knock up a page_title to sort it out
[21:12] <mwhudson> hmm
[21:13] <mwhudson> has gary been around today?
[21:34] <bigjools> sinzui: I made some changes, check it out
[21:39] <sinzui> bigjools: this is very nice
[21:40] <bigjools> sinzui: the nightmare has ended :)
[21:40] <sinzui> bigjools: you can have my ui* r=me
[21:41] <bigjools> sinzui: rock n roll
[22:06] <mwhudson> oh, labour day, duh
[22:15] <thumper> morning
[22:15] <thumper> mwhudson: yeah, just you and me again for our team I think
[22:15] <mwhudson> thumper: abentley should be here?
[22:15] <mwhudson> or is labour day the same day as labor day?
[22:15] <thumper> I think it is labour day in canada too
[22:16] <mwhudson> oh yes
[22:16] <mwhudson> it's thanksgiving that's a week apart?
[22:17] <mwhudson> thumper: skype then?
[22:18] <thumper> yep
[22:19] <mwhudson> hm, is this the usual confusion about who's online
[23:16]  * maxb wonders why the tarballs at http://people.canonical.com/~herb/ are ~230MB, when a freshly `bzr pack`-ed repository is only 140MB
[23:18] <lifeless> maxb: we had fragmentation bugs in the 2a format, in bzr. lp was suffering those, and its likely that herb tarred up the public repo, which would be fragmented
[23:31] <wgrant> maxb, lifeless: Those were created on release night, from a fresh checkout.
[23:31] <wgrant> But bzr sucked at that point.
[23:31] <lifeless> wgrant: see under fragmentation
[23:31] <lifeless> wgrant: we also didn't recompress when receiving fragmented streams
[23:32] <lifeless> all of which combine. These things are fixed in 2.0rc2
[23:32] <wgrant> lifeless: Right, but it wasn't the public copy's fragmentation.
[23:32] <wgrant> Yep.
[23:32] <wgrant> Nightlies work great now.
[23:32] <lifeless> wgrant: a fresh checkout made on release night would have inherited the public copies fragmentation
[23:32] <lifeless> wgrant: because lp was set hot, and hot things go to the public copy
[23:33] <wgrant> lifeless: Ah, right.
[23:33] <lifeless> wgrant: [and further to that, the master is on pqm; both lp copies are 'public' in that sense]
[23:33] <lifeless> spm: ping
[23:33] <spm> lifeless: heyo
[23:34] <lifeless> spm: this all reminds me; care to do a bzr pack in the codehosting copies of stable, devel, etc
[23:34] <wgrant> +inf
[23:34] <lifeless> df -h .bzr/repository/packs before and after
[23:34] <wgrant> But 1.17 doesn't do a very good job.
[23:34] <spm> of launchpad? not without flacoste being ok with doing so
[23:34] <wgrant> And isn't that what's on codehosting?
[23:34] <lifeless> if its < 1MB there
[23:34] <lifeless> 's no need
[23:34] <lifeless> wgrant: it will pack just fune
[23:34] <lifeless> *fine*
[23:35] <wgrant> lifeless: It didn't get devel down below 200MB for me.
[23:35] <lifeless> wgrant: with the C extensions?
[23:35] <lifeless> spm: well, gather the data anyhow.
[23:35] <wgrant> lifeless: I think so, but it was a while ago.
[23:35] <lifeless> spm: I don't see that this is a flacoste thing; its operational mgmt for a hosted branch :)
[23:36] <lifeless> spm: if anyone its a thumper/mwhudson thing
[23:36] <thumper> eh?
[23:36] <lifeless> thumper: theres a good chance that the copies of lp on codehosting are badly fragmented
[23:36] <thumper> and
[23:36] <lifeless> thumper: due to about 4 interacting bugs in bzr
[23:36] <wgrant> They are very, very badly fragmented.
[23:36] <wgrant> Nearly 100% larger.
[23:37] <lifeless> it will improve fetch performance, decrease server memory use, and disk space, if they get 'bzr pack' run on them.
[23:37] <lifeless> and network overhead on fetching too
[23:37] <thumper> lifeless: however bzr pack takes ages
[23:37] <lifeless> thumper: it doesn't lock the repository
[23:38] <thumper> lifeless: and IIRC you told me you should never need to run bzr pack
[23:38] <thumper> lifeless: so, why now?
[23:38] <lifeless> thumper: you shouldn't; OTOH I also said 'I wouldn't upgrade to 2a until its fully finished'
[23:38] <thumper> :)
[23:38] <thumper> lifeless: will the autopacks fix the issue?
[23:38] <lifeless> thumper: in 5 years or so
[23:39] <lifeless> auto packs only touch recent data most of the time
[23:39] <lifeless> thumper: how many revisions does your lp repo have in  it ? [bzr info -v]
[23:40] <thumper> 67122
[23:40] <lifeless> thumper: as to why now, I just got reminded of it by maxb above; we'll want to do this once, to all 2a repos on codehosting, when codehosting deploys 2.0
[23:40] <lifeless> ok autopack will fix this for you in another 32878 commits
[23:41] <thumper> lifeless: so why is it badly packed now?
[23:41] <lifeless> because of bzr bugs in 1.16,1.17 and 1.18 with fetching of 2a
[23:42] <thumper> lifeless: looking at the packs there, they look as large as expected
[23:42] <thumper> lifeless: to me it looks like natural growth
[23:42] <thumper> lifeless: why do you think it is different?
[23:42] <thumper> lifeless: I pushed completely packed repos there the first time
[23:43] <lifeless> looking at http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/.bzr/repository/packs/?C=S;O=D ?
[23:43] <thumper> yes, I was
[23:43]  * lifeless tests
[23:44] <maxb> for comparison purposes, a freshly packed shared repo of all 4 primary branches packs down to one 109MB pack
[23:44] <lifeless> thumper: ^
[23:45] <lifeless> thumper: in a fragmented repo the ratios of packs stay the same; the packs are just bigger.  Its their internal structure that is odd
[23:45] <lifeless> too many compression groups
[23:45] <thumper> lifeless: so internal changes to bzr in recent revisions have fixed this?
[23:46] <lifeless> 2.0rc2 will both no longer cause fragementation when fetching, and partially compensate for existing fragmentation on the client
[23:46] <lifeless> doing a full pack now won't stop some further fragmentation on lp until lp rolls out 2.0. *but* packed data won't get fragmented: its only *new data* that fragments.
[23:47] <thumper> lifeless: so no point really until we are on a later version of bzr
[23:47] <thumper> lifeless: because we only have 1.17 on LP now
[23:47] <thumper> lifeless: I'm in the progress of landing 1.18 final
[23:48] <thumper> lifeless: and I would add in 2.0rc2 if I could find the tar.gz on LP
[23:48] <thumper> but I can't
[23:48] <thumper> lifeless: but this won't be rolled out until 3.0
[23:48] <lifeless> thumper: there is very much a point now
[23:49] <thumper> lifeless: we don't have the fixed bzr on the machines to do the packs
[23:49] <lifeless> thumper: 99% of the data that will be in the repository when 3.0 is rolled out is already in it now; you can shrink the repo by ~ 60% according to maxb's stats
[23:49] <lifeless> thumper: you don't need a fixed bzr
[23:49] <lifeless> we haven't changed pack
[23:50] <lifeless> I wouldn't be suggesting this if I didn't think it would help you!
[23:50] <thumper> lifeless: why then is the repo so large when I packed it before pushing?
[23:50] <thumper> lifeless: I had a single pack file when we created the repo
[23:50] <lifeless> because pushing was fragmenting!
[23:50] <maxb> So, basically, a repack now saves bandwidth for LP and downloaders between now and 3.0 ?
[23:51] <thumper> hmm..
[23:51] <lifeless> thumper: and you pushed to the private copy, lp then copied it again to the public one fragmenting it further
[23:51] <maxb> (Somewhat meta question) Why does LP keep two copies anyway?
[23:52] <lifeless> thumper: at *every step* dictionary sort order was changing what bzr considered optimal @ merge points
[23:52] <thumper> maxb: histerical raisons
[23:52] <lifeless> thumper: each time this happens a gc group splits; gc groups contain full texts, so that text doubles its storage size
[23:52] <maxb> ahhh....
[23:52] <lifeless> maxb: theory at the time was scaling and security
[23:53] <thumper> lifeless: so to be effective we'd have to pack both copies?
[23:53] <lifeless> thumper: users pull from the public copy only, even on bzr+ssh
[23:53] <thumper> lifeless: how does pack work without locking?
[23:53] <lifeless> so most important one is the public copy
[23:53] <thumper> lifeless: no they don't
[23:53] <thumper> lifeless: bzr+ssh pulls from the hosted copy
[23:53] <lifeless> thumper: just a few days ago we had this confirmed
[23:53] <thumper> if it is a hosted branch
[23:53] <wgrant> thumper: Only if you have write access, right?
[23:54] <lifeless> thumper: and I'm sorry to say, you're wrong  :)
[23:54] <thumper> wgrant: it wraps it in a readonly transport
[23:54] <lifeless> thumper: or jml/mwhudson lied to us :)
[23:54] <thumper> lifeless: confirmed by whom?
[23:54]  * thumper looks at the code
[23:55] <mwhudson> thumper: well you and i will read from the hosted copy, cause we're bzr experts
[23:55] <mwhudson> everyone else reads from the mirrored area though
[23:55] <lifeless> mwhudson: am I a bzr expert ?
[23:55] <jml> hopefully not
[23:55] <thumper> mwhudson: I thought that all hosted branches were read from the hosted area
[23:55] <mwhudson> lifeless: you're an admin aren't you?
[23:55] <lifeless> mwhudson: not anymore
[23:55]  * jml dislikes the group, and wishes it as small as possible
[23:55] <mwhudson> thumper: how to put this tactfully?
[23:56] <mwhudson> thumper: i think you thought wrong
[23:56] <thumper> :)
[23:56] <thumper> mwhudson: where is the code?
[23:57] <mwhudson> thumper: it seems to be a bit convoluted
[23:57] <lifeless> >>> t = bzrlib.transport.get_transport('bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/.bzr/repository/packs')
[23:57] <lifeless> >>> t.list_dir('.')
[23:58] <mwhudson> thumper: but it's in lp.codehosting.vfs.branchfs
[23:58] <wgrant>         if writable:
[23:58] <wgrant>             dispatch = self._hosted_dispatch
[23:58] <wgrant>         else:
[23:58] <wgrant>             dispatch = self._mirrored_dispatch
[23:58] <mwhudson> TransportDispatch._makeBranchTransport
[23:58] <lifeless> 1d0252d21c3632af79515b5e8c497c15.pack
[23:58] <lifeless> thats the same large pack as on the public side
[23:58] <lifeless> spot check of a few others matches
[23:59] <lifeless> now that thats out of the way
[23:59] <lifeless> thumper: bzr repositories have fine grained locking, they were designed to be as concurrent as possible.