Not logged in - Log In / Register





[15:00] <bac> #startmeeting
[15:00] <MootBot> Meeting started at 09:00. The chair is bac.
[15:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:00] <bac> Hello and welcome to the LP Reviewers Meeting.  Who is here today?
[15:00] <jtv> me
[15:00] <jtv> hi bac
[15:00] <sinzui> me
[15:00] <noodles775> me
[15:00] <henninge> me
[15:00] <bac> hi jtv
[15:01] <barry> lurk
[15:01] <bigjools> me
[15:02] <bac> BjornT, EdwinGrubbs, mars, gmb, allenap: ping
[15:02] <gmb> me
[15:02] <bac> adeuring, gary_poster: ping
[15:02] <gmb> Thanks bac.
[15:02] <adeuring> me
[15:02] <mars> me
[15:02] <bac> salgado: ping
[15:02] <bac> who else are we missing?
=== matsubara is now known as matsubara-lunch
[15:03] <allenap> me
[15:03] <gary_poster> me-ish
[15:03] <BjornT> me
[15:04] <bac> ok, let's move on and perhaps others will show up
[15:04] <deryck> me
[15:04] <bac> [topic] Agenda
[15:04] <MootBot> New Topic:  Agenda
[15:04] <bac> * Roll call
[15:04] <bac>  * Action items
[15:04] <bac>  * Landing branches for community contributors. [bac for jml]
[15:04] <bac>  * Ease the "no lambdas" coding style to allow using them for Twisted callbacks. [heninge, allenap, abentley]
[15:04] <bac>  * Peanut gallery (anything not on the agenda)
[15:04] <bac> we had a lot of outstanding actions from two weeks ago but not much on the agenda for today.
[15:05] <bac> [topic] action items
[15:05] <MootBot> New Topic:  action items
[15:05] <bac> [topic] * allenap to start discussion on the ML about doctest size, refactoring, moving corner cases to unittests, etc
[15:05] <MootBot> New Topic:  * allenap to start discussion on the ML about doctest size, refactoring, moving corner cases to unittests, etc
[15:05] <allenap> Dang, still haven't done that.
[15:05] <allenap> Please keep it on the list.
[15:06] <bac> allenap: will do.  you think you'll have time this week?
[15:06] <bigjools> we need a new topic, "who sucks this week?"
[15:06] <bac> [topic] * gary_poster to do timing tests for try/except, examine current usage of check_permission, and we'll discuss again 10-Feb.
[15:06] <MootBot> New Topic:  * gary_poster to do timing tests for try/except, examine current usage of check_permission, and we'll discuss again 10-Feb.
[15:06] <EdwinGrubbs> me
[15:06]  * gary_poster cringes
[15:06] <allenap> bac: Yes, I will. I do suck :(
[15:06] <gary_poster> 17-Feb
[15:06] <bac> did i say the 10th?  surely i meant the 17th, gary_poster
[15:06] <gary_poster> :-D
[15:06] <gary_poster> :-) thanks
[15:06] <abentley> me
[15:07] <bac> [topic] * brad to find and clean up relevant reviewer pages on lp.c.c and move to
[15:07] <MootBot> New Topic:  * brad to find and clean up relevant reviewer pages on lp.c.c and move to
[15:07]  * bac rocks
[15:07] <henninge> cool bac!
[15:07] <bac> i think i got all of this done.  let me know if there are other old pages that need carting over.
[15:07]  * jtv cheers bac
[15:07] <bac> [topic] * salgado to update the wiki page to encourage reviews with sufficient context.
[15:07] <MootBot> New Topic:  * salgado to update the wiki page to encourage reviews with sufficient context.
[15:08] <bac> salgado doesn't appear to be here so we'll hold that one
[15:08] <bac> [topic] * bac to update coding guideline wrt conditional expressions.
[15:08] <MootBot> New Topic:  * bac to update coding guideline wrt conditional expressions.
[15:08]  * bac two for two
[15:09]  * noodles775 claps
[15:09] <bac> [topic] * barry to school us on the proper use of 'with'.
[15:09] <MootBot> New Topic:  * barry to school us on the proper use of 'with'.
[15:09]  * bigjools hi-5s bac
[15:09] <bac> barry thanks for the great email on that topic
[15:09] <barry> np!
[15:09] <bac> it was really informative
[15:09] <bac> and finally
[15:09] <bac> [topic] * edwingrubbs to document JS namespace issue.
[15:09] <MootBot> New Topic:  * edwingrubbs to document JS namespace issue.
[15:10] <EdwinGrubbs> bac: yes, that has been added to the wiki, and I opened bugs for each team.
[15:10] <bac> excellent EdwinGrubbs
[15:10] <bac> so, we've closed about half of those outstanding issue
[15:10] <bac> so on to new, hopefully more interesting stuff
[15:11] <bac> [topic] * Landing branches for community contributors. [bac for jml]
[15:11] <MootBot> New Topic:  * Landing branches for community contributors. [bac for jml]
[15:11] <bac> ok, so this isn't too interesting
[15:11] <bac> jml wanted us to discuss our approach for landing community contributions
[15:12] <bac> i think unofficially we've assumed the reviewer would do it but that isn't always the case.
[15:13] <jml> hello, I am unexpectedly here
[15:13] <bac> i'm pretty sure we discussed in the past the idea that the contributor needs to find someone to do the landing and make arrangements.  but i think reviewers need to plan on taking care of the landing unless otherwise noted
[15:13] <bac> hi jml.  welcome.
[15:14] <henninge> bac: +1
[15:14] <bac> jml's other point was the OCR should be the next contact if the original reviewer isn't around when the branch is actually ready
[15:14] <bac> like i said, not controversial but we need to agree this is how we'll do it
[15:14] <bac> thoughts?
[15:15] <bac> ok, i'll formalize that idea and slap it on the wiki page
[15:15] <henninge> I agree. Also, as mentioned before, all it takes is "ec2 land http://url_to_mp" in a current devel.
[15:15] <jtv> doesn't that suffer from the last-minute-change hole?
[15:16] <bac> [action] bac to update wiki page to make clear community contributor landing responsibilities
[15:16] <MootBot> ACTION received:  bac to update wiki page to make clear community contributor landing responsibilities
[15:16] <bac> jtv: it does
[15:16] <henninge> oh, it does?
[15:16] <jml> jtv, you mean, the script has a bug?
[15:16] <bac> jtv: there is an easy fix to ec2 i'd like to do when i get a chance but haven't yet
[15:16] <jtv> jml: not necessarily, but I'm not sure what behaviour is specified
[15:17] <henninge> bac: also, I made it my practice to add "Landed by henninge" to the commit message, as we discussed earlier. Should that be formalized, too?
[15:17] <bac> the problem is the contributor can push new changes to the branch during the time ec2 is running.  those new unreviewed, untested changes are then picked up and landed by pqm
[15:17]  * henninge remembers
[15:17] <abentley> bac, and also the contributor can push new changes while the branch is in PQM.
[15:17] <bigjools> I always copy the branch before submitting it
[15:18] <bac> abentley: sure, but that's generally a smaller windown
[15:18] <jtv> I think bigjools' approach is absolutely the right one.
[15:18] <jml> I think it's almost the right one.
[15:18] <bigjools> I also think we should be emailed when a branch gets new revisions after a review has started
[15:18] <jtv> But with that, resorting to the OCR when the reviewer is out of reach may lead to confusion.
[15:18] <jtv> jml: given the current technical constraints.
[15:18] <bac> bigjools: that's what i do now.  i wonder if we could get some tool support to make that less of a PITA
[15:18] <jml> jtv, the tools are easily fixed.
[15:19] <bigjools> I'd rather a way of freezing the branch
[15:19] <abentley> I implemented merge directives so that they would specify the particular revision to land.  Unfortunately, PQM still doesn't support them.
[15:19] <jtv> jml: all for that.
[15:19] <bigjools> PQM must die
[15:19] <jml> jtv, do it. if you have time to land someone's branch in a painstaking way you have time to make it easier for everyone.
[15:19] <jml> bigjools, +1
[15:19] <jtv> abentley: I'd prefer "refuse branches with unreviewed revisions" over "land an older version"
[15:19] <bigjools> die in the most horrible manner possible
[15:20] <jml> bigjools, swift death ftw.
[15:20] <bigjools> jtv: +1
[15:20] <bac> jml: the tools can not eliminate the PQM window abentley pointed out
[15:20] <jml> bac, copying the branch addresses that issue too.
[15:20] <bac> jml: yes, if that is the tool fix you're referring to
[15:21] <jtv> jml: it narrows the window for unreviewed revisions and in return for that you get more time for revisions to be lost
[15:21] <noodles775> Couldn't the current tool just not land the branch if there are extra untested revisions after it finishes the test?
[15:21] <bigjools> I think the branch should get frozen once approved
[15:21] <noodles775> Like a failure?
[15:21] <jtv> noodles775: that's my preferred outcome
[15:21] <noodles775> That way we could still use ec2 land safely?
[15:22] <jtv> bigjools: I do sometimes have last-minute fixes, e.g. because I forgot to check for lint.  They need to be reviewed, but apart from that...
[15:22] <bac> why is the 'reviewed revision' not set on our MPs?
[15:22] <abentley> bigjools, our partly-implemented landing queues are reasonably sophisticated, but let's talk about that offline.
[15:22] <henninge> jtv: well, you *could* always rs them, couldn't you?
[15:23] <jtv> henninge: that'd be another extra feature I guess
[15:23]  * henninge has never tried to approve his own MP
[15:23] <abentley> bac, there was no immediate win.
[15:23] <jtv> maybe it's not so bad if we can review our own cosmetic changes, as long as all revisions have been approved by _someone_ who is a reviewer
[15:24]  * abentley has approved many of his MPs, because the reviewers neglected to set the status.
[15:24] <bac> i think we've opened up a can of worms here that we need to discuss more on the ML, again.
[15:24] <henninge> abentley: oh, I have done that, too.
[15:24] <bac> let's table it for now
[15:25] <bac> [topic] * Ease the "no lambdas" coding style to allow using them for Twisted callbacks. [heninge, allenap, abentley]
[15:25] <MootBot> New Topic:  * Ease the "no lambdas" coding style to allow using them for Twisted callbacks. [heninge, allenap, abentley]
[15:25] <henninge> This came up during a review on Monday.
[15:25] <bigjools> heh, tabling means something different in British English :)
[15:25] <bac> bigjools: like everything else
[15:25] <henninge> allenap submitted code for review that uses Twisted and had lines like this
[15:25] <henninge> d.addCallback(lambda ignored: reactor.stop())
[15:26] <barry> hmm.  are use of lambdas "standard operating procedure" for twisted dev?
[15:26] <jml> barry, yes.
[15:26] <jml> barry, as is using 'd' for a narrowly-scoped Deferred
[15:26] <barry> jml: then: when in rome...
[15:26] <jml> barry, which is also verboten in our coding standard.
[15:27] <jtv> stupid question perhaps but is there no "bind" in python?
[15:27] <jml> bac, bigjools: (go to the end of page)
[15:27] <jtv> d.addCallback(bind(reactor, stop)), something like that?
[15:27] <allenap> abentley had a good point yesterday, which is that this is not about code reuse, but about adapting functions to be callbacks.
[15:27] <allenap> jtv: There is functools.partial
[15:28] <barry> jml: same reason we don't pep8 our method names
[15:28] <allenap> jtv: But that doesn't help when you want to ignore an argument.
[15:28] <jml> jtv, what definition of bind would make that equivalent to 'lambda ignore: reactor.stop()'?
[15:28] <jtv> oic
[15:30] <jml>
[15:30] <MootBot> LINK received:
[15:30] <henninge> Ok, so do we agree that the use of lambda is acceptable in Twisted context?
[15:30]  * jml agrees
[15:30] <bigjools> +!
[15:30] <sinzui> +1
[15:30] <bigjools> and +1
[15:30] <abentley> +1
[15:30] <adeuring> +1
[15:30] <allenap> +1
[15:30] <barry> +1
[15:30] <al-maisan> +1
[15:30] <henninge> +1
[15:30]  * barry would much rather see lambda than kerchop!
[15:31] <bac> +1
[15:31] <jtv> I hate for the rule to be so "arbitrary" though.
[15:31] <bigjools> common sense applies
[15:31] <henninge> cool, I'll update the guideline to say so.
[15:31] <jtv> bigjools: now *that* is a rule I like
[15:31] <al-maisan> kerchop was certainly enough of a deterrent to sway the votes ;)
[15:31] <jml> "Break any of these rules sooner than say anything outright barbarous."
[15:32] <bac> [action] henninge to update guidelines to allow lambda in twisted context
[15:32] <MootBot> ACTION received:  henninge to update guidelines to allow lambda in twisted context
[15:32] <noodles775> "Adapting functions to be callbacks" seems to make sense too though, as a more general context? - maybe that point should be said with the guideline :)
[15:32] <bac> [action] bac to not use 'table' as a verb in mixed company
[15:32] <MootBot> ACTION received:  bac to not use 'table' as a verb in mixed company
[15:32] <bac> [topic] * Peanut gallery (anything not on the agenda)
[15:32] <MootBot> New Topic:  * Peanut gallery (anything not on the agenda)
[15:32] <jtv> bac: you split an infinitive.
[15:33] <bigjools> lol @ bac
[15:33] <deryck> it's allowed in southern US english
[15:33] <bac> any new topic?
[15:33] <barry> noodles775: well.  in general, lambdas shouldn't e used for callbacks.  it's just that twisted style embraces and promotes lambdas, so it's more a "fit in with twisted coding styles when necessary" rule
[15:33] <noodles775> barry: oic
[15:34]  * jml disagrees w/ barry, but whatever.
[15:34] <barry> jml: :)
[15:34] <bac> nothing else then?
[15:34] <abentley> barry, it's also a matter of "writing twisted without lambdas is unnecessarily painful".
[15:34] <bac> 3
[15:34] <bac> 2
[15:34]  * bigjools has a quickie
[15:34] <barry> abentley: true that
[15:35] <bigjools> topic, that is
[15:35] <jtv> bigjools: enjoy it
[15:35] <bac> bigjools: thanks for sharing
[15:35] <bigjools> welcome
[15:35] <bigjools> do I have the floor?
[15:35] <bigjools> darn, did it again
[15:35] <bigjools> In a review of mine, bac noticed that I had some long line lint in a file
[15:35] <bigjools> that I'd changed, but not anything I'd changed myself.  The file was
[15:35] <bigjools> and someone had added very long lines to hack
[15:35] <bigjools> the return types for API exports.  I want to remind people to use the
[15:35] <bigjools> helpers in that file (e.g. patch_return_type()) because a) they're much
[15:35] <al-maisan> stay away from the table though ;)
[15:35] <bigjools> shorter, b) it factors the hacky code.  This might be worth having as
[15:35] <bigjools> a review point if everyone agrees?
[15:36] <barry> +1
[15:36] <bac> bigjools: thanks for bringing that up.  i didn't know about the helper
[15:36] <abentley> +1
[15:36] <bigjools> also if you need to patch something and there isn't a helper, write one
[15:36] <jml> a hearty +1 to that last point
[15:37] <bigjools> and make an effort to convert some of the existing crack in the file if you edit it
[15:37] <bigjools> that's it from me
[15:37] <bac> [topic] ensure developers have tested API changes with launchpadlib
[15:37] <MootBot> New Topic:  ensure developers have tested API changes with launchpadlib
[15:38] <bigjools> heh
[15:38] <bac> in that same review i noted bigjools was fixing an API change that hadn't correctly updated the WADL.
[15:38] <bac> had the original code been exercised locally using launchpadlib the error would've been discovered
[15:39] <bac> so, encourage the use of lplib.  it's easy and fun!
[15:39]  * bigjools wants lplib-based tests ...
[15:39] <jml> is it at all possible to automate?
[15:39] <abentley> bac, do you mean that our tests should use the python launchpadlib library?
[15:39] <bac> jml: we discussed that a long time ago and it wasn't do to the credentials problem
[15:39] <jml> do we not include launchpadlib in our dependencies and generate the wadl every single build precisely because of this?
[15:39] <flacoste> bigjools: that's actually possible iirc
[15:40] <bigjools> flacoste: IIRC it wasn;t done because LP would have a dependency on lplib
[15:40] <bac> leonardr has added new functionality to bypass the OAUTH browser dance which may make putting lplib into our test suite feasible now
[15:40] <jml> bigjools, we already depend on lplib
[15:40] <bigjools> oh?>
[15:41] <bigjools> wait, that conflicts with your previous statement
[15:42] <bac> gary_poster: perhaps foundations should revisit this issue to see if it is something we can do now
[15:42] <jml> bigjools, poor phrasing on my part
[15:43]  * gary_poster reads back
[15:43] <jml> bigjools, get rid of the "do", "not" and the question mark, and add "don't we?" to the end.
[15:43] <gary_poster> I think we can have lplib tests now.  I have some httplib hacks to make it possible in one of our layers.
[15:44] <gary_poster> In any case, I was just talking to Leonard about him producing tests like this
[15:44] <gary_poster> so then people can use that as an example
[15:44] <bac> gary_poster: can one of your team do a prototype?
[15:44] <gary_poster> :-) ^^^
[15:44] <bac> [action] leonardr to create an example for automated lplib tests in the launchpad tree
[15:44] <MootBot> ACTION received:  leonardr to create an example for automated lplib tests in the launchpad tree
[15:44] <gary_poster> That should be within this cycle.  It will hopefully be produced as part of the webservice versioning work Leoanrd is doing
[15:44] <bac> great!
[15:45] <bigjools> \o/
[15:45] <bac> that's it, we're out of time.  thanks for coming.
[15:45] <bac> #endmeeting
[15:45] <MootBot> Meeting finished at 09:45.


[21:31] <bac> #startmeeting
[21:31] <MootBot> Meeting started at 15:31. The chair is bac.
[21:31] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[21:32] <mwhudson> hi
[21:32] <bac> hi, welcome to our, uh, quarterly ASIAPAC reviewers meeting
[21:32] <bac> thumper is rockstar around today?
[21:32] <thumper> bac: rockstar is not well today
[21:33] <bac> sorry to hear that
[21:33] <bac> so we had a good meeting today with the AMEU people
[21:33] <bac> before we get to that, though, i'd like to chat with you two about these meetings and how to make them useful and informative.
[21:34] <bac> i want you to be plugged in to what the rest of the reviewers are doing but don't want to show up here and regurgitate info about what happened at the earlier meeting.
[21:34] <bac> thoughts on what you'd like to see?
[21:34] <mwhudson> well, that part is useful tbh
[21:35] <thumper> general agreements on change in style
[21:35] <thumper> or issues that other reviewers are having
[21:35] <mwhudson> it's nice to have a semi-interactive forum to disagree with the others :)
[21:35] <bac> ok.  i try to keep updated with at least the highlghts
[21:36] <bac> and the log files are available
[21:36] <bac> cool mwhudson
[21:36] <bac> well do jump in so it doesn't feel like i'm just cut-n-pasting you a wiki page.  :)
[21:37] <thumper> I just read the outstanding actions section
[21:37] <bac> one non-controversial topic jml brought up (well i brought it up on his behalf) was having reviewers land community contribution branches
[21:37] <thumper> seems reasonable
[21:37] <bac> it seems there are a few people (jml being one) who get pinged to land stuff
[21:37] <mwhudson> well that sounds sensible yes
[21:38] <bac> so we formalized the informal idea that the reviewer is to assume he'll be landing the branch
[21:38] <mwhudson> ok
[21:38] <bac> and if the reviewer cannot then whoever is OCR at the time should consider it part of their duties
[21:38]  * thumper nods
[21:38] <bac> i'll be adding something to summarize that to the wiki
[21:39] <bac> other than wgrant do you have other contributors in your time zone?
[21:39] <thumper> not that I know of
[21:39] <thumper> bac: but we may end up working with some americans
[21:39] <mwhudson> we sometimes get us folks in their evenings
[21:39] <thumper> bac: as it is only 3h to pacific time
[21:39] <mwhudson> nothing regular though
[21:40] <bac> ah, right
[21:40] <bac> that topic led to the issue of 'ec2 land' having a 3-4 hour window where unreviewed and untested code can be pushed to LP and pqm will happily land it
[21:41] <bac> we talked about solutions to that but nothing bubbled up to the top as a winner
[21:41] <thumper> the solution is to finish off merge queues
[21:41] <bac> the only risk-free way to do it is to get a copy of the branch for landing
[21:41] <thumper> we record revision ids
[21:41] <bac> thumper: and will that include integration with PQM?
[21:41] <thumper> bac: getting a copy is safe for now
[21:42] <mwhudson> oh right yeah
[21:42] <thumper> bac: we'll move to tarmac I believe
[21:42] <mwhudson> that really sucks :(
[21:42] <bac> doing it manually is a bit of PITA, though
[21:42] <thumper> bac: although integration with pqm isn't too hard
[21:42] <thumper> yes
[21:42] <thumper> perhaps we'll get the time to finish off merge queues
[21:43] <bac> that'd be sweet.  in the interim we may need to look at some light tool support to make grabbing and landing a branch less painful
[21:43] <bac> we've all become soft since 'ec2 land' is so easy now!
[21:44] <thumper> agreed
[21:44] <thumper> bac: or...
[21:44] <mwhudson> i guess you could do ec2 land --community that would construct the arguments from the mp, copy the branch and then ec2 test -s that
[21:44] <thumper> bac: we extend ec2 land to accept a revid
[21:44] <bac> thumper: it needn't even do that.  it could just take the current one, right
[21:45] <bac> thumper: but even then, there would still be the time it languishes in PQM as a window where new stuff could push
[21:45] <thumper> bac: well, you'd still want the ability to specify it if an unreviewed revision has already been added
[21:45] <bac> but i think just having ec2 not submit if the branch changed after it started it's work would be sufficient
[21:45] <thumper> bac: agreed
[21:46] <bac> i've meant to do that but just haven't gotten around to it
[21:46] <bac> another topic
[21:46] <bac> henning, abentley, and gavin brought up the fact that twisted uses lambdas a lot for defining callback functions
[21:47] <bac> after some discussion we agreed to a "when in rome" approach and decided to relax our coding guidelines to allow lambdas for that purpose when dealing with twisted
[21:47] <mwhudson> well yeah, the total lambda ban is a bit silly for this
[21:47] <mwhudson> in fact i'm fairly sure there are some lambdas in the code already for callbacks...
[21:47] <thumper> I agree with mwhudson
[21:48] <bac> bigjools repeated his mantra of "let common sense prevail" and we moved on
[21:49] <thumper> +1
[21:49] <bac> bigjools also reminded everyone of the circular import patching helper.  i knew nothing about it so i was glad to learn about them
[21:49] <bac> patch_return_type()
[21:50] <bac> makes _schema_circular_blah more readable
[21:50] <thumper> interesting
[21:50] <thumper> hadn't heard of that, so also happy to learn
[21:50] <mwhudson> ah worth knowin
[21:51] <bac> i then got on a soap box to encourage reviewers to insist that API changes be tested via launchpadlib, even if only in an ad hoc fashion
[21:51] <bac> which led us to talk again about getting launchpadlib tests in our test suite.  gary indicated it may be possible now and leonard is supposed to create some examples
[21:51] <bac> there was much celebration
[21:52] <thumper> I remember seeing a launchpad client in some test code
[21:52] <thumper> I remember thinking that that seemed like a much more sensible approach than the webservice doctests
[21:53] <bac> yeah, leondard had to write an approved way to get credentials without using the browser since people were making hacks to do it anyway.  while he didn't like the idea for real code it does allow us to use it for tests
[21:53] <bac> i'm anxious to see this work.
[21:54] <thumper> me too
[21:54] <bac> that pretty much sums up our meeting.
[21:54] <bac> do either of you have anything new to bring up?
[21:54] <mwhudson> well, i don't think i have anything to disagree with this week then
[21:54] <bac> darn
[21:55] <bac> thumper you're generally good for some disagreement...
[21:55] <mwhudson> i'm glad weekly chr is going away i think
[21:55] <bac> yeah, me too
[21:55] <thumper> I'm pretty happy right now, just tired
[21:56] <bac> ok, well that's it then.  i've got to race off to another call
[21:56] <mwhudson> ok, thanks bac
[21:56] <bac> #endmeeting
[21:56] <MootBot> Meeting finished at 15:56.
[21:56] <thumper> thanks bac
[21:56] <mwhudson> talk to you soon
[21:57] <bac> see you next week...

ReviewerMeeting20100210 (last edited 2010-02-11 14:16:59 by bac)