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