[00:04] <wgrant> Oh, russkaya, go away.
[00:04] <wgrant> Nobody likes you.
[00:13] <blr> wgrant: cjwatson: what's the significance (if any) or 'scotty' and 'mountain'? heh
[00:13] <blr> s/or/of/
[00:15] <cjwatson> blr: Your guess is as good as mine; the branch vocabulary tests go back quite a way
[00:15] <cjwatson> I probably copied them, but ...
[00:16] <blr> cjwatson: I've perpetuated the mystery.
[00:18] <blr> wgrant: all sorted save a GitDefaultConflict on setting the default repo to the same repo on a second submission.
[00:19] <blr> wgrant: suppose that will have to handled with the abort hack?
[00:20] <cjwatson> blr: That's a bug in GitRepository.set{Owner,Target}Default, I think; they should return early if existing == self
[00:21] <cjwatson> blr: Please fix that while you're there rather than inserting abort hacks.  The test should be simple
[00:21] <blr> cjwatson: ah, I assumed that was the right behaviour. Sure, I can fix that up.
[00:22] <cjwatson> (Or just "if existing is not None and existing != self", given that the following code is quick and a no-op in both cases)
[00:32] <blr> grabbing some lunch
[00:37] <cjwatson> hloeung: All right, so much for tomorrow morning.  https://code.launchpad.net/~cjwatson/launchpad/openpgp-show-fingerprint/+merge/262803
[00:38] <cjwatson> We'll get +activereviews under control yet :-)
[00:38] <hloeung> heh; oh so stories/*/xx-*.txt aren't actually generated?
[00:38] <cjwatson> No
[00:38] <hloeung> it looks easy now that I've seen someone else's diff of the changes required
[00:39] <cjwatson> Doctests are no fun
[00:39] <cjwatson> But they're easy enough to do lightweight tweaks to if you have an environment to run the tests in, indeed
[00:40] <cjwatson> The idea is that the indented bits that look like Python interpreter sessions are run and the output compared with what the file says it's supposed to be
[00:41] <cjwatson> So we wouldn't want to generate them
[00:41] <wgrant> Doctests are good for some things :)
[00:41] <wgrant> Mainly for documenting APIs.
[00:41] <wgrant> View aren't APIs :/
[02:08] <lifeless> doctests are the devils spawn
[02:08] <lifeless> there's a very narrow set of places they make sense - and they are great there.
[02:08] <lifeless> but - attractive nuisance everywhere else
[02:09] <blr> lifeless: gather someone was a little over-enamoured with Cucumber?
[02:11] <lifeless> blr: doctests are a very different thing to cucumber
[02:11] <lifeless> blr: but if it had existed, they probably would have loved it :)
[02:11] <blr> lifeless: the way they're using in LP is very similar
[02:11] <blr> *used
[02:12] <lifeless> there's none of the regex object lookup stuff
[02:12] <lifeless> nor rich verifiers
[02:12] <lifeless> because there's no DSL
[02:12] <lifeless> so there's no place to fix the issues
[02:13] <blr> right, I just mean in the 'BDD/tests as stories' sense
[02:14] <blr> lifeless: I would be happier with them if they were less brittle I guess
[02:15] <lifeless> yah
[02:39] <blr> wgrant: fixed the setTargetDefault bug, should be ready for you to look at when you're free.
[02:50] <blr> wgrant: one thing that could use improvement (although not certain how it works wrt the vocab), an invalid shortened_path returns "Invalid value" which could be nicer.
[03:51] <wgrant> blr: "Invalid value" is the best Launchpad error.
[06:07] <wgrant> blr_: ProductSeries:+index doesn't seem to work any more.
[06:29] <blr_> wgrant: hrm, will have a look, thanks.
[06:30] <blr_> ah, the git vocab context type
[07:25] <blr_> wgrant: hmm, that vocabulary won't be used in the ProductSeries context of course, s
[07:25] <wgrant> blr_: Shouldn't need to exist, no, since the field doesn't exist there.
[07:29] <blr_> weird, tmux went bellyup... anyhow.
[07:30] <blr_> wgrant: have pushed a fix, although it might not be the best approach.
[07:31] <blr_> the vocabulary will be called in both contexts, so I've handled ProductSeries there.
[07:31] <wgrant> blr_: Why is it being called when the widget isn't rendered there?
[07:33] <blr_> the SetBranchForm schema is inherited
[07:34] <wgrant> blr: It's common to customise self.field_names in setUpFields.
[07:34] <wgrant> So you could only include default_vcs and the git bits in one case.
[07:36] <blr> wgrant: right, can see that in some of the other views, that seems preferable to handling the unwanted context in the vocab!
[07:36] <wgrant> blr: Yep. The only thing to worry about is fixing the update actions to only run the code when the relevant widgets aren't excluded.
[08:54] <blr> wgrant: ok that should be looking happier now, thanks.
[20:58] <blr> would be nice if the comment nav left a buffer at the top of the frame...
[20:59] <cjwatson> wgrant: Are you happy with me requesting a prod git upgrade run?  I'd like to get turku in place again (it'll require slightly special instructions in the ticket, which I'll take care of).  It'll also pull in your recent turnip changes though.
[20:59] <blr> evening cjwatson
[21:00] <cjwatson> hiya
[21:00] <cjwatson> will vanish shortly to put kids to bed :)
[21:01] <blr> yep, see you in an hour
[21:01] <cjwatson> blr: will you have a chance to finish off verbose-diff today?
[21:02] <blr> cjwatson: will certainly try - just about finished with changes from wgrant's review
[21:44] <blr> wgrant: regarding configure_codehosting on ProductBranchListingView, not certain I understand your comment - it isn't an override afaict.
[22:00] <wgrant> cjwatson: Yep, turnip upgrade is fine.
[23:01] <cjwatson> man I love being able to do entire meetings without making a noticeable dent in my battery
[23:03] <wgrant> Heh
[23:03] <cjwatson> wgrant: oh, BTW, I'm deliberately not landing avoid-pbuilder until the buildd upgrade happens, to avoid confusion with the recipe build that would follow a commit
[23:04] <wgrant> cjwatson: Which confusion?
[23:04] <cjwatson> perhaps we should change procedures there to copy from ~launchpad/ubuntu/buildd-staging instead of ~launchpad/ubuntu/ppa
[23:04] <wgrant> Oh
[23:04] <cjwatson> the current procedure has them copying from ~launchpad/ubuntu/ppa, which is the target of a recipe
[23:04] <wgrant> IS confusion, right.
[23:05] <cjwatson> that
[23:42] <cjwatson> wgrant: I was thinking the other day about how we'd do git mirroring, incidentally; my thought is that we'd want to have a separate juju environment for pull/push workers (it wants rather different firewall rules from turnip, lots more outgoing), each of which keeps something like an LRU store of repositories which it reaps when it runs low on space; probably no point in sharing code with the existing codeimport stuff, it wants to be ...
[23:43] <cjwatson> ... juju from the start and there's not a huge amount it can usefully share; haven't figured out how the dispatch would work yet; don't know how the existing codeimport stuff arranges to be sufficiently privileged
[23:43] <wgrant> cjwatson: The existing codeimport stuff is valuable as a lesson in how not to do it.
[23:43] <cjwatson> the job dispatch business is something we'd need to solve to jujuise bzr codeimport anyway, since we wouldn't want the workers talking to the DB
[23:44] <wgrant> I was going to try avoiding having a duplicate copy of the branches.
[23:45] <wgrant> The codeimport workers currently talk only to xmlrpc-private and librarian upload.
[23:45] <cjwatson> The only way I can see to do that is to allow turnip outbound access; or perhaps a custom twisted thing to proxy git receive-pack/upload-pack
[23:46] <wgrant> I believe a bridge may be feasible.
[23:46] <cjwatson> Yeah, might even be buildable out of turnip code perhaps
[23:46] <cjwatson> It has most of the right pieces for it
[23:46] <wgrant> It just needs to handle the have/want negotiation between the remote upload-pack and the local receive-pack.
[23:46] <wgrant> That was always my preferred solution, but I don't have a proof of concept.
[23:48] <mwhudson> yes, don't do what the codeimport stuff does
[23:50] <mwhudson> figuring out how to let launchpad services have privileged access to branches would be nice too...
[23:50] <wgrant> You mean other than unauthenticated-but-firewalled read-only slow HTTP? :)
[23:51] <mwhudson> ideally
[23:51] <mwhudson> that's codebrowse you're talking about there?
[23:52] <wgrant> All internal services access Bazaar branches using the same mechanism.
[23:52] <wgrant> Scanning, diff generation, etc.
[23:52] <mwhudson> oh right, yes
[23:52] <mwhudson> what i meant, as i'm sure you know, is things like recipes for private branches
[23:52] <mwhudson> and also having code imports just being able to push to the branch directly
[23:53] <wgrant> Yep.
[23:53] <mwhudson> (but not having code import workers having the ability to just push to any branch...)
[23:53] <wgrant> Now that we have HTTPS git repo access that's probably more reasonable.
[23:53] <wgrant> No need for SSH keys. We can just create temporary tokens.
[23:53] <cjwatson> We'd need auth tokens
[23:53] <cjwatson> Yeah
[23:53] <wgrant> Similar to the librarian's TLTs, except that they can be revoked once the job is done.
[23:55] <mwhudson> i half implemented this for the codehosting ssh server once