=== mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [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:00] me [15:00] me [15:00] me [15:00] me [15:01] gary_poster danilos bigjools allenap jml BjornT ping [15:02] hi [15:02] me, sorry [15:02] me [15:02] [TOPIC] agenda [15:02] * bigjools stabs Google calendar [15:02] New Topic: agenda [15:02] * Roll call [15:02] * Action items [15:02] * UI review call update [15:02] * Careful with those drive-bys, they make reviewing unnecessarily harder [intellectronica] [15:02] * How can we better incorporate drive-bys and other tech debt payoff into our development process? [barry] [15:02] * Noodles and I (Edwin) discovered that we were using different guidelines for what goes into the view.label property. [15:02] barry, in a sprint, won't be joining you (as will nobody from translations team), sorry [15:02] * My method reduces the amount of redundancy between the

and the breadcrumbs directly below it. For example: [15:02] || '''Define upstream link''' <
> Ubuntu >> 9.04 >> “mozilla-firefox” source package >> Define upstream link || [15:02] * Noodle's method could have better google foo, since it puts more relevant info in the
. For example: [15:02] || '''Define upstream link for mozilla-firefox in Ubuntu Jaunty''' <
> Ubuntu >> 9.04 >> “mozilla-firefox” source package >> Define upstream link || [15:02] * Peanut gallery (anything not on the agenda) [15:02] [15:02] [15:02] danilos: cool, thanks [15:02] me [15:02] [TOPIC] action items [15:02] New Topic: action items [15:03] +1 on barries method of view.label definition :) [15:03] uhm, "barry's" :) [15:03] * danilos goes back to sprinting [15:03] barry, hi [15:03] as long as it's not berries :) [15:03] jml: hi! [15:03] me [15:03] * gary_poster and barry will transfer review guidelines from the old wiki and old old wiki to the new wiki [15:03] we still suck [15:04] oh we do! It had been so long that I had forgotten I suck! [15:04] gary_poster: maybe we should admit defeat [15:04] lol [15:04] barry: we almost had Matt doing it [15:04] barry: we just needed to tell him...something [15:04] barry: I tried to do it but no longer had access for some reason [15:04] gary_poster: right! i'll ping him on it and see if he can help out [15:04] barry: cool [15:05] [TOPIC] * UI review call update [15:05] New Topic: * UI review call update [15:05] action: barry to get matt to do the work he and gary were going to do ;-) [15:05] :) [15:05] i wonder if beuno is around? [15:05] intellectronica: can you give a quick summary of the meeting? [15:05] sure [15:05] two interesting items: [15:06] 1. martin will start working with one or two ui reviewers towards graduating them [15:06] as part of the process they will hopefully start collecting documentation of complete reviews [15:07] 2. there's some concern about the timing of the upgrade to the latest version of YUI3 [15:07] ideally, we'd like to have that before the next LAZR-JS sprint, so that whatever we do there builds on the new codebase, but it's unclear whether that's realistic given the resources we have for that time [15:08] Does everyone know that beuno is writing the Web UI guidelines for all Canonical. He is using Launchpad as the basis, but when finalised, we may need to make changes. [15:08] indeed [15:08] finally, now that some ui reviewers will graduate, reviewers are welcome to join as mentees. talk to martin if you're interested [15:09] hi beuno ! intellectronica gave a good summary of the meeting. do you have an eta for ui reviewer graduations? [15:09] intellectronica: regarding 2. [15:09] gary scheduled that for this cycle when Maris comes back [15:09] with help from salgado [15:09] awesome! [15:10] so we should have lazr-js updated by the sprint [15:10] I've talked to Gary about upgrading YUI3 before the sprint [15:10] also, Bjorn is finishing the buildout migration to lazr-js [15:10] yes [15:10] which will allow us to upgrade lazr-js to YUI3 without affecting LP [15:10] yeah those are the key bits. [15:11] Then the sprint would be able to work on migrating Launchpad itself to YUI 3 and the new lazr-js [15:11] (in part) [15:11] gary_poster, beuno can we also spend time on making it easier to add js to launchpad? it's still a very painful process :/ [15:12] gary_poster: in the ui call, we discussed how that might not be the best use of sprint time [15:12] barry, we will have 7 people from other teams, we need to make it easier [15:12] maybe this is the wrong meeting for dicussing this stuff, though [15:12] beuno: great. i really think this is critical for our success here [15:12] intellectronica: true. [15:13] intellectronica: yeah maybe so :-) but ok, then we migrate Launchpad after the sprint [15:13] :) [15:13] so. intellectronica, beuno anything else re: the ui meeting this week? [15:13] I will be working with noodles775 [15:13] barry, beuno, that's a discussion to have with BjornT also I suspect. [15:13] to graduate him, so please send UI reviews his and my way these next 2 weeks [15:13] gary_poster: good pint [15:13] intellectronica, beuno: I heard something about a new requirement to report ui work? [15:14] report? [15:14] report? [15:14] report? (just helping out) [15:14] rockstar said something about us having to report when we were doing ui work. [15:14] report to whom, and in what format? [15:14] intellectronica: Report at a new meeting, IIRC. [15:14] I asked rockstar what your team was up to, that's all [15:15] i've never heard of this before [15:15] beuno, intellectronica: maybe I got it wrong. I'll ask him. [15:15] ah ok, yes. in general we like to have a status round in those meetings so it's good if the team's representative knows the status of ui work for the week [15:16] intellectronica, beuno thanks. let's move on... [15:16] barry, did you get that about noodles775? [15:17] beuno: noodles775 is going to graduate, right? [15:17] beuno: or has he already graduated? [15:17] will start the process :) [15:17] noodles775: fantastic [15:17] barry, I'm going to work with him these next 2 weeks, so please throw as many UI reviews at him as you can, and add me as well :) [15:17] [AGREED] send your ui reviews to noodles775 and beuno so noodles775 can get graduated [15:17] (within reason) [15:17] AGREED received: send your ui reviews to noodles775 and beuno so noodles775 can get graduated [15:18] [TOPIC] drive-byes [15:18] New Topic: drive-byes [15:18] * Careful with those drive-bys, they make reviewing unnecessarily harder [intellectronica] [15:18] * How can we better incorporate drive-bys and other tech debt payoff into our development process? [barry] [15:18] [15:18] intellectronica: do you want to start? [15:18] sure [15:19] so, traditionally, we've encouraged people to do drive-by cleanups when working on unrelated branches [15:19] but in reviews, i find that these cleanups actually make the review much less focused [15:20] from a review pov, it would actually be much better if there were no unrelated cleanups in a branch [15:20] so there's a trade-off here, and i wonder how to best get the right balanace [15:21] intellectronica: it's a great point. i'm guilty of that. and yet, how do we encourage more cleanups and tech debt payoff? [15:21] what do people think about trying an experiment? [15:21] intellectronica: IME, bzr has the opposite problem, because it wants to avoid spurious changes. [15:21] that's on the assumption that drive-by cleanups are in general a good thing. that's also something we should maybe re-examine [15:21] I favor landing drvie-bys in a first branch [15:21] where we rs pure drive-by branches? [15:21] abentley: yes, i think avoiding spurious change is actually a desirable [15:22] There's a silly but real issue: [15:22] barry: so, we used to have that policy, and i think it got shot down for fear of abuse [15:22] I usually set my editors to remove trailing whitespace [15:22] intellectronica: but was that fear warranted? [15:22] I usually like this [15:22] using pipeline or loom makes it easy to do drive-bys in a separate branch, then land the drive-by and the real branch at the same time. [15:22] And I usually don't notice this [15:22] Because it is automatic [15:23] And happens when I do work on something else [15:23] gary_poster: i think that's acceptable exception [15:23] cool [15:23] gary_poster: i think that's the real issue for me. drive-byes are exactly that. you're working on something and you see something you could easily clean up right then and there. looms/pipelines help, but not completely [15:24] abentley: so do you submit a drive-by diff after your main review? [15:24] barry: but is that really a good thing to do? it is of course great to improve the codebase in general, but from the perspective of the branch you're working on, is the unrelated change really an improvement? [15:24] bac: In this hypothetical, you'd submit them both at the same time, and then land the last pipe / top thread. [15:25] bac: after both had been approved. [15:25] I think pipelines will make it easier for me to do the non-whitespace cleanups [15:25] intellectronica: that's a great point, however i think if you don't jfdi then, it'll almost never happen. maybe it's okay it never happens, but it seems like a wasted opportunity [15:26] easier to do separately, I mean [15:26] barry: honestly, i am undecided about that, but i surprised myself by thinking that there's at all a dilemma. maybe drive-bys aren't such an important thing after all [15:27] intellectronica: i'm not quite willing to go that far yet :) [15:27] in a way, drive-bys are unscheduled work which you're doing at the (marginal) expense of more important work [15:28] (the team lead meeting did celebrate the idea of "slack": time spent on tech debt both opportunistically and scheduled) [15:28] intellectronica: If you look at it that way, it's easy to build up technical debt. [15:29] abentley: exactly, because such low priority issues are never scheduled [15:29] abentley: au contraire. it forces you to schedule technical debt payments [15:29] intellectronica: but in practice...? [15:29] barry: how about always having a clean up-to-date branch. when see something that needs fixing, do the fix in the clean branch, get a quick review (showing a diff to the reviewer is enough), and merge it right-away? [15:29] intellectronica: Perhaps we don't really disagree-- I thought you were saying that debt reduction was less important than other work. [15:29] pink.bikeshed.com [15:30] barry: that's way i always do, except that i generally create the new branch from scratch, since it's quick to do so. [15:30] BjornT: yes, i think that's a good way to do it [15:30] BjornT: hmm. sort of always having a tech debt branch laying around when you're working on the real bug. clean things ujup there instead of your real branch? [15:31] bigjools: we don't have to discuss tech debt and so on in detail. what i'd like is to get out of this meeting with a recommendation that people don't do unrelated drive-bys in the same branch [15:31] barry: yeah. you probably don't even to have that branch laying around, you can create it when you need it. [15:32] intellectronica: I think common sense should mostly prevail and if it's a simple one-liner then do it, otherwise leave it for a separate branch. [15:32] BjornT: i have stupid reasons why that might not work as well for me, but i'm going to think about it, and especially wrt to pipelines/looms [15:33] barry: i think the key here is that the review should be quick; the reviewers should give priority to drive-by diffs maybe. [15:33] bigjools: true. but i've seen branches that are a third drive-by [15:33] intellectronica: i'm okay with that if we still find ways to encourage cleanups and other tech debt payments. BjornT's idea, schedule slack, might hep [15:33] I often shelve the unwanted changes and unshelve in a new branch. [15:34] sinzui: You mean "bzr shelve; bzr switch; bzr unshelve" ? [15:34] barry: we could, like BjornT suggested, prioritize these reviews higher, or offer to review two branches one after the other if the developer went out of his way to do some cleanup work in another branch [15:34] barry: another thing i do frequently is to do the fix in the branch i'm working on, but then i merge that commit into a seperate branch, which i submit for review while working on completing the first branch [15:35] intellectronica, BjornT i think those are both great ideas [15:35] abently no, I am idiot. That sounds like what I want to do. I have been moving the shelve to the new branch [15:35] intellectronica: why don't you and i spend some time outside this meeting to formulate some guidelines and perhaps run an experiment? [15:36] barry: works for me [15:36] [ACTION] intellectronica and barry to formulate guidelines/run an experiment for improving drive-by/tech debt payment [15:36] ACTION received: intellectronica and barry to formulate guidelines/run an experiment for improving drive-by/tech debt payment [15:36] [TOPIC] * Noodles and I (Edwin) discovered that we were using different guidelines for what goes into the view.label property. [15:36] [15:36] New Topic: * Noodles and I (Edwin) discovered that we were using different guidelines for what goes into the view.label property. [15:37] barry: I sent an email out a few hours ago to lp-dev... so far it looks like the low-redundancy version that Edwin used is favoured :) [15:37] noodles775, EdwinGrubbs the floor is yours [15:37] barry: This is a chance for you to formalise you trivial experiment [15:37] noodles775: i way behind on my email today :( [15:37] sinzui: +1 :) [15:37] and danilos, the second option actually originated from a review of I did of translations pages (for jtv I think). I don't remember the page in the review, but here's an example: [15:37] https://translations.edge.launchpad.net/~danilo/+imports [15:37] With the first option the h1 would be 'Import queue'. [15:38] So barry, it might be worth discussing next week anyway (and end this meeting more quickly) ;) [15:38] The main question is whether information is duplicated in the
and the breadcrumbs, since the
should give us better google juice. [15:38] next week is fine [15:38] noodles775: sounds good! [15:38] [TOPIC] peanut gallery [15:38] New Topic: peanut gallery [15:39] noodles775, I still think it's nicer, +imports pages are a special case because they live on many contexts (product, distro, distroseries, person, sourcepackage), so it's hard to get them right [15:39] we have 7 minutes left. does anybody have anything not on the agenda? [15:39] anyway, left for next week when I hope I can participate, sorry for interruptions :) [15:39] 5 [15:40] 4 [15:40] 3 [15:40] 2 [15:40] 1 [15:40] #endmeeting [15:40] Meeting finished at 09:40. [15:40] thanks everyone! [15:40] Thanks barry. [15:40] thank you barry [15:40] Thanks barry! === gary_poster is now known as gary-phone === EdwinGrubbs is now known as Edwin-afk === gary-phone is now known as gary_poster [21:33] #startmeeting [21:33] Meeting started at 15:33. The chair is barry. [21:33] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [21:34] hi [21:34] ni! [21:34] hi! [21:34] welcome to our new earlier time [21:34] i guess i'll start with a review of ameu [21:35] * barry will ask mrevell for help in converting the old wiki guidelines to the new dev wiki [21:35] * beuno will work with noodles to get him ui graduated. for the next 2 weeks, please send most of your ui reviews to them [21:35] * talk to beuno if you're interested in becoming a ui mentat [21:35] * intellectronica and barry will work out some guidelines for drive-by and tech debt payoff branches (contemporaneous drive-byes considered harmful) [21:35] (and we had some strategies to look at for improving drive-bys and tech debt) [21:35] that's it. is there anything you'd like to talk about? [21:37] rockstar, mwhudson ? [21:37] i think the last bullet could use expansion [21:37] "contemporaneous drive-byes considered harmful" [21:37] ? [21:38] mwhudson: so, intellectronica pointed out how distracting drive-bys can be when reviewing a branch. i think he observed one branch where 1/3 of the code change was tech debt. hard to pick out the important stuff [21:38] oh right yes [21:38] intellectronica even questioned whether drive-bys and the value they bring are worth the effort [21:39] i think they still are, so it's finding the right way to do them [21:39] some ideas: [21:39] * use bzr looms/pipelines to segregate the cleanups [21:39] i think the cost of drive-bys to a review depends on how "easy" the review is [21:39] * use some of the schedule slack to do pure tech debt branches [21:39] (etc.) [21:39] if it's a simple change to code you and the coder know well, it's no big deal [21:40] mwhudson: i usually don't mind them [21:41] i guess my goal is to make it even easier than it is now to clean up our code [21:42] how can we do that while not making reviewer lives hell? [21:43] mwhudson, rockstar any other thoughts for today? [21:43] barry, not from me. [21:44] mwhudson: ? [21:44] oops, got taken away sorry [21:44] nothing more from me [21:45] barry: apart from [21:45] cool. [21:45] ... [21:45] i totally support effort to keep a clean code base [21:45] it's worth a lot, possibly more than one realises [21:45] . [21:45] mwhudson: i completely agree! thanks [21:45] #endmeeting [21:45] Meeting finished at 15:45.