[03:00] #startmeeting [03:00] Meeting started at 21:00. The chair is barry. [03:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [03:00] hello everyone and welcome to this week's asiapac reviewer's meeting. who's here today? [03:00] here [03:00] hi [03:00] I am here. [03:00] and I bet mwhudson is too [03:01] hello [03:01] hi guys [03:02] apologies for being a little disorganized today. i moved and my isp screwed me over ;) [03:02] [TOPIC] agenda [03:02] New Topic: agenda [03:02] * Roll call [03:02] * What support can beuno and mrevell offer during the review process? (mrevell) [03:02] * Email cover letter to ml after pre-imp call? - barry [03:02] * If there's time, the old boring script [03:02] * Next meeting [03:02] * Action items [03:02] * Queue status [03:02] * Mentoring update [03:02] [TOPIC] * What support can beuno and mrevell offer during the review process? (mrevell) [03:02] New Topic: * What support can beuno and mrevell offer during the review process? (mrevell) [03:03] so, at the ameu meeting we talked about beuno and mrevell helping w/preimps and reviews [03:03] beuno mostly about ui stuff and mrevell about help, etc [03:03] they're also invited to the reviewer meetings and we can use them in m-p's [03:04] i would say, particularly for beuno that review is too late [03:04] right. [03:04] agreed [03:04] whereas, I think that for doc changes, reviews are at about the right time [03:04] mwhudson: yes, agreed, though i wonder if he should be a reviewer for all ui changes [03:05] that would be interesting [03:05] though he /should/ be involved earlier, maybe he /must/ be involved at review time? [03:05] jml: indeed [03:05] if he can keep up with the load, I think that would be a good idea [03:05] barry: i'd worry that he'd become a bottleneck [03:05] but maybe it's worth a try [03:05] it'll still add review latency problems [03:05] which will discourage trivial UI patches. [03:06] although, even if it's a post-merge review it'll probably help [03:06] right. i just think with all the redesign going on, we need someone to make sure things are consistent [03:07] the big danger to watch out for is ending up with another situation like db patches. [03:07] i know review latency is a big problem for you guys [03:07] jml: yes, great point [03:08] jml: though it'll be different because it wouldn't be on such a limited clock tick [03:08] this is why I think post-merge UI reviews are worth considering [03:08] yes, that's perhaps a good idea [03:08] jml: ui pre-imps & post-merge reviews? [03:09] yes, although that brings me to my next thought :) [03:09] which is that nominally, we share few core hours with Martin. [03:09] that said, 2/3 of us rarely do UI work anyway. [03:09] yeah, that does suck [03:10] and martin is an insane insomniac [03:10] * barry had him and sinzui at his house all last week :) [03:11] ok. i'll powwow with martin and see if he has some ideas, suggestions, preferences [03:11] sounds sane [03:11] cool [03:12] please do let me know if you have more ideas here. i don't want to impose any more bottlenecks, just looking forward a bit to handling big ui changes [03:12] [TOPIC] * Email cover letter to ml after pre-imp call? - barry [03:12] New Topic: * Email cover letter to ml after pre-imp call? - barry [03:13] does anyone actually read the review list any more? [03:13] i haven't been able to keep up for months [03:13] I don't [03:13] too busy [03:13] mwhudson: i'm thinking of sending it to the launchpad list. bad idea? [03:13] I think that'll make the launchpad list even more unfollowable [03:14] anyway [03:14] barry: what's the thinking behind the idea? [03:14] barry: what [03:14] right, what jml said [03:14] is the intent to make people do more pre-impls? [03:15] thumper: partly that yes. also so people have a better idea about what is going on and to spur wider discussion -- when people care [03:15] you'd probably ignore most of it, but something might catch your eye [03:16] better to do so early on than in the review process [03:16] i'm trying to write my covers right up front [03:16] if people could give useful subject lines it might help more [03:16] hmm. [03:16] so I don't have to read the messages [03:16] barry: I wonder if this is the right tool to solve the problem. [03:17] jml: maybe not [03:17] barry: my cover letters often say what I'm solving, what approach I'm taking and why. But they also discuss details of the implementation that simply aren't there pre-impl [03:17] barry: my guess is that if I did cover letters up front, I'd still need something like a cover letter sent on review. [03:18] jml: yes. i start the cover when i start the branch. it helps crystallize my thinking. i add pre-imp call notes, then implementation details as i'm working on it, so by the time i'm done, it's an accurate (hopefully helpful) detailed explanation of what i've done [03:19] barry: so, another thing we could try is this: [03:19] when you start working on something, set the bug to "in progress", and put an interesting comment in. [03:20] or, dare I say it, a work in progress merge proposal [03:20] thumper: ? [03:20] thumper: I've got a bug filed saying that there should be a stronger association between the two :P [03:21] jml: between bugs and m-ps? [03:21] barry: specifically between bug/branch links and m-ps [03:21] barry: but bugs and m-ps would follow, I hope. [03:21] jml: that will be awesome [03:21] barry: the bug is pretty vague :) [03:22] :) [03:22] barry: that said, I do think that using the bug / blueprint tracker for this is the right way to go. [03:22] barry: as individuals, we have a finer level of control over what bugs we find interesting. [03:23] jml: yes. for me, it all starts at the bug/blueprint [03:23] plus we have the advantage of making that decision whenever we wish, rather than when an email appears in our inbox. [03:23] right [03:24] cool. [03:24] that's all i have on this topic. obviously my thoughts aren't fully baked [03:25] one more topic not on the agenda [03:25] * jml needs to configure flashing red lights to go off when bug 173633 gets started. [03:25] Launchpad bug 173633 in launchpad-bazaar "Listing of branches per-user per-project" [Medium,Triaged] https://launchpad.net/bugs/173633 [03:25] [TOPIC] mapping m-p states with lp review process [03:25] New Topic: mapping m-p states with lp review process [03:25] or something like that [03:25] we had a discussion at ameu about how to map our current lp review states onto m-p states [03:26] which I didn't fully agree with [03:26] there was a vigorous discussion about it! [03:26] I didn't follow that discussion. [03:26] so just to summarize... [03:26] we had strong but not unanimous agreement that... [03:26] needs-reply == needs-fixing [03:26] +1 [03:27] merge-approved == approve [03:27] +1 [03:27] merge-conditional == approve + comment [03:27] +1 [03:27] and most people don't like resubmit :) [03:27] * thumper maybe does agree [03:27] we shouldn't have resubmit [03:27] because we talk to each other [03:27] or at least, we as lp developers should never get a resubmit [03:27] right. pre-impl calls basically make it unnecessary. [03:27] right [03:27] though we might when/if we start taking floss contributions [03:28] we don't develop in a vacuum [03:28] barry: agreed [03:28] thumper: speak for yourself! [03:28] jml: there's no air in oz? [03:28] thumper: I find hacking in a vacuum reduces the pressure. [03:28] jml: well, that is certainly true [03:28] jml: and you often get shit done [03:28] barry: only the best air on earth! [03:29] * jml was making a terrible pun, actually [03:29] :-D [03:29] so, sounds like you guys like the ameu decision? [03:29] yeah. [03:29] yep [03:29] yes [03:30] cool [03:30] well, that's it for me. anything on your minds? [03:30] just vegie curry [03:30] the absence of lunch :) [03:31] you eat, i'll sleep [03:31] see you next week! [03:31] #endmeeting [03:31] Meeting finished at 21:31. [03:31] see ya :) [03:31] thanks guys [03:31] barry: thanks === danilo-afk is now known as danilos === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell === bac` is now known as bac === thumper_laptop is now known as thumper === bac is now known as bac_afk === bac_afk is now known as bac