[15:00] <barry> #startmeeting
[15:00] <barry> heh
[15:00] <barry> hello everyone and welcome to this week's ameu reviewer's meeting
[15:00] <barry> i know a lot of people are away, but who's here today?
[15:00] <sinzu1> me
[15:00] <sinzui> me
[15:00] <allenap> me
[15:00] <intellectronica> me
[15:00] <schwuk> me
[15:00] <bac> me
[15:00] <salgado> me
[15:01] <EdwinGrubbs> me
[15:01] <gmb> me
[15:01] <intellectronica> sorry, everyone, for allenap and mine no-show today. we've been working very hard on that hacking thing
[15:01] <intellectronica> http://farm3.static.flickr.com/2395/2511062130_f148267b7f.jpg
[15:02] <barry> intellectronica: why is allenap smiling?  that doesn't look like work! :)
[15:02] <intellectronica> barry: something to do with JSON marshaling, iirc
[15:02] <barry>  * Roll call
[15:02] <barry>  * Next meeting
[15:02] <barry>  * Action items
[15:02] <barry>  * Queue status
[15:02] <barry>  * Mentoring update
[15:02] <barry>  * Review process
[15:02] <barry>    * Help people learn how big branches can be split up (BjornT)
[15:02] <barry>    * Adopt mars suggestion for more-specific imports; don't do multiline imports; communicate decision.
[15:03] <barry>  * Next meeting
[15:03] <barry> everyone okay with week += 1
[15:03] <barry> anybody know of sprints or holidays, or know you won't be here?
[15:04] <intellectronica> i won't be here, i'll be on vacation
[15:04] <salgado> I won't be here. vacation as well
[15:04] <danilos> me
[15:04] <barry> cool
[15:04] <barry>  * Action items
[15:04] <danilos> as in, me here today, though late
[15:04] <barry>  * barry drive to decision about multiline sequences
[15:05] <barry> so we've made a decision: we're going to adopt mars's suggestion and not multiline imports.  hopefully that will cut down on conflicts, but even if it doesn't, it'll be a win
[15:06] <barry> as we're all agreed __init__.py's import-*'s suck :)
[15:06] <barry> [ACTION] barry to update style guides and email ml
[15:06] <barry>  * barry to solicit ideas to better handle review scheduling and workload
[15:06] <barry> not done
[15:07] <barry>  * flacoste to add `safe_hasattr()` to `lazr.utils`
[15:07] <flacoste> i suck
[15:07] <flacoste> carry on
[15:07] <barry> ;)
[15:07] <barry>  * bjorn to add recommendation to test style guide saying don't use asserts in doctests
[15:07] <sinzui> That will wait until a week 0
[15:07] <barry> i don't think BjornT is here
[15:07] <barry> so we'll just carry on
[15:08] <gmb> barry: He's in a UDS session, I think.
[15:08] <barry>  * Queue status
[15:08] <barry> gmb: np
[15:08] <barry> salgado: you're switching ocr today, is that right?
[15:08] <salgado> barry, that's right
[15:09] <salgado> will update the wiki
[15:09] <barry> salgado: thanks for helping out w/coverage!
[15:09] <barry> looks like we have a few pink branches
[15:10] <barry> EdwinGrubbs: what's happening w/ the cprov and julian branches?
[15:10] <EdwinGrubbs> barry: I think they are done except for mentoring possibly.
[15:10] <salgado> they have been mentored
[15:11] <salgado> I think
[15:11] <barry> cool, so just waiting to land?
[15:11] <salgado> I think it's just the status that hasn't been updated
[15:11] <barry> np
[15:11] <barry> schwuk: any word on the adeuring #1 branch?
[15:12] <schwuk> barry: in progress
[15:12] <cprov> salgado: you did, I will reply it this evening. Sorry for the delay.
[15:12]  * schwuk forgot to check pending reviews and missed it
[15:12] <barry> schwuk: cool, thanks.  iirc, there was reluctance to start on the 2 and 3 branches until the first one got reviewed
[15:12] <sinzui> I think splitting a large branch and submitting all the parts at once is unfair.
[15:12] <barry> schwuk: you should check out bac's script :)
[15:13] <bac> barry,sinzui : we talked to abel about it yesterday.  he said they are pretty dependent.  2 & 3 should be withdrawn
[15:13] <schwuk> barry: I had it running, but I broked it :(
[15:13] <barry> sinzui: if they are highly intertwined
[15:13] <bac> but due to abel being at UDS i didn't get to talk with him directly
[15:13] <barry> bac: ok, thanks for the feedback.  i'll remove those branches from PR
[15:14] <barry> bac: and email abel so he knows to resubmit them when he gets #1 through
[15:14] <barry> anything else on the queue?
[15:14] <bac> barry: also make sure he knows about the depends option in review-submit
[15:14] <barry> bac: good point!
[15:15] <barry> moving on...
[15:15] <barry>  * Mentoring update
[15:15] <barry> any feedback, issues?
[15:16] <barry>  * Review process
[15:16] <barry>    * Help people learn how big branches can be split up (BjornT)
[15:17] <barry> well, we didn't really reach any conclusions on this one, but for the folks working on abel's branch, can you think about this some and make any (general) suggestions to the ml?
[15:18] <barry>    * Adopt mars suggestion for more-specific imports; don't do multiline imports; communicate decision.
[15:18] <barry> already mentioned.
[15:18] <barry> anyway, that's all i have on the agenda.  does anybody have any other topics?
[15:19] <sinzui> I think splitting a large branch and submitting all the parts at once is unfair.
[15:19] <intellectronica> sinzui: huh?
[15:19] <intellectronica> you should submit as soon as the code is available
[15:19] <sinzui> I think that stands as a topic. The last branch is in a precarious position.
[15:20] <sinzui> A mistake in the bottom of the design may topple the top branch
[15:20] <bac> and even mundane changes can bubble through all parts causing the reviewers to do extra work
[15:21] <sinzui> intellectronica: I agree that once a chunk of code is ready for review, it should be.
[15:21] <intellectronica> true, but i think if you already reached the point where you have all code ready at once there isn't much that can be done about this
[15:21] <intellectronica> we should pay attention to 'Depends:' in the submission, and try to spot problematic cases
[15:22] <intellectronica> also, it should be the responsibility of the developer to sort out effective reviews
[15:22] <barry> well, the pre-impl should have helped with any design issues, no?
[15:22] <sinzui> Yep
[15:22] <sinzui> A pre-imp should estimate the number of lines required and plan the branches
[15:23] <schwuk> sinzui: +1
[15:23] <barry> intellectronica: true, but devs should be conscious of not wasting reviewers time, so they should be highly confident their branches are solid
[15:23] <barry> and if not, get more up-front help in planning the branches
[15:23] <schwuk> If a branch is a few lines over the limit, fair enough. If it's 100+ lines over then the work hasn't been chunked properly (see pre-imp calls)
[15:23] <intellectronica> schwuk: b.t.w did you have a pre-imp with abel? you are the developer most likely to be able to have an effective one with him
[15:24] <schwuk> intellectronica: no, and he's not listed a pre-imp call on the review request.
[15:26] <barry> i will mention this to him, when i email him about his branches
[15:26] <schwuk> barry: I've queried it in my review as well.
[15:27] <barry> schwuk: thanks
[15:28] <barry> anything else?
[15:29] <barry> #endmeeting
[15:29] <barry> thanks everyone!
[15:29] <schwuk> thanks barry