=== salgado-afk is now known as salgado === bac-afk is now known as bac === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell === allenap_ is now known as allenap [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] welcome everyone to our first post-epic reviewers meeting. who's here today? [15:00] me [15:00] me [15:00] me [15:00] me [15:01] me [15:01] me [15:01] me [15:02] me [15:02] me [15:02] [TOPIC] agenda [15:02] New Topic: agenda [15:02] * Roll call [15:02] * Watch out for queries in intermediate tables. -- salgado [15:02] * Using merge proposals again -- barry [15:02] * If there's time, the old boring script [15:02] * Next meeting [15:02] * Action items [15:02] * Queue status [15:03] * Mentoring update [15:03] [TOPIC] * Watch out for queries in intermediate tables. -- salgado [15:03] New Topic: * Watch out for queries in intermediate tables. -- salgado [15:03] me! [15:03] :) [15:03] salgado: the floor is yours [15:03] already!? [15:04] Reviewers should watch out for queries on intermediate tables (e.g. AnswerContact), in which the only purpose is to get something which the intermediate tables link too (e.g. the people who are answer contacts). The query should either be on the table from where we want the results (e.g. Person) or at least it should bring in the rows from the linked table too, to make sure they don't need to be retrieved individually later. [15:04] salgado: jfdi! [15:05] if there are no objections I'll update the docs [15:05] salgado: is this made easier by using native storm api? [15:05] salgado: maybe write to the list, and with an example? coders should know wbout it, not just reviewers [15:05] barry, not really, I think [15:05] intellectronica, good point [15:05] I could do with an example [15:06] there was a method on IQuestionTarget which looked like [15:06] I can provide a diff of how the answer_contacts property used to work [15:06] contacts = AnswerContact.select(context=foo) [15:06] return [contact.person for contact in contacts] [15:07] that will cause any ORM to hit the DB once for every AnswerContact in contacts [15:07] and can easily be avoided [15:08] does that make sense? [15:08] salgado: yes. i've seen that situation often [15:08] +1 for an example posted to the list [15:08] ok, I'll do that [15:09] me [15:09] barry, I'm done here, then [15:10] salgado: thanks [15:11] [TOPIC] * Using merge proposals again -- barry [15:11] New Topic: * Using merge proposals again -- barry [15:11] Yay! [15:11] so, i think merge proposals have come a long way and i propose to use them again (exclusively?) [15:11] any thoughts? [15:11] The new UI has been really nice to use. [15:12] ...but I have a vested interest in us using it. [15:12] I'm still struggling with diffs, but I wont let that get in the way of using Launchpad. [15:12] what about the lint report? [15:13] sinzui: yeah, diffs are a bit problematic for now [15:13] bigjools, if there's something to note in it, I think a comment would be appropriate. [15:13] i guess its more incumbent on the coder to make sure his branch is lint clean [15:13] rockstar: well right now, review-submit generates a lint report, which merge proposals can't do [15:13] I forgot to do one in a review using merge-prop earlier [15:14] we definitely (eventually) want r-s to integrate with merge proposals [15:14] bigjools, yes, but that's specific to our flow. Putting it in the actual flow would be overkill for most projects. [15:14] rockstar: right - so the solution is to make review-submit go through merge-props [15:14] how do merge-proposals integrate with mailing lists (if at all)? [15:14] i wouldn't want to use them exlusively. i think i'd like another test run before we commit to using them exlusively. [15:15] barry, abentley landed a branch to use bzr send, so we can leverage that. [15:15] rockstar: excellent [15:15] intellectronica, we can have the launchpad review list mailed when a branch gets submitted. [15:15] rockstar: can you or abentley send instructions on how to use that? [15:16] BjornT, being all in means we feel our own pain. Test runs mean that we just have to endure until the trial is over. [15:16] I don't think that's the right attitude to take. [15:16] rockstar: cool. in that case, we could require the submitter to reply to that email with a diff and lint report [15:17] intellectronica, which is entirely possible. [15:17] rockstar: that's true, but also, this is a critical point in our development process. if it get screwed _everything_ gets screwed [15:17] rockstar: a test run means that we make a list of blockers. if there are no blockers, we can continue using them. [15:17] rockstar: btw, are the merge proposals exposed via the api? [15:17] Well, I think if we approach this half hearted, it'll be a few more passes until me actually go all in. [15:18] BjornT, no api that I know of yet, but it now works with bzr send, which means that review-submit can be made to work. [15:18] rockstar: if the experiment works we can all agree to move to it exclusively [15:19] Alright, I'm okay with only bailing if there are no blockers. I don't foresee any though. [15:19] I favour the experiment [15:19] The process may be painful at first though. [15:19] i'm worried about ping ponging between processes though. it's confusing to people becuase they don't know what to use [15:20] rockstar: well, i guess my question actually was: do i have to use the web ui to use merge proposals? (not only submitting them, but change meta data and so on)? [15:20] BjornT, you also have the email interface, which is where I ALWAYS work. [15:21] If someone would like to pair with me and show me the process of exposing APIs, I'd be glad to get it done. [15:21] rockstar: i'm happy to help with that [15:22] intellectronica, great. I'll ping you when I'm done here. [15:22] i like going all in and only reverting if there are blockers. [15:22] +1 [15:23] i'd like to hear more about how to use the email interface [15:23] can we still have the mailing list be the place where all communication go? [15:23] i have 4 branches that will soon be reviewable so i'll guinea pig the process and update the wiki page as i go [15:23] BjornT: +1 please! [15:23] BjornT, we can have the mailing list subscribed to the branch so that it all gets captured there. [15:23] rockstar: can i ping you during the process if i have questions? [15:24] i'm thinking specifically of the case where i want to CC someone on the review and have him participate in the discussion [15:24] barry, yes sir. I've been using it to submit my cscvs branches to michael [15:24] BjornT, you can also subscribe them. [15:24] rockstar: via e-mail? [15:25] BjornT, ah no. Requires web interface. [15:25] BjornT: iwbni lp automatically saw the cc and tried to add them as a reviewer or something [15:26] rockstar: right. so that was why i wanted us to have the mailing list be the place where all communication goes, so that CC and so on worked as it should [15:26] i think that's a quite important feature that should be preserved [15:26] rockstar: can you set up the mailing list interface for lp branches? === salgado is now known as salgado-afk [15:26] BjornT, it'll just be a mirror of what's going on it the review. [15:26] barry, alright. I'll have to do some futzing with it. [15:27] rockstar: cool, let's work together to make that work. and once we're happy with it, we'll let people know [15:27] BjornT: does that sound okay? [15:28] barry, acknowledged. [15:28] barr, rockstar: i'd say that would be a blocker, but that's just me [15:28] (blocker for using exclusively, not for doing another test run) [15:28] I don't think there's any code that needs changing. Just configuring. [15:28] ...and thumper might have done it already. [15:29] rockstar: i do think there is code that need to be changed [15:29] BjornT, the mailing list thing? [15:29] BjornT: gotcha. so maybe not mandated (until there are no blockers) but strongly and forcefully encouraged :) [15:29] rockstar: well, to make CC work [15:30] CC won't work if you use the mailing list simply to capture the conversation [15:30] BjornT, ah yes. I'll look into it, but I don't see that as a blocker, just a high priority. [15:31] rockstar: maybe that's because you never CC anyone on your reviews? ;) [15:31] BjornT: do we have an open bug for that issue at least? [15:32] barry: i don't know [15:34] so let's do this, i'll work with rockstar to document and test the process using merge proposals and email. i'll then send a message pointing to the updated wiki page and strongly recommend people use m-p's for reviews [15:34] we'll submit any bugs for missing features [15:34] but we won't make it exclusive yet [15:34] how's that sound? [15:35] barry: how do we track the things that we think should be fixed before using them exclusively? [15:36] BjornT: through the bug tracker. i'm tempted to use critical for adoption blockers [15:36] barry: high please! [15:36] barry: i don't think critical should be misused for this. [15:37] yeah, i thought you might object :) [15:37] :-) [15:37] and there are enough high bugs for them to get lost [15:37] I'm tempted to also use critical. [15:37] a tag would be better [15:37] we should not mis-use critical [15:37] this is in no-way critical [15:37] tag is a good idea [15:37] or a wiki page [15:37] flacoste, well, yes, I understand this. [15:38] on the wiki page documenting the process, let's link the blockers to the bug [15:38] crital means the issue is being worked on 24 hours a day and will be CPed into production [15:38] * barry feels like a bug tracker should be able to capture this bit of information [15:38] barry: a tag in the bug tracker [15:38] flacoste: "blocker" then? [15:38] or adoption-blocker? [15:38] its more like launchpad-blocker [15:39] or launchpad-merge-prosopal-adoption-blocker [15:39] how about launchpad-adoption-blocker for a compromise? [15:39] gmb: +1 [15:39] +1 [15:39] Since it could apply to other adoption-blocking bugs from other apps. [15:40] gmb, please point out another app that is actively being worked on that needs to be adopted by the LP team? :) [15:40] we're running out of time, so i propose we move on. i'll extract the action items from the irclog [15:41] [TOPIC] * Next meeting [15:41] New Topic: * Next meeting [15:41] rockstar: Touche. But what if we're stopping *other* people from adopting (e.g., to pick a random project, Gnome)? [15:41] s/we're/a bug is/ [15:41] is 1500 utc okay with everyone? i suspect it will not be good for salgado [15:41] but earlier is probably not great for EdwinGrubbs [15:41] It's good for me. [15:42] Yea, we start pushing 7 AM for me if we go any earlier. [15:42] rockstar: yeah [15:43] 1500 utc it is then [15:43] we have 2 minutes left, any other quick items not on the agenda? [15:44] sounds like we're done. thanks everyone! [15:44] #endmeeting [15:44] Meeting finished at 09:44. [15:44] Thanks guys! [15:44] thanks barry === salgado-afk is now known as salgado [16:37] ubuntulog === bac is now known as bac_afk === salgado is now known as salgado-brb === salgado-brb is now known as salgado === mrevell is now known as mrevell-dinner === bac_afk is now known as bac === salgado is now known as salgado-afk === mrevell-dinner is now known as mrevell === mrevell_ is now known as mrevell