[15:00] <barry> #startmeeting
[15:00] <MootBot> Meeting started at 09:00. 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] <danilos> me
[15:00] <EdwinGrubbs> me
[15:00] <mars> me
[15:01] <bigjools> me
[15:01] <bac> me
[15:02] <barry> jtv: hi!
[15:02] <jtv> hi barry!
[15:02] <barry> adeuring: ping
[15:02] <barry> allenap: ping?
[15:02] <adeuring> whoops, me
[15:02] <salgado> me!
[15:02] <barry> BjornT: ping
[15:02] <gary_poster> me
[15:02] <barry> cprov: ping
[15:02] <BjornT> me
[15:03] <barry> gmb: ping
[15:03] <barry> intellectronica: ping
[15:03] <gmb> me
[15:03] <barry> rockstar: ping
[15:03] <intellectronica> me
[15:03] <jtv> me
[15:03] <barry> sinzui: ping
[15:03] <sinzui> hi barry
[15:03] <flacoste> me
[15:04] <barry> hi everyone
[15:04] <sinzui> me
[15:04] <barry> [TOPIC] agenda
[15:04] <MootBot> New Topic:  agenda
[15:04] <barry>  * Roll call
[15:04] <barry>  * asiapac meeting time change
[15:04] <barry>  * deprecate zapi and ztapi in favor of zope.component APIs, gary
[15:04] <barry>  * Action items
[15:04] <barry>  * Mentoring update
[15:04] <barry>  * Peanut gallery (anything not on the agenda)
[15:05] <barry> [TOPIC]  * asiapac meeting time change
[15:05] <MootBot> New Topic:   * asiapac meeting time change
[15:05] <barry> so just a quick note that we've changed the date and time of the asiapac meeting.  10pm my time was just too difficult for me to remember, so now it's wednesdays utc 2300
[15:06] <barry> which i think also makes it easier to communicate between the two review teams
[15:06] <barry> just in case y'all wanted to drop by :)
[15:06] <danilos> in case I have no idea what to do at midnight, I might ;)
[15:06] <barry> :)
[15:06] <barry> [TOPIC]  * deprecate zapi and ztapi in favor of zope.component APIs, gary
[15:06] <MootBot> New Topic:   * deprecate zapi and ztapi in favor of zope.component APIs, gary
[15:07] <barry> gary_poster: the floor is yours
[15:07] <flacoste> for US fols, that's nice, we'll be able to drop by
[15:07] <gary_poster> :-) k
[15:07] <barry> flacoste: yep.  we don't have jamesh's tz to worry about any more :)
[15:07] <gary_poster> Zope deprecated zapi and ztapi quite awhile ago
[15:07] <gary_poster> Jim Fulton significantly refactored the zope.component API so that it was easier to use it directly
[15:08] <gary_poster> these APIs are more parallel (register/unregister for instance for adapters and utilities)
[15:08] <rockstar> me
[15:08] <gary_poster> and also don't hide how views work as adapters, for instance, behind what I believe to be an unnecessary and ultimately confusing veil
[15:09] <gary_poster> I think we (probably me) should come up with a cheat sheet on "if you were doing this, try doing this"
[15:09] <gary_poster> but Zope is already leaving that stuff behind, and I think we should too
[15:09] <barry> gary_poster: what kinds of things do we commonly do now that would be better off w/o zapi?
[15:09] <sinzui> I only see zapi and ztapi in old code. I have never reviewed code that added it.
[15:09] <barry> gary_poster: % fc lib/canonical zapi | wc -l
[15:09] <barry> 23
[15:10] <gary_poster> sinzui: so, do you mean, it is already effectively deprecated?
[15:10] <sinzui> gary_poster: I think so
[15:10] <barry> sinzui: 23 hits on zapi, 35 hits on ztapi
[15:11] <barry> which doesn't seem like much
[15:11] <gary_poster> barry: zapi should be completely unnecessary.  same with ztapi.  It's just cruft, keeping people from understanding the actual use of the component code, for no particular win
[15:11] <gary_poster> ok, so maybe simple proposal:
[15:11] <sinzui> gary_poster: I only know what Phillip wrote in his book. I think flacoste/SteveA have driven us from using it in the past two years.
[15:12] <gary_poster> 1) Someone (I?) does (do) a branch that rips out the remainder
[15:12] <barry> maybe the newest code is in l/c/lazr/rest/tales.py?
[15:12] <gary_poster> 2) that policy is official
[15:12] <allenap> me
[15:12] <gary_poster> the reason that this came up is that I saw leonardr use it
[15:12] <barry> +1, +1
[15:12] <gary_poster> ok
[15:13] <gary_poster> at least that was non-controversial ;-)
[15:13] <barry> gary_poster: maybe start with lib/canonical/lazr?
[15:13] <gary_poster> yeah
[15:13] <jtv> gary_poster: it was the "(I?)" part that sold us
[15:13] <gary_poster> lol :-)
[15:14] <gary_poster> k, done, unless someone else wants to say something
[15:14] <barry> jtv: are you saying that gary_poster is our jerry maguire?
[15:14] <barry> gary_poster: thanks
[15:14] <gary_poster> :-)
[15:14] <barry> [TOPIC]  * Action items
[15:14] <MootBot> New Topic:   * Action items
[15:14] <barry>  * abentley to email ml and gustavo with suggestions for improving storm
[15:14] <barry> abentley: just in time! :)
[15:14] <abentley> barry: Done.
[15:15] <jtv> barry: EPOPCULTREF
[15:15] <abentley> barry: Response was not very positive.
[15:15] <gary_poster> heh
[15:15] <barry> abentley: yeah
[15:15] <gary_poster> conversation with stub seemed potentially fruitful though
[15:15] <abentley> In fact, he said if we like the SQLObject api, we should use the shim
[15:17] <flacoste> well
[15:17] <barry> what do you guys think?  personally, i prefer both native storm query syntax and native storm class definitions
[15:17] <flacoste> that has some drawbacks
[15:17] <flacoste> and I don't think the shim is what we want to use
[15:17] <flacoste> native storm query: yes
[15:17] <flacoste> native storm class defs: not sure at all
[15:17] <abentley> I think stores should be optional.
[15:17] <abentley> Most of the time, we don't want or need them.
[15:18] <flacoste> the problem with the shim is that the results objects are incompatible
[15:18] <bigjools> as I found to my cost
[15:19] <abentley> Okay, so if we make our own base class, would that be acceptable?
[15:19] <barry> flacoste: what would you propose instead for class defs?  base class/metaclass?
[15:20] <flacoste> base class is probably best
[15:20] <barry> abentley: not outside the realm of possibility
[15:20] <flacoste> as metaclass usually makes people's brain explode
[15:20] <barry> flacoste: indeed
[15:20] <barry> flacoste: how would that change the attribute definition syntax?
[15:21] <flacoste> i think we might need a metaclass for that, i don't know
[15:21] <flacoste> and maybe the native storm syntax isn't that bad
[15:21] <barry> flacoste: i think we would, but i guess my question is: what would you do differently?
[15:21] <flacoste> it's just that I agree with abentley that the ID stuff is kind of boring
[15:22] <barry> true
[15:22] <flacoste> well, the attribute names for instance
[15:22] <flacoste> field_id instead of fieldID
[15:22] <bigjools> the only real problem with Storm syntax for me is importing a gazillion content classes
[15:23] <allenap> bigjools: That does have the advantage that things break hard when classes are changed.
[15:23] <allenap> and early.
[15:23] <barry> is anybody motivated enough to try an experiment here?
[15:23] <abentley> bigjools: Not seeing the connection.
[15:24] <bigjools> abentley: if you use Python expressions for the query joins ...
[15:24] <abentley> bigjools: Is that compared to raw SQL with SQLObject?
[15:25] <bigjools> yes. if you write a string in SQL then you don't have the import pain, but then Storm can't work out the FROM tables
[15:25] <jtv> barry: what experiment did you have in mind?
[15:26] <flacoste> barry: well, i think abentley's gripes are good, so if he's willing to try to cook up a base class that suits him, that would be a good start
[15:26] <bigjools> allenap: that's a great point
[15:26] <abentley> flacoste: Sure, I'm happy to start with that.  Metaclass foo later.
[15:26] <barry> jtv: a base class/metaclass to make various common boring or painful things easier
[15:27] <barry> abentley: cool.  i know there's an experiments page somewhere but my firefox is misbehaving right now
[15:28] <barry> [ACTION] abentley to experiment with a base class to ease the pain and boredom with storm
[15:28] <MootBot> ACTION received:  abentley to experiment with a base class to ease the pain and boredom with storm
[15:29] <barry>  * flacoste to take dead zone reviews issue to ml
[15:29] <flacoste> done
[15:29] <flacoste> not sure of the resolution there
[15:29] <flacoste> though
[15:29] <barry> flacoste: me neither
[15:29] <barry> jtv: what do you think about that thread?
[15:30] <barry> jtv: i think you and stub get weighted more heavily here as you're the most tz challenged
[15:31]  * barry taps the mic and asks "is this thing still on?"
[15:31] <jtv> barry: I do agree, just slightly concerned about having yet more ways to write a database class
[15:31] <jtv> barry: sorry, hard to type at this temperature
[15:31] <rockstar> jtv, +1
[15:31] <barry> jtv: TOOWTDI
[15:31] <barry> jtv: and you're dutch so it should be obvious to you
[15:31] <gary_poster> :-)
[15:32] <barry> jtv: sorry, i meant the dead zone review thread
[15:32] <jtv> barry: ahhh
[15:33] <jtv> barry: I thought we already were discussing that on the ml
[15:33]  * jtv reads back
[15:33] <barry> jtv: we are, just wanted to give you a higher bandwidth channel.  but it's okay, we can continue on the ml
[15:34] <jtv> barry: yes, sorry, having that one line added in the middle changed the meaning of my backlog
[15:34] <jtv> I think we agreed that cover letters are good, and possibly better than asking a reviewer personally
[15:35] <barry> cover letters + mp + (maybe?) irc topic?
[15:35] <jtv> barry: ah yes, the topic line, I liked that
[15:36] <barry> jtv: cool.  let's see if we can make that work. we can always try something else if need be
[15:36] <jtv> maybe a "candidate queue"?
[15:36] <jtv> after all, the "queue" is what an OCR has accepted
[15:36] <jtv> or a "review backlog"
[15:37] <barry> jtv: backlog: xxx in the topic?
[15:37] <jtv> barry: looks lovely
[15:37] <danilos> we can have two queues, one for on call, another for backlog, with OCRs reviewing alternately one from each
[15:37] <barry> danilos: +1
[15:37] <jtv> oh, practical problem: how does the next reviewer know which *branch*?  that's too long to record in the topic
[15:38] <barry> jtv: give an mp #?
[15:38] <danilos> how about just using links to bugs or MPs?
[15:38] <jtv> Yeah, nick:mp# would do it for me
[15:39] <barry> danilos: i think that makes the topic too long
[15:39] <abentley> hmm: The MP ids are unique.  Maybe we should provide a direct link to them.
[15:39] <danilos> abentley: yeah, that would be an improvement (something like we have for bugs)
[15:40] <barry> abentley: do you mean, have the bot recognize "mp 1234"?
[15:40] <danilos> barry: I meant only bug ids (and bugs will point to branches, which will point to mps :)
[15:40] <barry> danilos: ah yes, fair enough
[15:40] <danilos> I'd prefer a bookmarklet https://code.launchpad.net/+merge-proposal/%s :)
[15:41] <jtv> danilos: good idea, but blueprint names get longer
[15:41] <danilos> jtv: they are also not linked to branches afaik
[15:41] <abentley> barry: No, I meant to be able to put code.launchpad.net/mp/1234 as a url.
[15:41] <barry> abentley, jtv, danilos let's see if we can hash out the details on the ml
[15:41] <jtv> danilos: good point :)
[15:42] <barry> only a couple of minutes left, so...
[15:42] <barry>  * gary to email list about RENormalizing test, investigate alternate inline spellings
[15:42] <gary_poster> done.  See how to do it.  doctest not easily extensible for this, so will need to hack.
[15:42] <barry> i think that one's done
[15:42] <barry> gary_poster: thanks
[15:43] <barry>  * barry to add `pretty()` functions to reviewers docs
[15:43] <barry> i suck, not done
[15:43] <barry>  * flacoste to work on API reviewer cheat sheet
[15:43] <flacoste> i suck, not done
[15:43] <barry> [TOPIC] peanut gallery
[15:43] <MootBot> New Topic:  peanut gallery
[15:43] <danilos> I'd like to raise one issue here
[15:43] <barry> does anybody have anything not on the agenda?
[15:43] <barry> danilos: go4it
[15:43] <flacoste> if it's not done next week, i change my name to flacoste_hoover
[15:43] <danilos> the lightness of our reviews makes them not be that useful anymore as a learning tool
[15:43] <barry> flacoste: :)
[15:44] <danilos> we need to reiterate some points even if they are not necessarily what we expect developer to do
[15:44] <flacoste> what do you mean?
[15:44] <flacoste> or can you give an example?
[15:44] <danilos> eg. concrete example I have: we should mention LaunchpadForm for any form which is not using it
[15:44] <flacoste> good point
[15:44] <danilos> Henning was not aware of LaunchpadForm and hacked around even though he modified quite a few forms before
[15:45] <danilos> just a question for reviewers to ask: "why is this not using this and that infrastructure we have"
[15:46] <barry> danilos: +1
[15:46] <gmb> I didn't realise that our reviews were that shallow.
[15:46]  * bigjools fears for future Soyuz reviews
[15:47] <gmb> Just last week EdwinGrubbs pointed out a much easier way for me to do something that I'd spent ages hacking around with.
[15:47] <danilos> (even if reviewer knows the answer, we should help developers get to learn more about existing infrastructure, since there's so much of it)
[15:47] <bigjools> we need an infrastructure cheat sheet
[15:47] <gmb> bigjools: The only way you can have a shallow soyuz review is if the person doing the review is dead.
[15:47] <al-maisan> :)
[15:47] <gary_poster> :-)
[15:47] <flacoste> lol
[15:47] <bigjools> gmb: that can be arranged!
[15:47] <danilos> bigjools: the idea is not to force people to switch to new infrastructure, just to be aware of it, and understand why it's not being used
[15:48] <bigjools> danilos: that's fine - I just know that we have lots of, er, legacy code shall we say, done before a lot of the infrastructure was in place
[15:48] <bac> it works the other way too.  yesterday i saw something cool sinzui was doing in a doctest i was reviewing and adopted it.
[15:48] <danilos> bac: indeed
[15:49] <bigjools> bac: yes, that's a great reason to be a reviewer
[15:49] <danilos> anyway, we're over time already, and I think I am done
[15:49] <barry> bac: we should find a way to share those insights across the team!
[15:49] <barry> danilos: thanks. and apologies for going over
[15:49]  * sinzui just wanted the code to be readible
[15:49] <danilos> barry: we've tried so far to do that using wikis and mailing lists, but it doesn't really work out
[15:49] <mars> danilos, how about cleaning up technical debt as a learning exercise, rather than reviewing or using a cheat sheet?
[15:49]  * barry will eagerly await bac's email describing this insight :)
[15:49] <bigjools> I would like a cheat sheet, personally
[15:50] <mars> that's how I started - fixing callsites, submitting 2000-line patches...
[15:50] <jtv> mars: it's not always stuff you'd easily recognize as tech debt
[15:50] <gary_poster> cheat sheets get awfully big
[15:50] <bigjools> then the info is shared
[15:50] <gary_poster> we already have some
[15:50] <danilos> gary_poster: only if you want to cheat in everything you do :)
[15:50] <gary_poster> that are really really big
[15:50] <gary_poster> :-)
[15:50] <bigjools> gary_poster: they can't get bigger than the doctests we have though :)
[15:50] <gary_poster> heh
[15:50] <barry> :)
[15:50] <barry> anyway.  let's break for today
[15:50] <barry> #endmeeting
[15:50] <MootBot> Meeting finished at 09:50.
[15:50] <flacoste> thanks barry
[15:51] <barry> thanks everyone!
[15:51] <bigjools> thanks barry
[15:51] <jtv> thanks barry
[15:51] <gary_poster> thanks, bye
[15:51] <danilos> thanks all
[23:01] <barry> #startmeeting
[23:01] <MootBot> Meeting started at 17:01. The chair is barry.
[23:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[23:01] <barry> hello and welcome to the first of our newly scheduled asiapac reviewers meetings.  who's here today?
[23:01]  * barry pings jml thumper and mwhudson 
[23:01] <mwhudson> hello
[23:02]  * thumper pongs
[23:02] <thumper> :)
[23:02] <jml> barry: hi
[23:02] <barry> yay!  how's it going guys?
[23:02] <thumper> busy
[23:02] <jml> yeah, very busy
[23:03] <thumper> too many things to do at once
[23:03] <barry> mwhudson: very very busy?
[23:03] <jml> people keep finding bugs in our software
[23:03] <thumper> oh, and I have a dentist appt in 1 hour
[23:03] <mwhudson> barry: you guessed it!
[23:03] <thumper> which I need to walk to
[23:03] <barry> well then, we'll make this quick!
[23:03] <barry> [TOPIC] agenda
[23:03] <MootBot> New Topic:  agenda
[23:03] <barry> * Roll call
[23:03] <barry>  * asiapac meeting time change
[23:03] <barry>  * deprecate zapi and ztapi in favor of zope.component APIs, gary
[23:03] <barry>  * Action items
[23:03] <barry>  * Mentoring update
[23:03] <barry>  * Peanut gallery (anything not on the agenda)
[23:04] <barry> that's basically copied from the ameu meeting this morning, which i have not had time to write up yet
[23:04] <thumper> ok
[23:04] <mwhudson> well the first one seems to have worked
[23:04] <barry> indeed!
[23:04] <barry> [TOPIC]  * deprecate zapi and ztapi in favor of zope.component APIs, gary
[23:04] <MootBot> New Topic:   * deprecate zapi and ztapi in favor of zope.component APIs, gary
[23:04] <barry> let me see if i can channel gary_poster
[23:05] <thumper> do anyone outside foundations care?
[23:05] <jml> barry_imposter
[23:05] <thumper> haha
[23:05] <barry> thumper: probably not.  there's only about 70 hits for both in our code base
[23:05] <mwhudson> i've used ztapi in a test i think once
[23:05] <barry> and most of those are in very old code
[23:05] <mwhudson> i won't do it again :)
[23:05] <mwhudson> next
[23:06] <barry> mwhudson: yeah, you better not.  gary_poster is a big guy
[23:06] <barry> [TOPIC]  * Action items
[23:06] <MootBot> New Topic:   * Action items
[23:06] <mwhudson> i can't imagine him as a brawler though some how
[23:06] <barry> :)
[23:06] <barry>  * abentley to email ml and gustavo with suggestions for improving storm
[23:06] <jml> I think that's been done for some time :)
[23:07] <barry> abentley: right.  though today we talked about an experiment that abentley will conduct to see if he can create a base class that makes some annoyances simpler
[23:07] <barry> we still do not want to use the sqlobject shim
[23:07] <jml> barry: sure.
[23:07] <barry> we were generally agreed that native storm class defs and queries are fine with us
[23:08] <jml> ok.
[23:08] <barry> though foo_id is boring
[23:08] <barry> and needing to specify the store is boring
[23:08] <barry> we'll see what he comes up with
[23:08] <thumper> LPStorm class?
[23:08] <jml> it's also complicated :)
[23:08] <mwhudson> do you have to have the foo_id as a separate definition?
[23:08] <jml> barry: so I guess this is out-of-scope for reviewer meetings for the moment?
[23:08] <barry> thumper: something like that, tho i suspect a metaclass may be necessary
[23:08] <thumper> mwhudson: I believe so
[23:08] <barry> mwhudson: yep
[23:09] <thumper> I've seen both field_id and fieldID
[23:09] <thumper> do we have a standard?
[23:09] <barry> mwhudson: foo_id = Int(primary=True); foo = Reference(foo_id, Foo.id)
[23:09] <barry> thumper: we do not
[23:09]  * barry prefers and uses foo_id
[23:09]  * thumper votes for field_id
[23:09] <barry> thumper: rock on
[23:09] <mwhudson> barry: wouldn't foo = Reference(Int(primary=True), Foo.id) work?
[23:09] <barry> mwhudson: interesting!  dunno
[23:09] <thumper> barry: can you add an agenda item to add it for the next reviewer meeting
[23:10] <mwhudson> if it does, i think we can write a convenience class....
[23:10] <barry> [ACTION] barry will add foo_id vs fooID to next reviewers meeting
[23:10] <MootBot> ACTION received:  barry will add foo_id vs fooID to next reviewers meeting
[23:10] <mwhudson> FKeyIDRef or something
[23:10] <thumper> mwhudson: sometimes you need to do field.foo_id.is_in([1,2,3])
[23:10] <jml> mwhudson: best. name. evar. :P
[23:10] <mwhudson> ah ok
[23:10] <thumper> mwhudson: a bit hard to do without a defined foo_id
[23:10] <mwhudson> i should mention this on the list i guess
[23:10] <barry> mwhudson: please do
[23:11] <barry> next?
[23:11] <thumper> ya
[23:11] <thumper> yarp
[23:11] <barry>  * flacoste to take dead zone reviews issue to ml
[23:11] <barry> he did this
[23:11] <barry> jtv was at our meeting and i think we've decided on mp + cover + an irc cue
[23:12] <barry> basically jtv and stub would add a cue to the, er queue to let ocrs know that thye have branches they'd like reviewed
[23:12] <barry> or something like that.  i don't remember the details, but i'll write it up when i go through the minutes
[23:13] <thumper> I've also cleaned up the claiming a team review
[23:13] <thumper> so we should have less pending team review
[23:13] <thumper> s
[23:13] <thumper> when someone has done one
[23:13] <mwhudson> i guess in time, jtv and stub will end up reviewing each other's branches a lot
[23:13] <barry> yep, stubs a mentat now
[23:13] <jml> thumper: the remaining issue is that it's still hard to see which branches need review.
[23:13] <thumper> action for me: make sure a default reviewer is added through bzr send if none specified
[23:13]  * thumper thinks
[23:14] <thumper> if we have a bug for this
[23:14] <barry> thumper: yes please.  and btw, i used bzr send for the first time yesterday. awesome sauce
[23:14] <thumper> increase its priority
[23:14] <jml> thumper: partly because the mp status isn't always updated.
[23:14] <thumper> barry: just wait for the changes with jml is reviewing
[23:14] <thumper> jml: I've got some ideas
[23:14] <thumper> lets make the views better
[23:15] <jml> thumper: partly because there aren't clear mp statuses for "reviewed, waiting on reply"
[23:15]  * barry *can't* wait :)
[23:15] <thumper> jml: lets make one
[23:15] <thumper> jml: we use a decorated class now anyway
[23:15] <jml> thumper: let's talk about it after :)
[23:15] <thumper> jml: let's just invent a new status column
[23:15]  * thumper nods
[23:15] <barry> sounds good.  thanks guys
[23:16] <barry>  * gary to email list about RENormalizing test, investigate alternate inline spellings
[23:16] <barry> he did this
[23:16] <barry> doctest is hard to extend
[23:16] <barry> 'nuff said
[23:16]  * jml coughs politely
[23:16]  * mwhudson is tempted to say "two wrongs don't make a right"
[23:16] <barry> :)
[23:17] <barry> both flacoste and i suck at our two action items so i won't even mention them
[23:17] <mwhudson> if you can't specify this close-to-inline, it's a terrible terrible idea
[23:17] <jml> barry: you probably should :)
[23:17] <mwhudson> otherwise, it's just terrible, perhaps
[23:17] <barry>  * barry to add `pretty()` functions to reviewers docs
[23:17] <barry>  * flacoste to work on API reviewer cheat sheet
[23:18] <jml> these are both good ideas.
[23:18] <barry> mwhudson: we all agree on that!
[23:18] <mwhudson> good
[23:18] <barry> jml: yep, we should suck less and do more
[23:18] <barry> anyway, that's about it for my list.  do you guys have anything y'all want to talk about?
[23:19] <thumper> I'm working my way through the code-review bugs
[23:19] <thumper> if people have a strong opinion about something
[23:20] <thumper> they should contact me directly
[23:20] <jml> barry: I have a couple of things
[23:20] <thumper> otherwise they'll be fixed in thumper-priority
[23:20] <mwhudson> i guess i could say the same about loggerhead/codebrowse
[23:20] <barry> thumper: isn't that thumpertime?
[23:20] <barry> thumper: thanks
[23:20] <barry> jml: go ahead
[23:20] <thumper> barry: something like that :)
[23:20] <jml> first, the reviewer checklist
[23:21] <jml> 1. it's getting kind of long
[23:21] <jml> 2, it's hard to find
[23:21] <jml> the first one is a someday/maybe thing
[23:22] <jml> i.e. it doesn't matter too much, but it would be nice if it were shorter and more usable
[23:22] <jml> but I actually don't know where to find the latest version :)
[23:22] <barry> agreed, agreed. it's on My List to garden it and move it to dev.lp.net
[23:22] <jml> cool.
[23:22] <jml> second, mentoring
[23:23] <jml> I'm mentoring stub, and I don't feel I'm doing a particularly good job of it.
[23:23] <barry> jml: because of the tz?
[23:23] <jml> barry: partly
[23:23] <jml> barry: in more than one way, actually. there's not a huge deal of overlap, for a start.
[23:24] <jml> barry: but also my OCR day is busiest in the morning, as people from the Americas submit things on their Thursday evening.
[23:24] <barry> jml: and you overlap with stub in the morning?
[23:25] <jml> my afternoon.
[23:25] <thumper> stub's morning
[23:25] <barry> jml: i can chat with flacoste and/or stub if you want to see if we can line someone else up
[23:26] <jml> also, are there any docs on mentoring on the wiki?
[23:26] <barry> jml: some i think, but probably not much
[23:26] <jml> barry: that might be a good idea. let's leave it for another week though & see how it goes.
[23:26] <mwhudson> overlapping in the mentees morning isn't really the right end of things, i guess
[23:26] <barry> jml: sounds good
[23:27] <jml> that's it from me.
[23:27] <barry> that tz is just a challenge all around unfortunately
[23:27] <barry> cool, thanks jml.  anything else guys?
[23:27] <thumper> nope
[23:28] <mwhudson> nope
[23:28] <barry> guess we're done!
[23:28] <barry> #endmeeting
[23:28] <MootBot> Meeting finished at 17:28.
[23:28] <thumper> yay
[23:28] <mwhudson> thanks bazza
[23:28] <barry> thanks.  btw, i really like this meeting time
[23:28] <jml> barry: ya :)
[23:28] <jml> me too.
[23:28] <barry> great! see y'all back at the ranch