[15:00] <barry> #startmeeting
[15:00] <MootBot> Meeting started at 09:02. The chair is barry.
[15:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:00] <barry> hello everyone and welcome to this week's ameu reviewer's meeting.  who's here today?
[15:00] <gmb> me
[15:01] <gmb> ...
[15:01] <sinzui> me
[15:01] <statik> me
[15:01] <EdwinGrubbs> me
[15:01] <flacoste> me
[15:01] <allenap> me
[15:01] <intellectronica> me
[15:01] <bac> me
[15:02] <barry> BjornT: ping
[15:02] <barry> bigjools: ping
[15:02] <BjornT> me
[15:02] <bigjools> me
[15:02] <schwuk> me
[15:02] <barry> danilos: ping
[15:02]  * sinzui passes caffeine to the meeting 
[15:03]  * bigjools has an alarm for the meeting and still misses the start
[15:03] <barry> [TOPIC]  * Next meeting
[15:03] <MootBot> New Topic:   * Next meeting
[15:03] <barry> week += 1?
[15:03] <barry> anybody know you'll be sprinting or offline?
[15:04] <bigjools> I hope to be around but it depends on how my son's surgery goes on Monday
[15:05] <barry> bigjools: hope everything goes well!
[15:05] <bigjools> barry: thanks, me too :)
[15:05] <barry> [TOPIC]  * Action items
[15:05] <MootBot> New Topic:   * Action items
[15:05] <barry>  * barry to get with flacoste to open pqm bugs
[15:05] <barry> flacoste: we'll chat after the meeting
[15:05] <flacoste> hmm
[15:06] <flacoste> can't rememberr what this wa about
[15:06] <barry> flacoste: new item from asiapac meeting
[15:06] <barry> [TOPIC]  * Queue status
[15:06] <MootBot> New Topic:   * Queue status
[15:07] <barry> only observations i have is that pqm is HUGE
[15:07] <barry> and there are a few new pink branches on pending-reviews
[15:07] <barry> bigjools: i know i have a mentor review for you today
[15:08] <bigjools> pqm has 17 branches and it's only week 2 ... oy
[15:08] <barry> any comments on the queue?
[15:09] <barry> yeah, it's crazy!
[15:09] <sinzui> I think we have a lo of pink because we have been alocating at the end of the on-call review
[15:09] <bigjools> yeah I got one today that was already 2/3 days old
[15:09]  * barry apologizes for forgetting to do that this week
[15:09] <intellectronica> i just picked up a branch that was put up for review a week ago, and got rejected
[15:09] <sinzui> bigjools: That is because I suck. I miss-assigned it
[15:10] <intellectronica> let's try to get those branches into someone's hands quickly
[15:10] <bigjools> sinzui: you purposely giving me soyuz ones? :)
[15:10] <intellectronica> it may be an idea, to ask that if someone rejects a branch because of workload (rather than a problem with the branch), they try to find someone else so take on it
[15:10] <sinzui> bigjools: I did pause for a moment before pass it to you
[15:11] <bac> intellectronica: good idea
[15:11] <bigjools> np, at this busy time it makes sense
[15:11] <barry> intellectronica: +1
[15:12]  * sinzui must bring up the subject of how assigned branches relate to on-call times
[15:12] <barry> sinzui: ?
[15:13] <salgado-brb> me
[15:13] <salgado> sorry
[15:13] <sinzui> barry: Do we subtract the time done on an assigned review from the time we would spend doing on-call reviews?
[15:13] <barry> sinzui: everyone except you
[15:13] <barry> sinzui: :)
[15:14] <sinzui> barry: That is is not entirely true. I take only easy one on saturday
[15:14] <barry> sinzui: dunno.  if we're getting more branches than we can reasonably review, well, we've got other problems
[15:15] <barry> sinzui: i generally work them (and mentor reviews) around other work
[15:15] <intellectronica> i usually just go with the flow, and try to only pick up branches out of review days if i've come to a natural pause, or it makes sense in the grand scheme of things
[15:15] <intellectronica> sinzui: if it becomes too much of a burden, you should probably start rejecting branches
[15:16] <sinzui> I see one or more branches are not really need-review too.
[15:16] <sinzui> intellectronica: EdwinGrubbs ask me the question after I assigned him a branch
[15:17] <sinzui> We don't have an official answer
[15:18] <sinzui> half of the pink branchs are really needs-reply
[15:18] <barry> i think the answer is, reject branches if you overloaded.  if lots of branches are piling up rejected or not meeting the sla, then this part of the process is saturated and we need to find other solutions
[15:19] <barry> sinzui: is that just reviewers not keeping PR up-to-date?
[15:19] <sinzui> barry. correct
[15:19] <bigjools> pending branches has an update lag though
[15:19]  * sinzui was reading the launchpad-reviewer archive
[15:19] <sinzui> bigjools: but the lag is not measured in days
[15:20] <bigjools> ah, that would be bad then
[15:20] <bigjools> it would be interesting to see how many of those unchanges ones are from on-call reviews where the reviewer didn't know there was an entry in PR
[15:20] <bigjools> unchanged*
[15:21] <barry> bigjools: i always ask for a PR block for any branch i review
[15:21] <bigjools> right, but I don't think all the reviewers do that
[15:21] <barry> i know
[15:21] <bigjools> and some devs stick one in anyway
[15:22] <bigjools> hurry up PR-killer :)
[15:22] <barry> bigjools: that's the real answer! :)
[15:22] <barry> anyway, moving on
[15:22] <barry> [TOPIC]  * Mentoring update
[15:22] <MootBot> New Topic:   * Mentoring update
[15:22] <bigjools> perhaps we can get time assigned for that post 2.0
[15:23] <barry> any comments here either from mentors or mentorees?
[15:23]  * bigjools still wants a translations branch to review
[15:23] <barry> bigjools: maybe add a note on your PR queue?
[15:23] <bigjools> good idea
[15:24] <barry> [TOPIC]  * Review process
[15:24] <MootBot> New Topic:   * Review process
[15:24] <barry>   * Module alternatives - do we really want them?
[15:24] <barry> dunno what this one is about
[15:25] <barry> who added this one?  please take the floor
[15:25] <gmb> intellectronica, I think...
[15:25] <intellectronica> right
[15:26] <intellectronica> so, sometimes, we have imports of the form `try: from import cFoo as Foo \n except: import Foo`
[15:26] <intellectronica> do we really want to do that?
[15:26] <intellectronica> consider that we have pretty tight control over the environment in which we run
[15:26] <sinzui> I have done that twice, both times I had an XXX about when the hack could be removed
[15:27] <intellectronica> and that falling back silently to an inefficient implementation, is not necessarily a good thing
[15:27] <sinzui> intellectronica: The Gutsy to Hardy transition is a good example when we need while all the machines are upgrading
[15:28] <intellectronica> i mean, what what happens if one day the native-code module disappears from one of the production servers? we'll only notice this when the performance starts degrading
[15:28] <barry> i don't think we need to do that for things like cStringIO, etc.  just use the most appropriate one
[15:28] <intellectronica> don't we run everything on hardy now anyway?
[15:28] <bigjools> not quite
[15:29] <barry> after today tho, right?
[15:29] <intellectronica> and specifically, what about elementtree? is the native code version a new thing we're not guaranteed to have on older systems?
[15:29] <bigjools> no, next week will see everything upgraded IIRC
[15:29] <sinzui> intellectronica: We removed one hack shortly after PQM was upgraded
[15:29] <barry> that's a bit different because when we /do/ switch to py2.5, we'll have it available there instead of as a separate pkg
[15:30] <flacoste> barry: but the import path is different
[15:30] <flacoste> from xml.etrees
[15:30] <flacoste> or etree
[15:30] <barry> flacoste: right.  isn't that what intellectronica means?
[15:31] <allenap> Is it worth having a canonical/alternatives.py module which does all of this, and we import from there. Then we all use the right modules (and we don't get false lint)
[15:31] <intellectronica> allenap: i like this idea a lot
[15:32] <flacoste> it does introduce a layer of indirection
[15:32] <flacoste> but i guess from canoniocal.alternives import ElementTree
[15:32] <flacoste> wouldn't be too confusing
[15:32] <intellectronica> flacoste: sure, but it should be used sparingly. in most cases we should import the most specific version
[15:32] <barry> yes, very sparingly
[15:34] <barry> is elementtree the only example?
[15:35] <barry> well, that one fizzled out :)  any other topics for today?
[15:35] <BjornT> looks like it
[15:36] <intellectronica> that's the only example i have
[15:36] <barry> BjornT: if so, i wouldn't add all the extra machinery just for it
[15:36] <BjornT> i agree. is there a bug open on lint for this?
[15:36] <intellectronica> yeah, i guess not. but i'd recommend adding an XXX if we must do this trick
[15:37] <intellectronica> BjornT: what do you mean? would like lint warning for such cases suppressed?
[15:37] <BjornT> intellectronica: well, why is lint complaining about this?
[15:37] <BjornT> intellectronica: i don't want lint to complain at all
[15:38] <intellectronica> BjornT: the thing is, to make sure that it's correct, the try clause should have only one statement
[15:38] <intellectronica> i suppose if we handle that correctly, we can have lint not complain
[15:38] <BjornT> intellectronica: right. and it has only one statement, hasn't it?
[15:39] <intellectronica> yes. if we handle this specific case it should be ok
[15:39] <intellectronica> i'll file a bug on lint (if there isn't one already)
[15:39] <intellectronica> ACTION: ^^^
[15:40] <barry> [ACTION] intellectronica to file bug on lint issue regarding elementtree import
[15:40] <MootBot> ACTION received:  intellectronica to file bug on lint issue regarding elementtree import
[15:40] <barry> cool.  that's all i have today.
[15:40] <sinzui> That special case will require either an ugly sed hack, or a replacement lint script written in python
[15:41] <intellectronica> python, puh...
[15:41] <intellectronica> thanks barry
[15:41] <barry> i take that as a sign.
[15:41] <barry> #endmeeting
[15:41] <MootBot> Meeting finished at 09:43.
[15:41] <barry> thanks everyone