[00:09] <wgrant> lifeless: Ah, that's right. WAL won't allow us to read from slaves that are partly migrated, but it will allow us to detach a slave. Which means we could do very cheap read-only, which makes handling appserver requests much easier.
[00:09] <wgrant> Doesn't help for scripts, but they're less noticable.
[00:11] <wgrant> http://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally has instructions on getting a buildd and buildd-manager up.
[00:11] <wgrant> Best to run lp-buildd in a VM, of course.
[00:11] <wgrant> But you do anyway.
[00:11] <lifeless> wgrant: thanks
[00:25] <lifeless> wgrant: selfreview that
[00:25] <wgrant> lifeless: What?
[00:25] <wgrant> Oh, the sreg thing?
[00:25] <lifeless> yeah
[00:25] <wgrant> Was considering it.
[00:25] <wgrant> Thanks.
[00:34] <wgrant> lifeless: Yay, batchnav QA.
[00:51] <lifeless> well
[00:51] <lifeless> it looks ok t obe
[00:52] <lifeless> looks ok to me
[00:52] <wgrant> It does.
[00:52] <lifeless> I don't konw what abel found
[00:54] <wgrant> And we are qa-bad.
[00:54] <wgrant> Not on that rev, though.
[00:58] <lifeless> wgrant: what on ?
[00:59] <wgrant> Expander thingy.
[00:59] <wgrant> Bug #807434
[00:59] <_mup_> Bug #807434: Replace source package files, publishing history and similar bug expanders <bad-commit-13438> <qa-bad> <tech-debt> <Launchpad itself:Fix Committed by danilo> < https://launchpad.net/bugs/807434 >
[00:59] <lifeless> missing bad-commit-XXX
[01:00] <lifeless> no its not
[01:00] <lifeless> just mup formatting confused me
[01:00] <wgrant> Will rollback in a sec, just checking to see whether the other one needs doing too.
[01:00] <wgrant> It's not pretty, but it doesn't seem to be broken.
[01:00] <StevenK> spiv: O hai, you haz QA
[01:03]  * wgrant rolls back.
[01:04] <spiv> StevenK: for #702024 ?
[01:04] <StevenK> spiv: Yup
[01:06] <spiv> The only QA I can think to do replicates the automated tests, and the change is cosmetic rather than functional.
[01:06] <wgrant> Bug #702024
[01:06] <wgrant> Is that the Unavailable thing?
[01:06] <spiv> (And would require l-osa interaction I think)
[01:06] <spiv> Yeah
[01:06] <wgrant> Let me poke at it.
[01:06] <spiv> Thanks!
[01:07] <wgrant> wgrant@mawson:~$ curl http://bazaar.qastaging.launchpad.net:8022/
[01:07] <wgrant> Available
[01:07] <wgrant> 0 connections:
[01:07] <wgrant> Looks OK.
[01:08] <spiv> wgrant: thanks!
[01:08]  * spiv goes and takes some cold&flu pills to celebrate
[01:25] <wgrant> StevenK: Poor amd64.
[01:28] <wgrant> Hm, only 3200 OOPSes from the session incident.
[01:28] <wgrant> Not so bad.
[01:29] <wgrant> lifeless: Are you investigating the abel thing?
[01:32] <wgrant> StevenK: Can I have DF
[01:32] <wgrant> ?
[01:33] <lifeless> wgrant: I've emailed him
[01:33] <lifeless> wgrant: but he didn't seem to have written anything down other than the lazr.batchnavigator MP, which is approved.
[01:33] <wgrant> Yes, I saw that yesterday and wondered what was going on.
[01:33] <wgrant> Hoped you knew.
[01:34] <lifeless> me too :>
[01:36] <wgrant> StevenK: What do you know about +initseries?
[01:36] <wgrant> https://dogfood.launchpad.net/deribuntu/grar/+initseries defaults to initialising from natty.
[01:36] <wgrant> Despite there being existing series in that distro.
[01:36] <StevenK> wgrant: "Oh God, it's full of JS!"
[01:37] <wgrant> It also won't let me add any series from the current distro...
[01:38] <wgrant> Oh, perhaps the parent series thing there is not for initialisation, just for DSDs.
[01:38] <wgrant> This is confusing *me*. This isn't good...
[01:38] <StevenK> Haha
[01:41] <wgrant> Ah, yeah, the form changes subtly.
[01:43] <wgrant> StevenK: Do I use run_jobs to run IDS jobs?
[01:43] <StevenK> Yes
[01:47] <wgrant> The logging leaves something to be desired.
[01:47] <StevenK> The logging infrastructure that the job system provides is non-existant.
[01:48] <StevenK> There is no way to get at the logger object inside the job's run() method
[01:51] <wgrant> :)
[02:12] <lifeless> wgrant: ever seen:
[02:12] <lifeless> ~$ virsh console lp-builder
[02:12] <lifeless> Connected to domain lp-builder
[02:12] <lifeless> Escape character is ^]
[02:12] <lifeless> error: internal error cannot find character device (null)
[02:12] <lifeless> StevenK: ^
[02:13] <wgrant> Nope.
[02:13] <wgrant> But it doesn't surprise me.
[02:13] <wgrant> Do you have a console-capable domain?
[02:13] <wgrant> KVM normally isn't.
[02:13] <lifeless> ah
[02:14] <wgrant> Gar
[02:14] <wgrant> WTF
[02:15] <wgrant> Why is the URL of a packageset /package-sets/${distroseries.name}/${packageset.name}...
[02:18] <poolie_> lifeless, i have seen that, i didn't work out why
[02:18] <StevenK> Surely it should be distribution/distroseries/packageset?
[02:18] <poolie_> i like the sound of "downtown deploy"
[02:18] <wgrant> StevenK: You would think.
[02:18] <wgrant> /ubuntu/natty/+packageset/core
[02:19] <StevenK> Right
[02:19] <StevenK> That sounds good
[02:19] <lifeless> poolie_: where is that typo?
[02:20] <poolie_> http://www.youtube.com/watch?v=FKCnHWas3HQ
[02:20] <poolie_> also bug 810694
[02:20] <_mup_> Bug #810694: mirror prober failed after trying to shutdown during a downtown deploy <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/810694 >
[02:37] <lifeless> poolie_: what was the initial password resulting in your ubuntu-vm-builder recipe ?
[02:37] <lifeless> (the one from dev.l.n)
[02:38] <spiv> lifeless: 'ubuntu' perhaps?
[02:40] <lifeless> tried already :P
[02:42] <lifeless> Ubuntu
[02:42] <lifeless> nope
[02:42] <lifeless> ><
[02:42] <poolie_> i don't recall
[02:47] <lifeless> ah, it totally ignored the parameter to control the user
[02:47] <lifeless> presumable ubuntu-vm-builder -> vmbuilder fallout
[02:48] <lifeless> also, hooray for network X
[03:17] <StevenK> wgrant: Your rollback just hit buildbot
[04:03] <wgrant> lifeless: We don't do backward navigation yet, do we?
[04:03] <lifeless> wgrant: next, prev
[04:03] <wgrant> But does that actually use the new backward navigation stuff?
[04:03] <lifeless> wgrant: yes
[04:03] <wgrant> :(
[04:04] <lifeless> its only broken in the corner case of less than a full batch at the start
[04:04] <lifeless> which I expect would occur only with changing data today
[04:04] <lifeless> because all the current navigators will be offset based.
[04:04] <lifeless> [or with url hacking]
[04:05] <lifeless> s/which I expect would occur only with changing data today/which cannot happen today/
[04:05] <wgrant> Are we OK to deploy with it, then?
[04:06] <lifeless> AFAICT yes, but its friday ... figuring abel can answer what he found when he shows up
[04:25] <LPCIBot> Yippie, build fixed!
[04:25] <LPCIBot> Project devel build #891: FIXED in 5 hr 37 min: https://lpci.wedontsleep.org/job/devel/891/
[04:36] <lifeless> wgrant: are you and free sorting out the tc* name?
[04:36] <lifeless> bah
[04:37] <lifeless> long poll project name.
[04:37] <wgrant> I haven't discussed it since it was mentioned last night.
[04:37] <lifeless> I'm going to ignore it from now on; AIUI he would like a implementation agnostic name.
[04:37] <wgrant> It will probably end up as txwebnotify, but we'll see :)
[04:37] <wgrant> Yeah
[04:38] <lifeless> webevent
[04:38] <lifeless> httpevent
[04:38] <lifeless> push
[04:38] <lifeless> (some arbitrary suffixes to play with)
[04:43] <spiv> tenfoot
[04:43] <spiv> (it's a long pole!)
[04:43] <lifeless> kill me now
[04:43] <lifeless> !
[04:44] <wgrant> That's a very Twisted name, though.
[04:44] <LPCIBot> Project db-devel build #723: STILL FAILING in 5 hr 43 min: https://lpci.wedontsleep.org/job/db-devel/723/
[04:44] <lifeless> spiv: (nice one)
[04:45] <lifeless> wgrant: overly cute pehraps
[04:46] <spiv> lifeless: :)
[04:50] <wgrant> lifeless: Yes, very Twisted.
[05:31] <StevenK> Hm, how do we QA r13437?
[05:33] <lifeless> its live
[05:33] <lifeless> therefore its ok
[05:33] <StevenK> lifeless: Marking as qa-ok, then
[05:34] <StevenK> Then aside from r13413 and the pending rollback of r13438, we look in okay shape
[05:34] <lifeless> cool
[05:35] <lifeless> when abel gets up, someone should ask him about 413
[05:35] <lifeless> I should be around
[05:36] <StevenK> Right, and the only QA to do will be one rev of wgrant's, but that won't be for roughly four hours.
[05:36] <StevenK> But then it's probably too late to deploy until Monday morning.
[05:37] <lifeless> yup
[05:57]  * StevenK wishes qas didn't take an hour to update
[06:14] <spm> patches accepted
[06:44]  * StevenK waits for wallyworld_ to review his branch, since he's already claimed it.
[06:45] <StevenK> wallyworld_: I've just pushed a new rev that removes one line of extraneous whitespace
[06:45] <wallyworld_> StevenK: thans, just about to +1 it :-)
[06:46] <wallyworld_> sorry for stealing it, it's my first and only one today
[06:46] <spm> wallyworld_: may I suggest a -1 due to excessive impatient impertinence?
[06:46] <wallyworld_> lol
[06:46] <StevenK> wallyworld_: I am of the opinion that it's too large to self-review, so it's perfectly fine.
[06:47]  * spm promotes peace and understanding via the application of a nail studded club, amongst LP developers
[06:47] <wallyworld_> ooh, studs. now you're talking
[06:47] <spm> ... tmi.
[06:47] <StevenK> Now. Look. What. You've. Done.
[06:47] <spm> clearly it's all your fault StevenK. you started this.
[06:50] <nigelb> I thought some bored LOSA started it :P
[06:50]  * nigelb yawns and stretches
[06:50] <wallyworld_> StevenK: i assume you changed the vocab because the users of the vocab wanted to pass in spn instead of dsp?
[06:51] <nigelb> I wish a very painful death to telemarketeers who wake you up the day you pull an all-nighter
[06:51]  * wallyworld_ wishes the same thing to *ant* telemarketer
[06:51] <wallyworld_> any
[06:51] <StevenK> wallyworld_: I changed it due to sinzui's e-mail of this morning.
[06:52]  * wallyworld_ looks at email
[06:53] <wallyworld_> makes sense now :-)
[07:06] <StevenK> wallyworld_: You'll prod jtv to mentor?
[07:33] <wallyworld_> StevenK: yes
[07:34] <wallyworld_> StevenK: you may want to cut'n'paste a bit of the email which mentioned the need for the change into the mp description
[07:38] <wallyworld_> StevenK: jtv is away today (national holiday). maybe wgrant can +1
[08:03] <mrevell> Hey
[08:06] <adeuring> good morning
[08:11] <lifeless> adeuring: hi
[08:11] <bigjools> morning
[08:11] <lifeless> adeuring: so batchnav
[08:12] <lifeless> adeuring: you should land your patch and do a release :) - but more importantly, is lp ok at the moment with the simple offset based batches?
[08:12] <lifeless> adeuring: (thinking qa for Revision 13413 )
[08:13] <adeuring> lifeless: yeah... real QA is hard for such a change that affects each batched view. Any suggestions?
[08:15] <StevenK> jtv: Can you please mentor wallyworld_'s review of https://code.launchpad.net/~stevenk/launchpad/dsp-vocab-use-spn/+merge/68046 ?
[08:16] <lifeless> adeuring: play with as many as we can - its how I found the change needed in 1.2.5
[08:16] <lifeless> adeuring: I have been playing since that hit qastaging and couldn't break it (without url hacking)
[08:16] <lifeless> adeuring: I grepped for similar things too
[08:16] <adeuring> lifeless: ok.
[08:17] <lifeless> adeuring: how did you find that direction=forwards issue ?
[08:17] <adeuring> lifeless: by reading the source code
[08:17] <lifeless> adeuring: ah, fresh eyes!
[08:18] <adeuring> lifeless: can you tell me how to do a release of for lazr.batchanv?
[08:19] <lifeless> adeuring: https://dev.launchpad.net/ReleaseChecklist
[08:19] <adeuring> thanks
[08:19] <lifeless> its pretty much what I followed
[08:19] <lifeless> uhm, you will need to be added to the pypi maintainer list for projects
[08:20] <lifeless> I need to spend family time, so perhaps you can get flacoste to do that in ~ 4 hours
[08:20] <lifeless> the pypi registration step is the last step so its not a blocker for updating LP
[08:28] <bigjools> wgrant: hi - did you get a chance to look at my copyPackage branches?
[08:30] <wgrant> bigjools: I think we should confirm that PCJs work first.
[08:31] <bigjools> they do
[08:32] <wgrant> I doubt it.
[08:32] <wgrant> I don't see how some cases work.
[08:32] <wgrant> eg. announcements of copies into Ubuntu.
[08:33] <bigjools> so, rather than a blanket "they don't work" I think I'd appreciate it if you were more specific like that from the start
[08:34] <wgrant> Well, AFAICT PCJs had a few missing bits hacked together by Steve, then he was repossessed by our squad and nobody verified that PCJs were actually complete.
[08:34] <StevenK> Ah. ENOJTV
[08:34] <wgrant> And this will enable copying into Ubuntu, so a thorough verification of their correctness needs to be performed.
[08:34] <StevenK> Who wants to mentor wallyworld_'s review, then? :-)
[08:39] <bigjools> wgrant: can you name any specific parts that you know don't work as expected?
[08:40] <wgrant> bigjools: I need to leave for a while in a moment, but will return in an hour or so.
[08:41] <wgrant> bigjools: But things like build notifications, copy announcements, etc. for copies into the Ubuntu primary archive are, I'm pretty sure, not going to work.
[08:41] <wgrant> We've already seen that notifications are not reliable.
[08:41] <wgrant> In some cases they crash.
[08:41] <wgrant> They are likely to email the wrong people, because we have no way to track who the right people are.
[08:42] <wgrant> The security code has not been checked since the last few rounds of improvements were made.
[08:42] <bigjools> security code?
[08:42] <wgrant> The interfaces are weak so it's hard to verify that everything is going to work, but we need to try.
[08:42] <wgrant> This moves security into the model.
[08:42] <wgrant> From the security adapters.
[08:42] <wgrant> This is scary.
[08:42] <StevenK> adeuring: O hai, you're fine to do OCR today?
[08:42] <bigjools> the adapter can never work
[08:43] <wgrant> Sure.
[08:43] <wgrant> But the new approach needs to be approached with great skepticism.
[08:43] <bigjools> we are now using the very tried and very tested checks that have always been there
[08:43] <wgrant> Their integration is not tried, tested, nor trustworthy.
[08:43] <bigjools> yes, that's exactly why I wanted your opinion
[08:43] <bigjools> but this is counterproductive
[08:44] <StevenK> I think you just got his opinion, in spades.
[08:45] <wgrant> The recent implementations of PCJs and series initialisation need a lot of checking, because they were developed by hacking existing code to pieces and reassembling it and grafting on other refactorings until they did roughly what was required.
[08:46] <wgrant> We are now trying to push them out without cleaning them up or checking that they work.
[08:46] <bigjools> sorry but you are talking out of your arse
[08:46] <adeuring> StevenK: sure, need a review?
[08:47] <StevenK> adeuring: Sort of. A mentor of wallyworld_'s review -- https://code.launchpad.net/~stevenk/launchpad/dsp-vocab-use-spn/+merge/68046
[08:47] <adeuring> StevenK: ok, I'll look
[08:47] <StevenK> adeuring: Thank you.
[09:22] <adeuring> StevenK: +        dsp = self.context.getSourcePackage(spn)
[09:22] <StevenK> adeuring: What about it?
[09:23] <adeuring> StevenK: this assumes that self.context is not None, but: def __init__(self, context=None):
[09:23] <StevenK> It does, yes
[09:23] <adeuring> so, this breaks if no context is given
[09:23] <StevenK> adeuring: This vocab is used nowhere else yet
[09:24] <adeuring> StevenK: ok, so, then we can drop the "=None" from the __init__() parameters?
[09:25] <StevenK> Hm, sure
[09:25] <adeuring> StevenK: I mean, the =None is an invitation to create the vocab without a context, but that would explode :)
[09:29] <adeuring> StevenK: r=me with this change
[09:30] <StevenK> adeuring: Thanks! Changes pushed.
[09:30] <adeuring> StevenK: cool
[09:32] <wgrant> bigjools: Are PCJs tested with binaries at all?
[09:32] <wgrant> It seems they allow binary copies, but only source overrides.
[09:32] <wgrant> Not sure what is going to blow up if someone copies binaries into Ubuntu without overrides...
[09:33] <wgrant> The security seems OK.
[09:37] <bigjools> wgrant: this is the first 2 branches in a pipeline, I need to make some other changes yet, like feature flag checking and binary copying.  Thank you for checking the security.
[09:38] <wgrant> bigjools: Oh, so this is to be behind a feature flag?
[09:38] <bigjools> in fact I will probably deny binary copying for distros for now; eventually we want to use it for security uploads
[09:39] <bigjools> that's the plan
[09:39]  * bigjools curses code that passes logger objects around
[09:42] <wgrant> If I'd known you'd not planned to land this as is, I would have been far less likely to decry it as dangerous madness. As presented, the branches suggested that you considered the functionality complete and finished and ready for widespread use, which seems somewhat premature given the complexity of the issues at hand.
[09:43] <wgrant> I still contend that PackageCopyJobs are, in their present form, a hackjob with only slightly fewer special cases than delayed copies, but at least they have good promise for being cleaned up and destroying delayed copies :)
[09:45] <wgrant> I also need to think about how copy/build notification recipients should work.
[09:45] <wgrant> Have you considered that at all?
[09:45] <wgrant> There is potential for great misdirected spammage.
[09:46] <wgrant> I was hoping StevenK could look at that after the initial notification fixup, but that was not to be :(
[09:47] <jtv> wgrant: I suspect that for the foreseeable future, soyuz changes will always be immature.
[09:48] <jtv> Pointing it out with words like "hackjob" is a bit like pressing a "panic" button too often though; it can distract from the work that needs doing to make things better.
[09:48] <jtv> Lots of stress involved.
[09:49] <jtv> I find it takes a substantial mental effort to get past those terms and into constructive detail.
[09:52] <jtv> wgrant: Wouldn't be an issue in low-blood-pressure situations, but as long as we're not in one, please beware of the inadvertent damage from blanket judgments!
[10:08] <wgrant> jtv: Soyuz changes will always be immature, yes. But for copies, perhaps more than anything else in this project, it must be avoided. They are complex, fragile, badly understood, and most mistakes are of great consequence. Perhaps one day we will unify and clean the copiers up... but until then calling them by any positive term would be a dangerous misrepresentation of the situation.
[10:16] <jtv> wgrant: not arguing any of that; I believe you.  I'm saying that in this situation of pressure and uncertainty, you need to be careful how you say these things.  Be specific about your concerns, keep them somewhere visible, state them in terms of what needs doing about them so that people can see progress towards their goals and aren't made to feel (unintentionally I know, but I'm pointing out that pressure isn't rational!) that they do a bad job, 
[10:17] <jtv> Trust me, I'm middle-aged now.
[10:18] <nigelb> Can't argue that ^
[10:18]  * nigelb ducks
[10:18] <jtv> Hey, I can say it; you are supposed to go "you don't look a day over 39½!"
[10:19] <nigelb> haha
[10:20] <wgrant> jtv: Is it worth adding the config setting?
[10:20] <bigjools> jtv: you've always been middle-aged
[10:20] <wgrant> jtv: Given that it is deprecated?
[10:21] <jtv> It's _almost entirely_ deprecated.
[10:21] <wgrant> Isn't the migrator the only thing that remains?
[10:21] <jtv> Exactly.
[10:21] <wgrant> Any reason not to hardcode it and delete it in three weeks?
[10:22] <wgrant> Oh, tests, I guess.
[10:22] <wgrant> Grar.
[10:22] <jtv> The tests went across with remarkable ease, though it's nice to know that the migration itself can be tested and automated.
[10:27] <LPCIBot> Yippie, build fixed!
[10:27] <LPCIBot> Project db-devel build #724: FIXED in 5 hr 42 min: https://lpci.wedontsleep.org/job/db-devel/724/
[10:47] <danilos> wgrant, hi, if you are still around, perhaps you'd want to review a very simple fix for DSP:+index expanders?
[10:49] <danilos> wgrant, fwiw, you rolled back the wrong revision :(
[10:51] <wgrant> danilos: Argh, sorry. The bug was linked, and I saw distributionsourcepackage-publishinghistory in there, and mistook it for distributionsourcepackage-index.
[10:52] <danilos> wgrant, no worries, I'll reland that revision, and a fix for the problem you noticed as soon as it goes through ec2 (just to be extra careful, some tests might be expecting IMG tag in there which we don't need anymore)
[10:52] <wgrant> danilos: Have you checked all the others?
[10:52] <wgrant> I only checked up to the first issue.
[10:52] <wgrant> And unless we're sure it's all fine we should roll it all back.
[10:53] <danilos> wgrant, what do you mean? I can't QA the revision until it is on qastaging, and it's already up to your rolled-back revision
[10:53] <wgrant> danilos: Well, this sort of stuff is fairly QAable locally.
[10:53] <danilos> wgrant, as for the problem in previous revision, how do I look for other togglers on packages?
[10:54] <danilos> wgrant, well, I did QA everything locally, but I missed it because same JS integrated in the archive-macros.pt was used on two different pages implicitely
[10:54] <wgrant> Ahh, fun fun.
[10:54] <danilos> wgrant, I QAd only the PPA:+packages page
[10:54] <danilos> wgrant, thinking I am good
[10:54] <wgrant> Yeah.
[10:54] <wgrant> I am glad we are cleaning this stuff up.
[10:55] <wgrant> So, I guess see if you can grep around a bit further, and if not I will just look everywhere on Monday, I guess.
[10:56] <danilos> wgrant, I did grep for treeCollapsed, but I guess I missed this one case :/ (there are a few others left which I am not fixing because of the lack of time, and this one was in registry as well :/)
[10:56] <wgrant> Yeah.
[10:58] <wgrant> Still, I am impressed at the lack of any other breakage.
[10:58] <wgrant> Considering all the cleanup.
[11:01] <danilos> wgrant, heh, thanks, I did try to be very careful with QA, and you can look at QA URLs in my MPs to see the number of URLs I had to get to to test stuff out (finding proper places for that was sometimes harder than migrating the template/JS)
[11:01] <wgrant> danilos: Yes. I opted to check all the expanders I knew about, because it's all so intertwined.
[11:01] <wgrant> Little other choice :(
[11:02] <wgrant> Still, progress!
[11:02] <danilos> wgrant, indeed
[11:05] <danilos> wgrant, I suppose you don't have time to review https://code.launchpad.net/~danilo/launchpad/fix-806925/+merge/68070 then? :)
[11:05] <danilos> adeuring, can you please look at https://code.launchpad.net/~danilo/launchpad/fix-806925/+merge/68070 (it's very short)
[11:05] <adeuring> danilos: sure
[11:07] <danilos> thanks
[11:18] <adeuring> danilos: r=me
[11:19] <danilos> adeuring, thanks
[11:27] <danilos> adeuring, I've stuck in another expander replacement in the same template fwiw, can you please glance at it and check if it's ok as well?
[11:27] <adeuring> danilos: sure
[11:28] <danilos> adeuring, it's in diff from line 27 onwards, QA on https://launchpad.dev/ubuntu/+source/iceweasel (because there are PPAs for that)
[11:31] <adeuring> danilos: still looks good!
[11:31] <adeuring> r=me
[11:31] <adeuring> again
[11:31] <danilos> adeuring, heh, thanks (again :))
[11:57] <sumanah> hi, bac, still working on that summary and will get it to you in the next hr
[11:57] <sumanah> https://dev.launchpad.net/UI/Reviews?action=show&redirect=UserInterfaceReviewNotes#Tips%20for%20reviewers will be pretty useful I think!
[12:01] <maxb> stub: problems? :-)
[12:18] <bigjools> adeuring: hi, can I get a review please! https://code.launchpad.net/~julian-edwards/launchpad/pcj-requester-bug-810957/+merge/68081
[12:22] <bac> morning adeuring
[12:22] <adeuring> hi bac
[12:26] <bac> adeuring: i am grabbing ian's first branch, unless you've already started it
[12:27] <adeuring> bac: no, I haven't  (working purely "Interrupt dirven" this morning )
[12:27] <bac> adeuring: ok.  claimed.
[12:56] <sumanah> bac: working on a summary of how Launchpad does code review & deployment -- can you give me a link about the template merge proposal that you can do via email?  I look at https://help.launchpad.net/Code/Review and it links to http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#sending-changes which does not exist
[12:57]  * bac looks
[12:57] <sumanah> and http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/sending_changes.html does not mention the template
[12:57] <bac> sumanah: https://dev.launchpad.net/Code/BzrSend
[12:57] <sumanah> aha! thanks bac
[12:57] <sumanah> you can see how far I've gotten in Gobby
[12:59] <sumanah> "The lpreview_body plugin will pre-populate the message body with our standard template, plus lint output." ooh, I'm going to look at that plugin to see what your template is!
[13:01] <deryck> Morning, all.
[13:02] <sumanah> http://bazaar.launchpad.net/~launchpad/lpreview-body/trunk/view/head:/body_callback.py got it.
[13:06] <abentley> bac, sumanah: bzr send hasn't worked for a couple of years.
[13:07] <bac> abentley: what is the replacement then?
[13:08] <abentley> bac: there is no replacement.
[13:09] <abentley> bac: The technical issue is that installing a bundle is incompatible with stacked branches.
[13:09] <adeuring> rvba: your branch init-series-not-close-bugs looks good but I think it could have at least one more test: the new test test_multiple_parents_close_bugs should check that the bug created in the test is not closed (and... shouldn't the test method's name include a 'nit'?)  . And do we already have tests that ensure that the other callsite of the packagecopier does indeed close bugs?
[13:11] <rvba> adeuring: Thanks for reviewing this branch. I think I'll add the check to the existing test.
[13:11] <adeuring> rvba: thanks!
[13:11] <rvba> adeuring: about the other callsites, I'm not really sure ... but I *suppose* we do have check for this.
[13:11] <rvba> I'll have a look, just to make sure.
[13:11] <adeuring> rvba: cool, thanks
[13:12] <bac> abentley: i'm confused between 'bzr send' and lpreview/lpreview_body
[13:12] <abentley> bac: bug #718723
[13:12] <_mup_> Bug #718723: fetch from merge directive to stacked branch unable to fill in chk pages <oops> <regression> <Bazaar:Confirmed> <Launchpad itself:Triaged> < https://launchpad.net/bugs/718723 >
[13:12] <bac> abentley: i've continued using 'bzr send --no-bundle' to create my MPs
[13:13] <rvba> adeuring: BTW, the branch we are talking about depends on ~rvb/launchpad/perm-distributionjob-bug-808680/+merge/68059.
[13:13] <abentley> bac: Yes, if you use --no-bundle, that probably works, but it means you have to manually upload the branch first.
[13:13] <rvba> adeuring: If you have time, I'll be glad to have a review for this branch as well.
[13:14] <bac> abentley: i always push first.
[13:14]  * bac assumed that was standard workflow
[13:14] <abentley> bac: However, lp-propose does it all over the API instead of using email, and it does the push for you, so it's more convenient and has basically replaced "send"
[13:14] <abentley> bac: lp-propose also supports prerequisite branches, unlike "send".
[13:14] <bac> abentley: ok.  is there a wiki page?
[13:14] <sumanah> abentley: does it include a template for the merge proposal?
[13:15] <abentley> sumanah: the lpreview_body plugin provides the template for lp-propose (as well as send).
[13:15] <sumanah> aha
[13:15] <abentley> bac: for lp-propose? No, it's a bzr command.
[13:16] <abentley> bac: Part of the launchpad plugin which ships with bzr.
[13:16] <adeuring> rvba: sure, I'll look at that one too
[13:16] <rvba> adeuring: thanks/
[13:16] <rvba> thanks!*
[13:17] <bac> abentley: ok.  thanks.  we should dismantle the wiki page i posted
[13:17] <abentley> bac: There is https://lists.launchpad.net/launchpad-dev/msg06026.html
[13:18] <sumanah> bac, abentley - & point to http://doc.bazaar.canonical.com/plugins/en/launchpad-plugin.html ?
[13:19] <abentley> sumanah: That's the standard command help.
[13:19] <sumanah> abentley: sure seems like it, yes :-)
[13:20] <abentley> sumanah: I would not point at it, because people can get it from the commandline, and it will be the help that is accurate for their version.
[13:20] <sumanah> abentley: I'm documenting how Launchpad does its code review process, so my colleagues can use it as an example, so I need to point them to documentation of the tool support/infrastructure that you use as well
[13:21] <abentley> bac: did you see my messages yesterday?
[13:22] <sumanah> abentley: the people reading my summary will not have bzr installed, much less this plugin, so I would rather point them to a webpage with relevant documentation of this part of the process
[13:23] <bac> abentley: i did
[13:23] <abentley> sumanah: If it's your documentation, then of course it's your call.
[13:23] <bac> abentley: i've worked through most of the hurdles on that branch
[13:24] <sumanah> abentley: seems like you'd want reasonable documentation in the public eye -- on the web somewhere -- for the community devs, no?
[13:24] <abentley> bac: excellent.
[13:25] <sumanah> abentley: and point to it from the dev.launchpad wiki?
[13:25] <abentley> sumanah: If you want to document it for us, please put it on the wiki, rather than pointing to it.
[13:26] <sumanah> abentley: I'm surprised you didn't update https://dev.launchpad.net/Code/BzrSend when you sent that msg in Dec 2010
[13:26] <abentley> sumanah: I'm not.  I was just trying to get the word out.  And at that point, I had some hope that "send" would eventually be fixed.
[13:26] <sumanah> abentley: what's inaccurate about http://doc.bazaar.canonical.com/plugins/en/launchpad-plugin.html ?
[13:28] <abentley> sumanah: If you're using an older version of bzr, lp-find-proposal won't exist, for example.
[13:28] <abentley> I wrote that in the last year.
[13:30] <sumanah> I am the least expert person in this conversation and likely to introduce errors in any documentation I write about this plugin, but .... aaand I get an error even trying to log in to the dev.launchpad wiki.
[13:31] <henninge> deryck: still travelling but almost back
[13:31] <sumanah> aha, it's because I have an OpenID. http://moinmo.in/MoinMoinBugs/OpenID%20login%20to%20Ubuntu%20wiki%20fails?highlight=%28\bCategoryMoinMoinBug\b%29
[13:31] <deryck> henninge, ok, np
[13:49] <sumanah> bac: ok, I cannot log into the dev.launchpad MoinMoin wiki (bug filed), so thanks for updating https://dev.launchpad.net/Code/BzrSend
[13:49] <sumanah> or rather, even though I am logged in, I can't edit
[13:53] <abentley> bac: I don't know what happened, but when you merged from me today, you didn't get three revisions that I committed yesterday.
[13:54] <bac> abentley: sorry, i did see your note yesterday but haven't done the merge yet.  didn't know you'd be grabbing my branch.
[13:54] <bac> i'll do it now
[13:54] <abentley> bac: Oh, my bad.  The merge I'm looking at wasn't today.
[13:55] <abentley> bac: If you could, that would be great, so we can get synced up.
[13:56] <bac> abentley: merging from yours now.  will let you know when i've pushed
[14:03] <adeuring> rvba: r=me for your init-series-not-close-bugs branch
[14:12] <bac> abentley: pushed, though i've still got work to do on the branch.
[14:13] <abentley> bac: I have it working (with some hacks to the old version of your code) on the translation sharing details page.
[14:13] <bac> cool
[14:17] <rvba> adeuring: Thanks (sorry for the delay, OTP). Instead of checking the bug's status I'll use the fakemethod trick to make sure the close_bugs_... method has not been called. It's best to do that because that is precisely what this test wants to check (as opposed to calling the method and failing with a permission denied error)
[14:17] <bigjools> adeuring: hi, can I get a review please! https://code.launchpad.net/~julian-edwards/launchpad/pcj-requester-bug-810957/+merge/68081
[14:17] <adeuring> rvba: sure, makes sense
[14:18] <adeuring> bigjools: sure
[14:18] <bigjools> thanks
[14:26] <abentley> bac: Your latest changes work for me, with this patch: http://pastebin.ubuntu.com/644806/
[14:27] <bac> abentley: yeah, that makes sense
[14:36] <sumanah> bac: it's a bit difficult to search for information about how you deploy Launchpad -- is there an overview I am missing about your deploy/release process
[14:36] <sumanah> ?
[14:37] <sumanah> bac: I see https://dev.launchpad.net/QAProcessContinuousRollouts  -- aha, points to https://dev.launchpad.net/MergeWorkflow .  Is that reasonably accurate?
[14:39]  * bac reads
[14:39] <bac> sumanah: https://dev.launchpad.net/QAForContinuousRollouts?highlight=%28qa%5C_reports%29
[14:40] <bac> er, https://dev.launchpad.net/QAForContinuousRollouts
[14:41] <sumanah> thank you bac!   I should be looking for "rollout" and its variations rather than "deploy"
[14:52] <sumanah> mrevell: I appreciate the wordplay & graphics in your blog posts :-)
[14:53] <mrevell> thanks sumanah :)
[14:54] <adeuring> bigjools: your branch looks good. I don't see any usage of the job.requester, but I assume that will follow in another branch?
[14:54] <bigjools> adeuring: correct!
[14:54] <bigjools> was just doing this separately for ease of review
[14:55] <adeuring> bigjools: ok, so r=me (I appreciate that your deferred implementing the usage here -- would have made the branch even longer ;)
[14:55] <bigjools> adeuring: well the other reason is that I have another branch in progress but it depends on this before I can fix it further. :)
[14:55] <bigjools> adeuring: thanks for reviewing
[14:59] <sinzui> deryck, I want to nuke lib/lp/scripts/utilities/lpwindmill.py and its only caller, bin/jstest. Are these oversites from our removal of windmill?
[15:00] <sinzui> s/oversites/oversights/
[15:01] <deryck> sinzui, yes, just oversite.  I mean to go back and remove them.  Kill at will. :)
[15:04] <sinzui> :)
[15:18] <flacoste> danilos: what's the story behind qa-bad of bug 806925?
[15:18] <_mup_> Bug #806925: Replace bug task, ppa details and package details expanders <bad-commit-13421> <qa-bad> <tech-debt> <ui> <Launchpad itself:Fix Committed by danilo> < https://launchpad.net/bugs/806925 >
[15:18] <flacoste> there are is no comment on the bug
[15:31] <gary_poster> flacoste, what I know is this: a branch is landing now, and will hopefully be ready for qa later today
[15:31] <gary_poster> that's according to our kanban board and morning call
[15:33] <gary_poster> henninge, am I right that a question about why https://translations.launchpad.net/babelenterprise/+imports has not been approved should be transferred to the babelenterprise project?
[15:34] <flacoste> gary_poster: thanks
[15:34] <gary_poster> yw
[15:34] <gary_poster> oh, no, this guy asking is the owner of the project
[15:34] <henninge> gary_poster: No, approvals still need to be done either automatically by the script or by a lp engineer
[15:34] <henninge> "the autoapprover script"
[15:35] <gary_poster> henninge, so should it have shown up here for lp devs to review https://code.launchpad.net/+code-imports?field.review_status=NEW ?
[15:36] <henninge> gary_poster: that's code imports, you were asking about transltion imports.
[15:36] <gary_poster> and henninge, can I just approve this poor guy so he can move on with his life, or do I need to...check something first?
[15:37] <gary_poster> henning, aygh!  https://translations.launchpad.net/+imports/+index?field.filter_target=[PRODUCT]&field.filter_status=NEEDS_REVIEW&field.filter_extension=pot
[15:37] <gary_poster> augh I mean
[15:37] <henninge> gary_poster: yes, you can approve. That is part of CHR duties (until we fix that)
[15:37] <gary_poster> looks like there has been some confusion about who needs to do what since the thunderdome
[15:37] <henninge> gary_poster: I was told orange did CHR last week (I was on leave)
[15:38] <henninge> gary_poster: but I can work down that queue fairly quickly I think
[15:38] <gary_poster> (yeah henning, I think danilos did not realize we were on CHR this week somehow, even though we talked about it :-( )
[15:39] <gary_poster> thank you henninge!  I'd really appreciate it
[15:39] <henninge> np
[15:40] <henninge> argh ...
[15:40] <henninge> bad file naming
[15:44] <henninge> gary_poster: actually, I will not approve them and you shouldn't either
[15:44] <gary_poster> ok henninge
[15:45] <gary_poster> henninge, is there a quick reason why?
[15:46] <gary_poster> (I'd like to reply to the question too, https://answers.launchpad.net/launchpad/+question/163067)
[15:46] <henninge> gary_poster: I will ask the uploader to rename the files so that the template name is extracted automatically
[15:47] <henninge> all the files are named translations/translations.pot
[15:47] <henninge> but they should be modulename.pot
[15:47] <gary_poster> ok henninge.  So I can close the question, saying that we have replied to the translation request with details on what to fix?
[15:47] <henninge> gary_poster: hang on, let me look at the question first
[15:47] <gary_poster> ok
[15:49] <henninge> gary_poster: there is only one file in their queue and it is not approved automatically because es_es.po is not supported by Launchpad, it should be es.po.
[15:50] <gary_poster> ah ok
[15:50] <henninge> gary_poster: you can either approve it to spanish or ask them to re-upload with the correct name.#
[15:53] <gary_poster> henninge, to approve I would go to https://translations.launchpad.net/+imports/5558326 and selevct "Spanish (es)" and click approve, yeah?  I can do taht and then suggest a change for the future in the reply
[15:53] <henninge> yes, you can do that.
[15:54] <gary_poster> ok thanks very much henninge!
[15:54] <henninge> gary_poster: you also need to pick the template
[15:54] <henninge> there is only one
[15:54] <gary_poster> ok that makes it easy, got it :-)
[15:56] <sumanah> bac, flacoste - draft sent.  Brad, I know I am getting it to you later than I said I would; can you still review today for inaccuracies?
[16:28] <jcsackett> can someone point me to where LP.cache.context gets setup?
[16:31] <abentley> jcsackett: We're in the process of changing that.  Right now, it's set up in lib/lp/app/templates/base-layout-macros.pt
[16:31] <jcsackett> abentley: ah, thanks.
[16:32] <abentley> jcsackett: In my branch, it comes out of lib/canonical/launchpad/webapp/publisher.py, getCacheJSON.
[16:32] <jcsackett> abentley: that's as part of your ++cache++ stuff, right?
[16:32] <abentley> jcsackett: Right.
[16:33] <jcsackett> cool. i'm just trying to understand the current picture i'm working with. i look forwards to seeing your work land. :-)
[16:33] <abentley> jcsackett: (though we're calling it ++model++ to try to reflect its real significance)
[16:33] <jcsackett> abentley: that does seem like a better namespace.
[16:33] <abentley> jcsackett: my branch is ~abentley/launchpad/json-serialization
[16:41] <sumanah> bac: just checking -- do you think you'll be able to get me a critique today?  just looking for inaccuracies & gross omissions
[16:48] <jcsackett> abentley: do you know of any gotchas about the json cache (aside from it not working for anonymous users) that would lead to me placing something in it only to find nothing there on the page?
[16:49] <jcsackett> for context, in lib/lp/app/widgets/popup.py i'm trying to add in some global picker config options, but nothing i put in can be found once i'm on a page with a picker.
[16:49] <jcsackett> (actually, right now i'm scaled back to just trying to put a random string in).
[16:49] <bac> sumanah: yes
[16:50] <sumanah> thanks
[17:33] <abentley> jcsackett: Nothing comes to mind off the top.  Are these basic python types or exported web service entry types?
[17:35] <jcsackett> abentley: basic types. i think it may have something to do with trying to do it in the widget, rather than a view's initialize method (where every other example of adding to the cache seems to do it).
[17:36] <abentley> jcsackett: I'm not sure of the order of operations, but it's conceivable that the widget is rendered after the jsoncache.
[17:37] <jcsackett> abentley: yes, i think that's the case.
[17:38] <jcsackett> oh well, this is what i get for doing something weird. i think i'll look into other approaches.
[18:14] <jcsackett> EAT!!!	
[18:14] <jcsackett> me(g) is starting to have a bad day. 14:14	
[18:56] <abentley> deryck[lunch]: do we have a story for where test helpers go?
[19:03] <deryck> abentley, in lib/lp/app/javascript/testing/
[19:05] <abentley> deryck: Ah, okay.
[19:25]  * jcsackett sighs, having just noticed that somehow is empathy chats have been redirected into IRC.
[19:59] <m4n1sh> what is this dependency granite for maya?
[19:59] <m4n1sh> err sorry again wrong window :9
[21:41] <wgrant> Grar
[21:41] <lifeless> ?
[21:41] <wgrant> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-2022AU38
[21:42] <wgrant> Lots of checks, looks like it's checking 44 times whether the user administers any more teams.
[21:42] <wgrant> I suspect the bugsubscription stuff.
[21:42] <wgrant> Which we both identified as suspect.
[21:42] <wgrant> s/bugsubscription/structural subscription/
[21:42] <lifeless> just cause we're paranoid doesn't mean we're right...or wrong
[21:44] <wgrant> Although you put a workaround in there to stop it from executing multiple times.
[21:44] <lifeless> and tuned it somewhat as well
[21:45] <wgrant> Half the code says "administrated", another half "administered"
[21:45] <wgrant> yay
[21:45] <lifeless> that looks like either a change, or a different code path
[21:45] <lifeless> perhaps late evaluation ?
[21:46] <wgrant> Let's see if it renders on DF.
[21:46] <wgrant> And if so, traceback time.
[21:46] <lifeless> new bug time too
[21:46] <lifeless> can't see a match
[21:46] <wgrant> True
[21:48] <wgrant>   [r=jcsackett][bug=809841] 'All-Ubuntu-derivatives' option for
[21:48] <wgrant>   	process-accepted script.
[21:48] <wgrant> What could go wrong.
[21:50] <wgrant> OTOH, we are now below 300 lines of mochikit-using JS.
[21:55] <wgrant> sinzui: Does that mean we no longer depend on the hacked spidermonkey package?
[21:56] <sinzui> wgrant, correct
[21:56] <wgrant> Excellent news.
[21:56] <sinzui> I just removed the last vestiges of it 10 minutes ago
[21:56] <wgrant> And excellent deletion of embedded code.
[21:56] <wgrant> It is gone from launchpad-dependencies?
[21:56] <sinzui> it is
[21:56] <wgrant> Perfect.
[21:56] <sinzui> update and upgrade to 94
[21:57] <wgrant> Perhaps I will investigate YUI3 calendar widgets.
[21:57] <wgrant> Because this YUI2 embedded in the tree irks me greatly.
[21:59] <wgrant> Blah.
[21:59] <wgrant> The tour embeds jQuery.
[21:59] <wgrant> How unpleasant.
[21:59] <sinzui> wgrant, there were non last year
[21:59] <sinzui> wgrant, we paid for the tour, and jquery is the defacto standard or js libs
[21:59] <wgrant> sinzui: Yes, and I like it, but I do not like embedding external dependencies in our tree :)
[22:00] <wgrant> http://www.yuiblog.com/blog/2010/06/18/alloy-date-selector/
[22:02] <sinzui> We use datetime sometimes, but I wonder if that need can be factored out. datetime leads to bad notices that a release it overdue.
[22:05] <wgrant> sinzui: Are you sure you can remove python-profiler?
[22:05] <wgrant> sinzui: It provides pstats.
[22:05] <wgrant> Which the test suite uses in two places.
[22:06] <sinzui> it is identical to the pstats in py2.6
[22:06] <wgrant> Yes, but it's in a separate package because it's non-free.
[22:06] <sinzui> wgrant, I saw only comment changes in the diff
[22:06] <wgrant> It's the only part of stdlib that's in a separate package.
[22:07] <wgrant> $ dpkg -L python2.6 | grep pstats | wc -l
[22:07] <wgrant> 0
[22:07] <sinzui> oh ?
[22:07] <wgrant> python-profiler is part of the standard library, but it's a separate package in multiverse because the 'profile' and 'pstats' modules are non-free.
[22:07] <sinzui> I get 1
[22:07] <wgrant> I am on natty.
[22:07] <wgrant> Perhaps oneiric has regressed.
[22:08] <wgrant> Let me see.
[22:08] <james_w> it's free now
[22:08] <wgrant> Huh.
[22:08] <james_w> so it's in the python packages in oneiric
[22:08] <wgrant> Was declared free, or was made free?
[22:08] <james_w> pass
[22:08] <wgrant> sinzui: Depend on 'python2.6 (>= whatever version) | python-profiler', I guess.
[22:09] <wgrant> 2.7.2-2 made the change.
[22:09] <wgrant> Oh, nice.
[22:09] <sinzui> wgrant, maybe I should fork lp-deps to only require python-profiler for natty/lucid
[22:09] <wgrant> they got Disney to agree to relicense it.
[22:09] <wgrant> sinzui: No, just use the versioned disjunction.
[22:10] <sinzui> okay
[22:10] <LPCIBot> Project devel build #893: FAILURE in 5 hr 40 min: https://lpci.wedontsleep.org/job/devel/893/
[22:11] <wgrant> sinzui: odd, it's not in your 2.6, surely?
[22:11] <wgrant> I can only see the diff in 2.7.
[22:11] <wgrant> Ah, no, there it is.
[22:11] <wgrant> 2.6.7-2ubuntu1
[22:18] <wgrant> This also means we can remove the awful component checking stuff from rocketfuel-setup in 12 months.
[22:22] <wgrant> sinzui: So, are you fixing that up, or should I?
[22:23] <sinzui> wgrant, I was trying to. I do not know how to write a ored statement that essential say, don't bother
[22:28] <sinzui> wgrant, can you do it. I will read your change to know how?
[22:29] <sinzui> wgrant, I am guessing that we also need to state Lp requires python 2.6
[22:29] <wgrant> sinzui: Just depend on 'python2.6 (>= 2.6.7-2ubuntu1 | python-profiler'
[22:29] <wgrant> Er.
[22:29] <wgrant> 'python2.6 (>= 2.6.7-2ubuntu1) | python-profiler'
[22:29] <sinzui> ah
[22:29] <wgrant> In addition to the usual python2.6 dependency.
[22:30] <sinzui> There is no python2.6 dep
[22:30] <wgrant> Perhaps we should fix that.
[22:30] <wgrant> Let me see.
[22:32] <wgrant> We should really port to 2.7 in the next month or two. But I guess adding a 2.6 dep for now wouldn't hurt, as we now only get it accidentally.
[22:34] <sinzui> wgrant, Is this the line to add theN
[22:34] <sinzui> python2.6, python2.6 (>= 2.6.7-2ubuntu1) | python-profiler
[22:34] <sinzui> I feel like a idiot writing it.
[22:35] <wgrant> sinzui: That would indeed work.
[22:36] <wgrant> It feels odd, but is not uncommon.
[22:36] <sinzui> I will proceed.
[22:36] <wgrant> Thanks.