[12:08] <gary_poster> (bac out) benji frankban (gmb sprinting) https://plus.google.com/hangouts/_/af560291cc6180166d05d115d54a449ab5dab277?authuser=1&hl=en-US
[13:02] <frankban> gary_poster or benji___ : could you please review https://code.launchpad.net/~frankban/lpsetup/commands-unittests/+merge/112094 ?
[13:04] <benji> frankban: I can in a few minutes.
[13:05] <frankban> thanks benji
[13:05]  * benji wonders how his nick got to be "benji__", but enjoyed kicking the imposter "benji" off freenode anyway.
[13:12] <gary_poster> :-)
[13:19] <bac> tarmac should be working now.  frankban please let it merge your MP after review.
[13:19] <bac> gary_poster: i'm back home but can't really see.  will go sit in a dark room for a little while
[13:19] <frankban> ok bac
[13:19] <gary_poster> ok bac, relax
[13:20] <bac> gary_poster: good news though.  no visible problems. told me to go home and not come back for a year
[13:20] <gary_poster> excellent, bac
[14:22] <gary_poster> bac, when you return, let's get those goals take care of in allhands
[14:22] <gary_poster> gmb, when you see this, please let me know how allhands is going for you
[14:25] <gmb> gary_poster, Haven't tried today, will do so in the next half hour or so
[14:25] <gary_poster> great gmb, thanks
[14:31] <benji> frankban: I have commented on https://code.launchpad.net/~frankban/lpsetup/commands-unittests/+merge/112094
[14:32] <frankban> thanks benji: reading
[14:40] <frankban> benji: thanks for the comments, I will change the branch as you suggested. Only a question: how do you suggest to implement the get_arguments in the subcommand tests? Actually I am reusing arguments (e.g. test_install calls test_inithost.get_arguments)... so, class/static methods? Testcase subclasses?
[14:40] <benji> frankban: I figured it would just be the body of the module-level get_arguments, but as a method instead.  Did I miss something?
[14:46] <frankban> benji: we can have TestCase.get_arguments(self), but then we should continue supporting the story of another testcase reusing the arguments returned by the first testcase (e.g. InstallTest.get_arguments(self) should call and extend Inithost.get_arguments(self)). If I am not wrong, we can 2 this in 2 ways (that I can think now): 1) having one testcase as a subclass of another (so, use super and then extend)
[14:46] <frankban>  or 2) use class methods, so we can call AnotherTestCase.get_arguments()
[14:47] <benji> frankban: ah, I think I see why you went with the original solution then.  I agree that leaving it as-is is best.
[14:49] <frankban> cool benji
[15:11] <frankban> benji: branch updated following your suggestions.
[15:12] <benji> cool; looking
[15:13] <benji> frankban: looks great, approved
[15:15] <frankban> thanks benji, I will approve the mp and wait for tarmac to do the rest.
[15:16] <benji> I, for one, welcome our new branch-landing overlords.
[15:23] <benji> frankban and gary_poster: I have the smoketest branch up for review at https://code.launchpad.net/~benji/lpsetup/bug-1017973-add-smoke-tests/+merge/112141
[15:23] <frankban> benji: looking
[15:23] <benji> thanks
[15:24] <gary_poster> thanks
[15:28] <frankban> hum...still waiting for tarmac...
[15:36] <gary_poster> bac, is tarmac alive?
[15:46] <gary_poster> I want to start adding the workaround to bug 1014916 and bug 1013921 to lpsetup.  I think it is kinda safe because Graham is out this week, and because I ought to be able to get people to help me if I slow down, and I think it ought to be fast.
[15:46] <_mup_> Bug #1014916: simultaneously started lucid containers pause while starting after the first seven <lxc (Ubuntu):Confirmed> < https://launchpad.net/bugs/1014916 >
[15:46] <_mup_> Bug #1013921: our zope.testing fork needs to emit subunit time immediately before test start and immediately before test completion <paralleltest> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1013921 >
[15:46] <gary_poster> It goes against the rules...
[15:47] <gary_poster> I'm gonna do it, and ask Brad to work with me on it when he returns
[15:47] <frankban> gary_poster: cool. tarmac is not merging my branch, maybe this is because rhere wasn't a commit message at the time I approved it?
[15:48] <gary_poster> frankban, maybe not.  I dunno.  Can I do anything to help?  You could try adding the commit message and then unapproving and then reapproving, maybe?
[15:48] <frankban> gary_poster: trying
[15:50] <gary_poster> frankban, if that fails, merge manually.  we can iron out the wrinkles later when someone has access to the tarmac machine
[15:51] <frankban> gary_poster: yes, I will wait for 2 minutes and then merge manually
[15:51] <gary_poster> ok cool
[15:54] <frankban> gary_poster: maybe I should have asked this before: when I review lpsetup branches, should I follow the usual steps for a mentored reviewer (i.e. request Raphael review)
[15:55] <gary_poster> frankban, um.  :-D  Can I pretend you didn't ask me that? ;-)  The thought had quietly occurred to me before, and I thought that it would be nicer and easier and quite reasonable if we did not go through the mentoring for this project.  That said...
[15:56] <gary_poster> I suspect the proper thing to do is to go through the mentoring process.
[15:56] <gary_poster> If I pretended the question didn't exist then I didn't have to do the proper thing :-P
[15:57] <gary_poster> I know!  Let's ask Brad when he returns.  he's the reviewer god.  or was, once.
[15:57] <gary_poster> So meanwhile frankban, continue reviewing lpsetup without mentor.  We'll ask Brad for his judgement later.
[15:59] <frankban> hum... ok gary_poster, and we could still forget to ask him...
[15:59] <frankban> :-)
[16:00] <gary_poster> frankban, what was that?  did you say something?  Were we talking about something?
[16:01] <frankban> about the weather I guess...
[16:02] <frankban> and tarmac merge my branch.
[16:02] <frankban> merged
[16:03] <gary_poster> :-) cool
[16:07] <frankban> benji: approved,  I've added just a comment.
[16:21] <frankban> gary_poster: I am looking at the card "rename validators to handlers". we already have a handle() method in the subcommands that can generate confusion, do you agree in also renaming handle() to run()?
[16:21] <gary_poster> frankban, lemme look at code, one sec
[16:23] <gary_poster> frankban, so handle->run and handler->runner?
[16:24] <gary_poster> (in argparser)
[16:24] <frankban> no, handle -> run, validate -> handle_namespace (or similar), handler remains handler
[16:25] <frankban> and, validators -> handlers
[16:25] <gary_poster> ok, trying to get my head around that
[16:27] <gary_poster> right, ok.  So handlers.py contains (validators -> ) handlers...and
[16:27] <frankban> gary_poster: currently the handlers are called validators in argparse: we have a validators class attribute, a get_validators() method, a validate method that actually runs the handlers. we should rename all these attrs and methods.
[16:28] <frankban> but...
[16:29] <gary_poster> right, validate becomes handle_namespace or prepare_namespace, and is fir handler in self.get_handlers(namespace): try: handler(namespace); except ValidationError as err: parser.error(err)
[16:29] <gary_poster> (IOW, ValidationError remains, and handlers raise it)
[16:29] <frankban> yes
[16:30] <frankban> I was suggesting to rename handle() to run() to avoid confusion, because handle() does a different thing: it runs the steps.
[16:32] <gary_poster> frankban, right, I agree with that, but then why should handler (in register_subcommand and BaseSubCommand) remain handler?  It is either the "run" method or something else designed to run the subcommand's steps, right?  Calling that a handler seems another very similar confusion
[16:33] <gary_poster> BaseSubCommand.__init__ in particular, I mean
[16:33] <gary_poster> I don't love "runner"
[16:33] <gary_poster> but I like it better in that context than "handler" I think
[16:34] <frankban> gary_poster: ah! I see, yes... what about "callback"?
[16:35] <gary_poster> frankban, I like that, yeah
[16:35] <gary_poster> frankban, and all the rest you said makes sense to me now too, fwiw, so +1
[16:35] <frankban> cool
[16:39]  * benji returns from lunch and looks at the MP review.
[16:51] <benji> Laura Czajkowski's change of the smoke test bug importance from Undecided to High confuses me.  Was that a bot, perhaps?
[16:54] <frankban> hum...
[16:54] <gary_poster> benji, no, she is responsible for triaging, just as we were when we had community rotation or whatever it was called.  We are not allowed to have untriaged bugs in the LP project and lpsetup is an LP project.
[16:55] <gary_poster> "high" is the correct triage in fact: it is not critical, but we intend to do it now.
[16:55] <benji> ah, that makes sense
[16:55] <gary_poster> correct at least according to our LP definitions of course
[16:55] <benji> yeah, my main confusion was to why she was doing anything, but since it is part of LP, it makes sense
[16:56] <benji> confusion relieved, tragedy averted
[16:58] <gary_poster> :-)
[16:58] <gary_poster> frankban, are you quitting now?  I have a question for you but I don't want to keep you
[16:59] <frankban> gary_poster: no problem, please ask
[17:02] <gary_poster> ok thanks.  So, I want to add a --lxc option to inithost.  When you use that option, it will run a separate step that installs things specific to the host only if it is an lxc container.  (Then lxcinstall will include that option.)  I intend to do this by adding an lxc step, and then adding an lxc argument and then adding a call_lxc that only calls the step if the argument is included
[17:02] <gary_poster> what do you think of that?
[17:02] <gary_poster> frankban, ^^
[17:03] <gary_poster> I'll be right back
[17:05] <frankban> gary_poster: I think it's right. FWIW I've used the dynamic dispatcher in the same way for create_scripts in lxcinstall
[17:07] <gary_poster> frankban, ok cool thank you!
[17:08] <frankban> welcome, have a nice evening!
[17:10] <gary_poster> you too :-)
[17:24] <benji> well, that was fun.  I had to restart my machine to get networking to work again
[17:44] <bac> hi gary_poster, i'm looking at your suggestion about piotr's method.  i don't really see that it buys that much and adds an unexpected command line option.  i'd vote for not doing it.
[17:44] <gary_poster> hey bac
[17:44] <gary_poster> cool
[17:45] <bac> and you've got to remove it from sys.argv before calling setup() or it gets angry
[17:45] <bac> minor
[17:45] <gary_poster> bac, what it buys, apparently, is that you can use the system's setuptools if it is installed
[17:45] <gary_poster> as it usually is
[17:45] <gary_poster> on Ubuntu
[17:46] <gary_poster> (where setuptools == distribute)
[17:46] <bac> oic
[17:47] <gary_poster> so, isn't that something of value?  Note that another way to approach this is to run screaming to barry, who IME will make you feel better at the very least, even if there aren't any options ATM.  He write that email not very long ago though
[17:47] <gary_poster> aren't any good/approved/official options, I should say
[17:48] <gary_poster> he's probably doing something reasonable for his flufl things
[17:48] <gary_poster> let's see...
[17:49] <gary_poster> bac, :-/ http://bazaar.launchpad.net/~barry/flufl.i18n/devel/view/head:/setup.py
[17:50] <bac> so your point being barry has punted like us mortals?
[17:50] <gary_poster> bac, precisely
[18:08] <benji> bac: are we in all tarmac, all the time land now?  In other words, do I have to manually land my lpsetup branch or will tarmac do it for me?
[18:08] <bac> benji: don't land.  i have it running as a cron job but am having some problems with gpg-agent
[18:08] <bac> benji: either it will land via the cronjob or i'll do it by manually running tarmac
[18:16] <benji> k
[18:16]  * benji laments that his beeper still needs AC power to work
[18:20]  * gary_poster goes to have lunch, a bit late.
[18:35] <benji> I really like having tarmac.  It has already saved me from comitting with failing tests.
[18:57] <gary_poster> yay!
[19:04] <bac> benji: yeah, i saw that.  cool.  yours is committed now.
[19:14] <bac> benji: distribute_setup.py is dirty too
[19:15] <benji> Is that distribute's version of ez_setup.py?  Do we need either of them?
[19:24] <gary_poster> benji, yes; and it depends.  I added a "pain" topic for bac to talk about the packaging annoyances on Friday.
[19:24] <benji> cool
[19:31] <bac> benji: hey, tarmac makes me look busy:  https://code.launchpad.net/~benji/lpsetup/bug-1017973-add-smoke-tests/+merge/112141
[19:31]  * bac needs to make a new LP user for tarmac
[19:31] <benji> :)
[19:31]  * bac ponders --swedish-chef option for tarmac
[19:51] <gary_poster> heh
[20:00] <bac> gary_poster: it is time for me to switch to a 'bot user in LP for tarmac to use.  can you think of an appropriate one to re-use or just create 'yellow-tarmac', 'yellow-robot', etc?
[20:00] <bac> actually it should not be yellow-specific, of course
[20:03] <gary_poster> um
[20:03] <gary_poster> bac, lp-tarmac?
[20:03] <gary_poster> bac, I wonder who diogo is using
[20:04] <gary_poster> on call with flacoste
[20:04] <bac> were he not off stuffing his face with crepes and red wine i would ask him.  (diogo, not francis)
[20:04] <gary_poster> lol
[20:04]  * bac </jealous>
[20:05] <bac> ok, i'll suffer with my user id until tomorrow
[21:07] <bac> gary_poster: damn homonyms
[21:08]  * bac intrigued that "skillz" got by your spellchecker
[21:09] <gary_poster> :-)
[21:09] <gary_poster> heh
[21:09] <gary_poster> skillz seemed humorous
[21:09] <gary_poster> vain seemed unintentional
[21:15] <bac> yes, quite.
[21:15] <bac> i remember in grade school the teacher was talking about homonyms.  she had the hardest time convincing us that "pin" and "pen" were not pronounced the same.