[00:19] <poolie> o/ jelmer
[09:01] <mgz> morning all!
[09:08] <vila> mgz: hey !
[09:08] <vila> mgz: can you have a look at https://code.launchpad.net/~vila/bzr/948339-config-caching/+merge/97256 and give me a quick go/no-go for inclusion in 2.6b1 ?
[09:11] <vila> wow, I don't know what have changed but ./tools/check-newsbugs.py is faster than ever by a significant margin...
[09:17] <fullermd> I'll take the credit.
[09:28] <vila> bad, 3s for 8 bugs in trunk vs 58s for ~141 bugs in 2.5: apples vs oranges
[09:29] <vila> s/bad/bah/
[09:30] <fullermd> Hm.  That's 133 bugs less, a month after the branch.  Since it's about 5 months 'till the next branch, that means that 2.6 should have -657 bugs!
[09:32] <vila> \o/
[09:49] <vila> mgz: if you haven't started, forget about it, my RM persona said: too late ;)
[09:49] <mgz> I'vee been looking at it
[09:50] <vila> ha, thks
[09:50] <mgz> it's really three different things though, and I don't yet understand one of them, and am not convinced by one
[09:50] <vila> 3 ?
[09:51] <mgz> checking the lock count is straightforward, but lacks a test?
[09:51] <mgz> the list->dict swap for sections I don't see what the bug was previously
[09:52] <vila> aaron did add a relevant tests IIRC
[09:52] <mgz> and just changing aaron's tests to assert the things that it was calling out as suspect doesn't really seem useful
[09:52] <vila> they document the expected compatibility (or not) behavior
[09:52] <mgz> the comments are nice, but if you're leaving those issues in place, it's not really the best place for it
[09:53] <vila> well, the core issue is how far we try to stay compatible and my take is that it contradicts the aim of reducing the IOs
[09:53] <mgz> ^the problem is aaron's test mentioned in that bug, you changed to just assert that the thing that he reckoned was wrong... happened
[09:54] <mgz> so, overall the mp is probably reasonable, but I'm confused.
[09:54] <vila> the list->dict swap is covered by a failing test encountered while fixing the bug: spurious warnings were emitted because two different callers got two different MutableSection
[09:55] <vila> mgz: ok, then that's a no-go, no worries
[09:56] <mgz> right, that tests for the same section object is makes that clear
[09:56] <vila> I shouldn't have tried to get it approved anyway, when the RM says: I'm freezing, it's too late, rushing at this point is just making RM's life harder, I should know ;)
[09:56] <mgz> there's a bug you flipped from 2.6b1 -> None that was just a merge up, was that an accident or is it really not merged?
[09:58] <vila> it is merged (bzr lp:bzr/2.5 says: nothing to do), I did both cheks at different times may be I should have left the milestone
[09:58] <mgz> bug 939605
[09:58] <mgz> will be in 2.6b1 right?
[09:58] <vila> yup
[10:01] <vila> I think we should set the milestone only when marking the bug fix released and never before
[10:07] <vila> jelmer, mgz: by the way, to be clear, I'm freezing 2.6b1, no landings please ;)
[10:07] <vila> Had I started with that I wouldn't have dared asking for a review ;)
[10:09] <mgz> it's sometimes useful for targetting things that need to be done for a release
[10:09] <jelmer> vila: hah, ok
[10:09] <mgz> did <https://code.launchpad.net/~jelmer/bzr/bzr.1-launchpad-commands/+merge/97443> bounce?
[10:10] <mgz> I don't see it in the PQM queue
[10:10] <jelmer> it's still in my local mail queue
[10:10] <mgz> otherwise, vila that's already sent
[10:10] <mgz> ah, so you can just hold it till vila unfreezes.
[10:11] <mgz> good post on plugin testing jelmer
[10:11] <vila> jelmer: +1
[10:16] <vila> will reply later
[10:27] <jelmer> thanks
[10:29] <vila> jelmer: by the way, any news about bzr-notify dangling progress dialog ?
[10:36] <jelmer> vila: haven't worked on that yet
[10:37] <vila> sumbitting 2.6b1 to pqm
[11:04] <jelmer> vila: let me know when I can flush my mail queue :)
[11:05] <vila> jelmer: I will, waiting for pqm and that's already conflict with my immediate schedule which includes a meeting off the internet in 10 minutes at an 8-minute cycle ride ;)
[11:06] <mgz> ...98% done, but I'm not sure you can do everything remaining in 2 minutes :)
[11:10] <vila> 2.6b2 open submitted, will finish 2.6b1 later
[11:10]  * vila runs
[12:25] <vila> uuurgh, http code 502: Bad Gateway when submitting :-/
[12:58] <vila> jelmer, mgz: 2.6b2 opening landed, trunk is free for landing
[13:06] <jelmer> \o/
[13:37] <jelmer> hmm
[13:37] <jelmer> ValueError: 0 not in range -2147483648 to 2147483647
[13:37] <mgz> ehehe
[13:38] <vila> use a bigger 0
[13:41] <vila> mgz: re-reading the log:
 it's sometimes useful for targetting things that need to be done for a release
[13:42] <vila> well, strictly speaking what *needs* to be done for a release ought to be marked critical
 otherwise, vila that's already sent
[13:42] <vila> ECANTPARSE
[13:43] <vila> At the time I thought you meant you sent your review but there is nothing there so I was probably wrong ;)
[15:27] <lamalex> is it possible to hook into bzr config from a hook/plugin?
[15:32] <vila> well, yeah, there are hooks there, what's your need ?
[15:32] <vila> bzr help hooks
[15:34] <vila> lamalex: ^
[15:35] <lamalex> jsut for some general configuration. i was wondering if there was already bzr api for using the bzr configuration, rather than rolling my own
[15:36] <vila> bzrlib.config is the code, doc/developers/configuration.txt and dov/developers/new-config-rationale.txt may be worth a read too
[15:37] <lamalex> thanks
[15:38] <vila> lamalex: if you have a use case that is not covered I'd love to hear about it ;)
[15:38] <lamalex> i will let you know after some light reading :)
[15:38] <vila> k
[16:19] <jml> hey
[16:19] <jml> I'm making a script to deplo udd to an ec2 instance
[16:19] <jml> it needs openid credentials for the launchpad stuff
[16:19] <jml> any thoughts on which user I should use in that script?
[16:21] <mgz> ~james_w clearly :)
[16:22] <jml> heh heh
[16:22] <jml> there are three approaches I can think of
[16:22] <mgz> can you just make a new one? there are various robotty things, but there's some benefit to keeping them single purpose
[16:22] <jml> one is to use a fixed use
[16:22] <jml> user, rather
[16:22] <jml> the other is to re-use the credentials of the person firing up the instance
[16:23] <jml> and the third is to make a new user every time
[16:23] <mgz> I think I favour option 1.
[16:23] <jml> mgz: I can do that. I wonder what LP would think about it.
[16:23] <jml> I guess I should ask them.
[16:23] <vila> jml: what's the purpose of the ec2 instance ? Replacing the jubany one ?
[16:24] <jml> vila: integration testing.
[16:24] <vila> no write access to lp then right ?
[16:24] <jml> vila: uhh, I think I would want it to be as close to production as possible
[16:25] <jml> vila: but I mostly care about emulating the instance on hadar
[16:25] <jml> vila: and maybe that only has r/o acccess
[16:25] <mgz> jml: we have ~bzr-build-bot for instance just for running things on ec2
[16:25] <vila> jml: uhh ? writing to staging then ? You don't want to interfer with the real one right ?
[16:26] <jml> vila: I don't understand.
[16:26] <mgz> if you can get away with not talking to production launchpad creating a new user each time would be more practical
[16:26] <vila> jml: you don't want to create the same branches than the importer on jubany right ?
[16:27] <jml> vila: I'm not creating branches at all. I'm not using lp:udd for anything to do with branches :)
[16:28] <vila> then I don't understand what you're using it for :)
[16:31] <jml> vila: lp:udd contains a highly robust, field-tested package monitoring system. We're using that.
[16:32] <vila> ok, no need for write-access then (AFAIR)
[16:32] <jml> yeah, I don't think so.
[16:32] <jml> but lifeless insists that the read access be authenticated.
[16:33] <vila> then I'd go for 2 or 3 (a dedicated user or the one starting the instance), if anything goes wrong you'll get some trail (sp?)
[16:34] <jml> 'trail' is correct.
[16:34] <vila> yeah, so he can kill your bot if needed ;)
[16:34] <james_w> jml, does anonymous with a distinctive token name suffice for him?
[16:34] <jml> james_w: no, it does not, IIRC. Let me find the thread...
[16:35] <jml> hmm. I think I might have said user-agent rather than token name...
[16:35] <james_w> I think they are equivalent in lplib
[16:35] <james_w> I think it uses the token name in the user agent
[16:35] <jml> james_w: https://bugs.launchpad.net/udd/+bug/906846
[16:38] <james_w> thanks
[16:42] <jml> I'm going to be lazy and go with 1 for now. :\
[18:05] <kevin|> Kbulgrien is idle?
[18:14] <kevin|> Given a shared bazaar repository at: /repo and a branch at /repo/prj/bra that contains a folder structure like top/mid/bot, is it possible to make a new branch /repo/prj/mid that has a root at mid of top/mid/bot? IE. A checkout of /repo/prj/mid results in a copy of mid/bot and nothing else from top.
[18:16] <mgz> kevin|: depends exactly what your goal is
[18:19] <mgz> doing `bzr branch prj/bra prj/tmp && bzr split prj/tmp/top/mid && mv prj/tmp/top/mid prj && rm -rf prj/tmp`
[18:19] <mgz> is literally what you're asking for, but perhaps not what you really want.
[18:21] <mgz> partial checkouts haven't been implemented, so you can't work on a subset of the branch then merge it back
[18:26] <kevin|> Ok... bummer on no partial checkout but will read up on split.
[18:27] <kevin|> Thanks for the tip.
[18:35] <kevin|> Isn't bzr view partial checkout?
[18:36] <mgz> no, but it might work for what you want
[18:37] <mgz> it doesn't create a tree with only some elements, rather it restricts operations on an existing tree to a subset
[18:53] <xnox_> I'm doing the 'fake' cherrypicking a revision from trunk onto maintanance branch, why does it not offer to copy the commit message / author / fixes urls / commiters  upon bzr commit?
[18:54] <xnox_> or what is the proper way to do cherrypick and copy the commit message?
[19:04] <wgz> xnox_: nope, a nicer interface for doing cherrypicks would be good
[22:36] <poolie> hi all
[22:38] <mgrandi> hihi