=== mwhudson__ is now known as mwhudson [03:00] #startmeeting [03:00] hello everyone and welcome to this week's asiapac reviewer's meeting [03:00] who's here today? [03:00] Oh, hi. [03:00] I'm here :) [03:00] me? [03:01] spiv: hi! :) [03:01] jml is in Prague I guess? [03:01] thumper: ? [03:01] mwhudson: ? [03:01] (good thing I was idling in here!) [03:01] * thumper smacks forehead [03:01] spiv: that's okay. i haven't eaten dinner yet :) [03:01] completely forgot, sorry [03:01] I'm hip deep in pqm [03:01] (the source that is) [03:01] ouch [03:02] we can make it a quick one then [03:02] well, if we ignore for the moment that the patch will be approx 3k lines [03:02] == Agenda == [03:02] * Roll call [03:02] * Next meeting [03:02] * Action items [03:02] * Queue status [03:02] * Mentoring update [03:02] it will make it better [03:02] * Review process [03:02] * Help people learn how big branches can be split up (BjornT) [03:02] * Final vote multiline import [03:02] it being a us holiday next week, i will not be here. shall we just skip it and convene back in 2 weeks? [03:02] barry: I'm guessing that mwhudson is afk too [03:02] thumper: gotcha [03:03] barry: sure, I don't mind skipping [03:03] barry: expecially as it is a week 4 [03:03] thumper: yep [03:03] * Action items [03:03] * barry drive to decision about multiline sequences [03:03] i think we're close to a decision here, but i'l say more in a few minutes [03:04] * barry to solicit ideas to better handle review scheduling and workload [03:04] not done [03:04] * (continued) thumper to report on pending-reviews killer in LP [03:04] not done either [03:04] thumper: shall we keep this on the agenda or ditch it? [03:04] barry: ditch for now I think [03:05] we have things coming up [03:05] thumper: sounds good [03:05] but it doesn't really help saying skip it each week [03:05] thumper: all post 2.0 right? [03:05] yeah [03:05] works for me [03:05] +1 [03:05] * Queue status [03:06] * thumper hasn't looked at the queue in ages [03:06] nothing much from me here. i got through a bunch of branches today, and assigned the 3 i couldn't get to [03:06] doesn't look too bad right now but i wouldn't want to be sinzui on friday :) [03:06] And Saturday [03:07] sinzui: only because you like it :) [03:07] No Soccer this weekend [03:07] sinzui: promise me you will not work on the holiday! :) [03:08] Work on what? [03:08] it's national bbq day [03:08] * sinzui starts the heater on the pool [03:08] * barry is going to skip the mentoring update [03:08] sinzui: very nice! [03:08] * Review process [03:09] * Help people learn how big branches can be split up (BjornT) [03:09] don't talk to me about that right now [03:09] at ameu , bjorn brought up a discussion on how to get people to learn how to split their big branches [03:09] I have a real killer [03:09] thumper: your branch? [03:09] yeah, me for lifeless [03:09] oh man, i _always_ forget this meeting [03:10] barry: a sharp whack across the knuckles with a big ruler every time a branch goes over the limit? ;) [03:10] spiv: it is a pqm refactoring branch [03:10] spiv: that's one idea! [03:10] spiv: most of it is just moving stuff to modules [03:10] i had a big branch, but mostly because i added some upstream files [03:11] would you believe I got __init__.py down to just having __version__ in it? [03:11] but in general, all the branches i saw today were < 800 lines [03:11] so i don't know how common this is [03:11] i'm not really aware of it being a problem [03:11] I think we need a wiki page to collect ideas, then circulate a email of the top 5-10 tips after two weeks [03:11] So there's two possible issues I guess. [03:11] I don't think it is a big problem right now [03:11] what i'd say is that if you notice the same offenders over and over again, we should work with those people to get them to learn how to organize their work better [03:11] +1 [03:11] i think 800 lines is a low enough limit that it can be slightly exceeded without causing much pain [03:12] mwhudson: agreed [03:12] One is that maybe people are doing to much work, rather than sending things incrementally (i.e. "send-as-you-go") [03:12] The other is that maybe when a big branch happens (which can be hard to avoid), people don't know how to split them up. [03:12] spiv: it was brought up that looms can be a useful tool for organizing a complex branch into reviewable chunks [03:12] I'm not sure which of these two Bjorn is referring to? [03:12] it requires a certain discipline to go 'oh crap to do X i need Y and then i need Z' and then put each thing in it's own branch [03:12] (maybe both?) [03:13] spiv: i get the sense that it's a lot of the latter. how to help people learn how to split it up [03:13] Ok. [03:13] but otoh, most of the branches i've been reviewing have been fine [03:13] spiv: I believe I'm now seeing a pattern of multiple branches being submitted on the same day. bug branches are being split instead of being driven to the right solution through review. [03:14] This is something that the broader bzr user community would benefit from education about. [03:14] sinzui: i'm not sure i understand [03:14] s/bug branches/but branches/ [03:14] i'm going to ask BjornT to start a discussion on the ml about this [03:15] There's a fairly straightforward process you can go through with looms + bzr shelve. [03:15] sinzui: at least in an ideal world, the correct solution should be determined around the time of the pre-imp call [03:15] not the review [03:15] Which has occasionally been described on #bzr and maybe on the mailinig list. [03:15] spiv: is there anything written up about this way of working? it's definitely something i do [03:15] (the bazaar@ mailing list) [03:15] But I don't think it's been written up properly. [03:15] mwhudson: yes, we want to push the organization earlier in the process [03:15] So perhaps the thing to do is write a good, clear tutorial on it, and put it in the loom plugin docs? [03:16] mwhudson: I think 1800 line branches are being written, then split. The view is in a precarious position because there may be drastic changes to the model and utils below it. not to mention that mpt my have grievous things to say about the UI. [03:16] And use the launchpad team as guinea pigs for that doc :) [03:16] sinzui: ah, i see [03:16] spiv: +1. if you want to drive it/start it, i will certainly chip in [03:17] I don't have time for that at the moment. [03:17] well, this is all about the 'ready to code' mantra i guess [03:17] I'd be happy to proof read. [03:17] [ACTION] barry to write something up about working effectively with looms+shelve [03:17] mwhudson: agreed [03:18] barry: thanks! [03:18] i gotta run, so i'm going to (try to) make this last item short: [03:18] * Final vote multiline import [03:18] did you all see mars's suggestion? [03:18] remind me? [03:19] instead of: from canonical.launchpad.interfaces import ([800 lines later) [03:19] do: from canonical.launchpad.interfaces.bugs import (many fewer things) [03:19] and eradicate (over time) all import-*'s in __init__.pys [03:19] and do not do one-line-per-import [03:19] thoughts? [03:20] I'm +0 on that, I think. [03:20] i don't think this will please the people who think one-line-per-import will take too much space, will it? [03:20] but yeah, import-* sucks, even when used carefully [03:20] There's a risk that module renaming/interface moving will then cause merge-time conflicts. [03:20] yes, import-* sucks for many reasons [03:21] spiv: we won't actually move anything, we'll just do a more-specific import [03:21] Evil though import * is, it does make the actual layout of canonical.launchpad.interfaces.* etc a blackbox to other packages. [03:21] barry: I think spiv means if we do move something [03:21] which should reduce big parenthesed import statements, thus reducing conflicts [03:21] barry: right, but when something moves [03:21] yeah, i see what you mean [03:21] import-* destroys the convenience of namespaces. [03:21] this seems to be a bit [03:22] I'm not sure it's a significant problem. [03:22] If we always import *, we get php at some point [03:22] But it does make me hesitate a little. [03:22] me neither. i don't know how often interfaces move around [03:22] 'import statements attract conflicts' -> 'but one-line imports are too verbose' -> 'lets do something else that doesn't really solve either problem' [03:22] ish [03:22] unless it does :) [03:22] Yeah, my gut feeling is with mwhudson, that this is a largely orthogonal issue. [03:23] but then i don't really have a problem with conflicts in import statements _or_ large amounts of imports at the top of files [03:23] i think it will reduce conflicts on import lines, which iiuc is the primary motivation for moving to one-line-per-import [03:23] so maybe i should just shut up and hope people stop bothering me by talking about it :) [03:23] :-D [03:24] ok, well i didn't hear howls of objections, so i'l take that as "let's try it and see" [03:24] i just want to get this f'n item off my list ;) [03:24] that's all i have today. anything else from y'all? [03:25] nop3 [03:25] e [03:25] barry: my vote on any specific proposal is +0, but my meta-vote is +1 for barry just declaring how it will be. :) [03:25] ditto [03:25] barry for president! [03:25] * mwhudson waits for the s/!=/<>/ branch of doom [03:26] mwhudson: well, I might be -0 on *that* specific one ;) [03:26] * barry is just waiting until the psf f's up the trademark and then it's off to the fork he goes! [03:26] anyway. thanks everybody. see you in 2 weeks! [03:26] #endmeeting [03:26] bye barry [03:26] hm, python.org seems down [03:27] mwhudson: there's always python.com [03:27] oh no [03:27] probably my internet being crap again === mpt_ is now known as mpt === salgado-afk is now known as salgado === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [17:01] Hello! Is anyone here for the Launchpad documentation meeting? === salgado is now known as salgado-lunch === salgado-lunch is now known as salgado === gumpa_hiding is now known as gumpa === salgado is now known as salgado-afk