[05:52] <thumper> mwhudson: if you could take a look at http://bazaar.launchpad.net/~thumper/launchpad/new-bzr/revision/11058
[05:52] <thumper> mwhudson: I've reviewed the rest of the bzr 2.2 upgrade branch as it was done by abentley
[05:52] <thumper> mwhudson: but that revision is the only non-merge one
[05:53] <thumper> from me
[05:54] <thumper> I'm running it throug ec2 now (test only)
[05:55] <mwhudson> thumper: assuming it makes the tests work, it looks ok to me
[05:55] <thumper> https://code.edge.launchpad.net/~thumper/launchpad/new-bzr/+merge/32845 is the entire MP
[05:55] <thumper> the tests all pass with flying colours
[05:56] <mwhudson> thumper: reviewed, then
[05:56] <thumper> ta
[09:33] <jtv> henninge: approved
[09:33] <henninge> jtv: thank you very much! ;)
[09:34] <jtv> np
[10:04] <gmb> jtv, https://code.edge.launchpad.net/~jtv/launchpad/recife-approveSuggestion/+merge/32848 is it?
[10:10] <jtv> gmb: yes, that's it
[10:10] <gmb> Righto
[10:10]  * gmb should really write an x-chat plugin to deal with the topic in this channel.
[10:12] <jtv> We could write a chat server for Launchpad…
[10:13] <jtv> gmb: I do unfortunately have to run off very soon.
[10:14] <gmb> jtv, No worries, we can do any back-and-forth by email.
[10:17] <jtv> gmb: thanks
[10:40] <lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/milestones/+merge/32855
[11:00] <jtv> gmb: still getting used to adding more comments to unit tests… I'd like them to be shorter and have simpler subject material so I could make the code speak for itself, but doesn't always work.
[11:02] <gmb> jtv, Yeah; All I'm after is a comment (or docstring; I prefer comments but have no reason for it) at the start of the test telling me the expected behaviour.
[11:03] <jtv> gmb: doing that now
[11:03] <gmb> # If the foo is prodded the frobnob goes boing.
[11:03] <gmb> And so on.
[11:03] <gmb> jtv, Cool.
[11:03] <jtv> thanks for the review btw.
[11:03] <gmb> np
[11:03] <gmb> jtv, Thanks for the awesome cover letter that saved me a lot of confusion :)
[11:03] <jtv> Glad to know the effort's not wasted!
[11:03] <gmb> Indeed.
[11:47] <lifeless> gmb: thanks
[11:49] <gmb> np
[12:22] <cjwatson> gmb: I'd like to have a pre-impl chat about bug 619152
[12:26] <gmb> cjwatson, I think you'd be better off chatting to one of { bigjools, jelmer, noodles775 }; I have this much context on Soyuz: ><
[12:26] <cjwatson> bigjools: ^- would you have a moment?
[12:27]  * StevenK idly notes he isn't in that list :-P
[12:28] <gmb> StevenK, I assumed that you were sleeping or otherwise engaged.
[12:28] <StevenK> Trying to stop working. Failing. :-/
[12:30] <cjwatson> well, this is *cough* "pre"-impl, I have a branch and would quite like a sanity check that it covers everything I need; especially as running ec2test involves some pile of local setup I haven't managed to do
[12:31] <gmb> cjwatson, *definitely* one for the Soyuz team, then. Sanity is defined differently once you enter lp.soyuz.
[12:32] <wgrant> No, it's undefined :/
[12:33] <cjwatson> lp:~cjwatson/launchpad/dpkg-xz-support-619152
[12:33] <jelmer> cjwatson: Hi
[12:33] <cjwatson> hi
[12:35] <jelmer> cjwatson: I can do a review and run your branch through ec2 if you like.
[12:35] <cjwatson> that would be awesome
[12:42] <jelmer> cjwatson: Looks great
[12:43] <jelmer> cjwatson: I'm wondering though how much policy enforcement we should be doing in nascentuploadfile.
[12:44] <jelmer> It would be nice if we could do this sort of testing by enforcing a few lintian errors, as dak is doing.
[12:46] <jelmer> bigjools: Is there a particular reason we aren't doing more checking of control fields in nascentupload?
[12:50] <jelmer> cjwatson: Before this can land, we also need to get a newer version of dpkg deployed on the Launchpad servers.
[13:00] <cjwatson> jelmer: the policy enforcement there is just a copy of what we used to do when the other compression formats were new
[13:00] <cjwatson> jelmer: (not that this really answers your point as such)
[13:00] <cjwatson> I actually literally resurrected it from old commits
[13:01] <cjwatson> jelmer: would you like me to take care of getting a new dpkg in place?
[13:01] <cjwatson> may take a while ...
[13:02] <jelmer> cjwatson: Ah, sorry. I wasn't aware there had been something like that previously.
[13:02] <jelmer> cjwatson: I can take care of it if you like; I need to upload some updates to the Launchpad PPA anyway.
[13:03] <jelmer> cjwatson: If you can propose a merge into lp:launchpad/devel I'll do a proper review as well landing this.
[13:03] <cjwatson> OK, either way.  Do you know the stuff that's required for hardy-cat backporting?
[13:04] <jelmer> Hmm, I hadn't considered hardy-cat actually, was just thinking about the launchpad servers (which do unpacking).
[13:05] <cjwatson> hardy-cat is how dpkg gets to them
[13:05] <wgrant> Or is Lucid happening soon enough that that's irrelevant?
[13:06] <cjwatson> lucid doesn't have dpkg 1.15.6, so it would be an issue either way
[13:06] <jelmer> wgrant: Lucid's dpkg is too old as well if I understand correctly. (1.15.5 vs 1.15.6)
[13:06] <cjwatson> the backport diff to hardy-cat is http://paste.ubuntu.com/479368/; there was an extra upload by LaMont after that as well, but that was a backport from 1.15.6 so I think it can be discarded
[13:07] <cjwatson> http://paste.ubuntu.com/479369/ is the complete diff from hardy to hardy-cat currently
[13:07] <jelmer> do the launchpad servers run hardy-cat as well, not just the buildd's ?
[13:07] <cjwatson> yes
[13:26] <cjwatson> gah, dpkg gets harder and harder to backport - now I have to care about gettext
[13:27] <cjwatson> maybe it would be easier just to cherry-pick the change in question
[13:28] <jelmer> how intrusive is the patch?
[13:32] <cjwatson> not hugely
[13:33] <cjwatson> will still need to get xz-utils into hardy-cat though
[13:34] <cjwatson> hm, there was some packaging awkwardness there, I recall
[13:34] <cjwatson> should be OK with maverick's version
[14:24] <jelmer> hi gmb, mars
[14:24] <gmb> jelmer, Howdy.
[14:24] <jelmer> can I add a simple soyuz branch to either of your queues?
[14:24] <gmb> jelmer, How small is it?
[14:25] <gmb> I ask because I need to go afk for 1:30 at about 14 UTC
[14:25] <jelmer> It's 458 lines, but pretty much only adds tests for existing code
[14:25] <gmb> jelmer, Okay, I'll take a look now. Diff me.
[14:25] <jelmer> gmb: thanks - mp is @ https://code.edge.launchpad.net/~jelmer/launchpad/nascentuploadfile-tests/+merge/32874
[14:42] <gmb> jelmer, Review sent; quite a lot of cosmetic changes needed (callsite formatting and tests that need a comment).
[14:42] <gmb> But the code is sound; nice work.
[14:42] <jelmer> gmb: Thanks for the review.
[14:43] <gmb> np
[14:43]  * gmb goes off review for a while for travelling.
[15:07] <benji> mars: I have a couple revisions to an already-approved branch that need review: http://bazaar.launchpad.net/~benji/launchpad/bug-597324/revision/11117 and http://bazaar.launchpad.net/~benji/launchpad/bug-597324/revision/11118
[15:22] <jelmer> What should the per-line imports look like exactly? The python style guide doesn't appear to've been updated yet.
[15:25] <mars> jelmer, mister review master wrangler back may know
[15:25] <mars> 'bac' even
[15:25] <bac> jelmer: no, it hasn't
[15:25] <mars> benji, sure, please add yourself the queue
[15:26] <bac> jelmer: we agreed that single imports remain on one line, and that more than one require multiple lines, one per
[15:26] <bac> jelmer: we did not discuss alphabetizing, so i assume that criterion has not been relaxed
[15:27] <jelmer> should the closing ")" be on a separate line?
[15:27] <bac> yes
[15:27] <jelmer> ok, that was the main thing I wasn't sure about - thanks
[15:27] <bac> with a trailing comma on the last item
[15:27] <bac> unfortunately, the ) on a separate line irritates our linter
[15:28] <benji> bac: I missed that decision; was it in the email thread [Launchpad-dev] RFC: format lists one-per line ?
[15:30] <bac> benji: it was in the reviewers meeting and there was an email discussion.  i think you contributed to it.
[15:31] <bac> benji: i do need to send an email, though, finalizing the decision
[15:31] <benji> bac: right, I hadn't seen a finalization email; thanks
[15:32] <bac> benji: that's b/c i am slack
[15:32] <benji> heh
[15:54] <mars> Ursinha, merge is ready: https://code.edge.launchpad.net/~mars/qa-tagger/lazr-conversion/+merge/32878
[15:54] <Ursinha> mars, thanks!
[15:59] <benji> mars: should I add another MP for those revisions?  I'm not sure how to handle the situation when a branch has been approved and then more changes have to be made to it.
[15:59] <mars> benji, usually we just ask for another review explicitly for the changed revisions
[16:00] <mars> and add it to the existing MP
[16:00] <mars> benji, what is the MP?
[16:00] <benji> mars: https://code.edge.launchpad.net/~benji/launchpad/bug-597324/+merge/30829
[16:01] <mars> thanks
[16:06] <mars> benji, I think you need a new MP.  The old one was not updated with your latest changes
[16:06] <mars> it looks like you can indeed keep hacking on the same branch
[16:07] <mars> benji, there is also a big revision gap: the MP ends at 112, and you asked for 117 and 118 to be reviewed.  Where did the others go?
[16:08] <benji> mars: one was a merge, two were trivial, and one should have been included (and is in the MP I'm writing right now)
[16:09] <mars> benji, ok, then I think a new proposal should just Do The Right Thing
[16:12] <benji> mars: here you go: https://code.edge.launchpad.net/~benji/launchpad/bug-597324/+merge/32884
[16:13] <mars> thanks
[16:14] <mars> benji, you may want to try 'bzr qannotate' to browse publication.py and figure out what the intent of the 'appears to be a XSRF countermeasure' thing is
[16:14] <mars> or bzr explorer
[16:14] <benji> I'll look at that now.
[16:14] <mars> benji, db-devel is the right target?
[16:15] <benji> darn; no it's not
[16:15] <benji> mars: let me delete and re-create the MP so it has the right target
[16:15] <mars> ok
[16:16] <benji> mars: https://code.edge.launchpad.net/~benji/launchpad/bug-597324/+merge/32886
[16:17] <mars> ok
[16:25] <benji> mars: did you mean "bzr qannontate" or just "bzr annotate"?
[16:25] <mars> benji, a method has 40 lines of comments to 3 lines of code - I don't know what to say
[16:26] <benji> mars: ?
[16:26] <mars> benji, there is a qbzr plugin that gives gtk versions of some bzr commands - qannotate and qlog are really nice versions of the set
[16:26] <benji> mars: oh, the referer exception  thing
[16:27] <benji> ok; I'm more of a text kind of guy :)
[16:27] <mars> benji, no, the text is good
[16:28] <mars> it's the very fact that a small book must be written to explain the purpose of a single call to 'return' that I find... strange
[16:28] <mars> sounds like something NASA would do
[16:30] <benji> heh
[16:32] <mars> benji, your comments there are fine.  I'm surprised that that one block of code has so many XXXs and so much text
[16:32] <benji> mars: speaking of NASA, I'm sure you've read this http://www.fastcompany.com/node/28121/print; if not, you'll enjoy it
[16:33] <benji> yeah, it's a bit of an oddity
[16:33] <benji> maybe we should start a contest for the most well-documented bare return
[16:34] <mars> benji, yep, that article is what inspired my NASA comment :)
[16:34] <benji> cool
[16:34] <benji> I like to read that every year or so; lots of good stuff in there
[16:35] <mars> for me that article perfectly demonstrates one of the three faultlines (or continents) in the software world: hackers, enterprise, and academic
[16:35] <mars> they all hate each other
[16:35] <mars> and insist that if the others just did it their way, the world would be a better place :)
[16:37] <benji> heh
[16:37] <jml> mars, "they"?
[16:38] <mars> jml, ?
[16:38] <mars> 'they all' => 'they'
[16:38] <mars> maybe?
[16:38] <jml> mars, surely "we" would be more appropriate :)
[16:39] <mars> :D
[16:39] <benji> I would hope that the NASA folks realize that very few people can afford to put 260 people on building something about the size of LP.  I'd also hope that the hacker type (which I count my self as) realize that when lives depend on your work product you have to be quite bit more particular about processes.
[16:39] <jml> mars, unless you're hiding on some uncharted fourth continent :P
[16:40] <benji> heh
[16:40] <benji> journey to the center of mars
[16:40] <mars> benji, then I count thee as enlightened
[16:41] <benji> ok, mars: I was able to verify that the referer-rejection code is indeed about XSRF; I'll update the comment to be a statement instead of a question.
[16:42] <mars> cool
[16:43] <mars> bac, are we transitioning slowly to multi-line imports, or is someone going to nuke the source tree with a macro over the weekend?
[16:43] <bac> mars: unclear
[16:43] <bac> mars: the code team seemed to indicate they were going to rush off and do theirs quickly
[16:44] <bac> mars: no one volunteered for an apocalyptic branch
[16:44] <mars> bac, I'm reviewing benji's branch, and he worked with the imports in test_publication.py.  Should the ones he worked with be updated to multiline as part of the policy?
[16:44] <mars> not suggesting the whole file be updated
[16:45] <bac> mars: i'd suggest not requiring it until we get some tool support.
[16:45] <mars> perfect
[16:45] <mars> thanks back
[16:45] <mars> thanks bac
[16:45] <mars> twice today, argh
[16:45] <bac> there is an emacs 'sort-imports' and i think vim has something similar.
[16:45] <bac> they should be updated
[16:45] <mars> personally I would like a Python or sed script
[16:46] <bac> mars: that too
[16:47] <mars> benji, nice test suite addition
[16:47] <benji> cool
[16:55] <mars> benji, done, one errant comment, r=mars with the fix
[16:55] <mars> off to lunch!
[16:55] <benji> mars: thanks
[17:30] <EdwinGrubbs> mars: can I get a small branch reviewed? https://code.edge.launchpad.net/~edwin-grubbs/launchpad/bug-615654-fillTeamParticipation-timeout/+merge/32895
[18:16] <bdmurray> mars: Could you review https://code.edge.launchpad.net/~brian-murray/launchpad/x-launchpad-bug-modifier-follow-on/+merge/32900
[19:13] <mars> Xorg server crash
[19:13] <benji> I hate those.
[19:14] <benji> mine is at https://code.edge.launchpad.net/~benji/launchpad/bug-580035/+merge/32615
[19:14] <mars> cool, thanks
[19:28] <mars> jcsackett, feel free to put your name in the topic and leave a PM with the merge proposal link
[19:28] <jcsackett> mars: okay, thanks.
[19:29] <mars> well, PM isn't right, just a message
[19:29] <mars> either myself or a passer-by will pick it up
[19:29] <jcsackett> mars: okay.
[19:30] <jcsackett> mars: mp is at https://code.edge.launchpad.net/~jcsackett/launchpad/plus-participation-additional-fixes/+merge/32820
[19:30] <jcsackett> mars: thanks so much!
[19:31] <mars> no problem
[20:13] <mars> benji, ping, looks like bug-580035 has a merge conflict
[20:14] <mars> benji, merged with db-devel again
[20:22] <mars> EdwinGrubbs, btw, in your branch, for the routines that the SQL query replaced: was that their only callsite?  If so, can the routines be eliminated?
[20:23] <EdwinGrubbs> mars: what do you mean eliminated?
[20:23] <mars> EdwinGrubbs, ah, I guess not.  Lines 97-100 of the diff
[20:24] <mars> those are probably used elsewhere
[20:24] <mars> :)
[20:25] <EdwinGrubbs> mars: oh, you mean whether hasParticipationEntryFor can be eliminated. good question.
[20:26] <benji> ok, mars: the conflict is fixed and a new MP with the right target is at https://code.edge.launchpad.net/~benji/launchpad/bug-580035/+merge/32917
[20:26] <EdwinGrubbs> it looks like theat is getting used in asserts and tests, so it would be a pain to remove.
[20:27] <mars> thanks benji
[20:27] <mars> EdwinGrubbs, then it still sounds useful to me
[21:20] <mars> alright, I'm done for the day.  Take care everyone
[21:31] <leonardr> gary, can you take a quick look at https://code.edge.launchpad.net/~leonardr/launchpadlib/fix-test-failure/+merge/32925 ?
[21:31] <gary_poster> on call leonardr
[21:37] <leonardr> np, i'll wait. i have an ec2 test running and i'll come back tomorrow to see if this solved all the problems or only one
[23:05] <gary_poster> approved leonardr