launchpad-dev team mailing list archive

[Barry Warsaw <barry@xxxxxxxxxxxxx>]

= ReviewerMeeting20091007 =

== summary ==

 * barry will ask mrevell for help in converting the old wiki guidelines to the new dev wiki
 * beuno will work with noodles to get him ui graduated.   for the next 2 weeks, please send most of your ui reviews to them
 * talk to beuno if you're interested in becoming a ui mentat
 * intellectronica and barry will work out some guidelines for drive-by and tech debt payoff branches (contemporaneous drive-byes considered harmful)
   * bzr looms/pipelines
   * schedule slack
   * trivial branch experiment
   * rs branches?

== logs ==

=== ameu ===

{{{
10:00:15 > barry: #startmeeting
10:00:16 < MootBot: Meeting started at 09:00. The chair is barry.
10:00:16 < MootBot: Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
10:00:27 -!- deryck!n=deryck@samba/team/deryck has joined #launchpad-meeting
10:00:29 > barry: hello everyone and welcome to this week's ameu reviewer's meeting.  who's here today?
10:00:31 < sinzui: me
10:00:31 < EdwinGrubbs: me
10:00:37 < intellectronica: me
10:00:44 < flacoste: me
10:00:46 -!- andrea-bs!n=andrea@ubuntu/member/beeseek.developer.andrea-bs has quit [Remote closed the connection]
10:00:47 -!- abentley!n=abentley@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx has joined #launchpad-meeting
10:00:56 < bac: me
10:00:59 < deryck: me
10:01:00 < noodles775: me
10:01:58 > barry: gary_poster danilos bigjools allenap jml BjornT ping
10:02:07 < bigjools: hi
10:02:09 < allenap: me, sorry
10:02:09 < gary_poster: me
10:02:11 > barry: [TOPIC] agenda
10:02:12 < * bigjools!n=quassel@canonical/launchpad/bigjools stabs Google calendar
10:02:12 < MootBot: New Topic:  agenda
10:02:13 -!- jamalta!n=jamalta@209.20.66.76 has joined #launchpad-meeting
10:02:20 > barry:  * Roll call
10:02:20 > barry:  * Action items
10:02:20 > barry:  * UI review call update
10:02:20 > barry:  * Careful with those drive-bys, they make reviewing unnecessarily harder [intellectronica]
10:02:23 > barry:    * How can we better incorporate drive-bys and other tech debt payoff into our development process? [barry]
10:02:26 > barry:  * Noodles and I (Edwin) discovered that we were using different guidelines for what goes into the view.label property.
10:02:26 < danilos: barry, in a sprint, won't be joining you (as will nobody from translations team), sorry
10:02:30 > barry:    * My method reduces the amount of redundancy between the <h1> and the breadcrumbs directly below it. For example:
10:02:33 > barry:      || '''Define upstream link''' <<BR>> Ubuntu >> 9.04 >> “mozilla-firefox” source package >> Define upstream link ||
10:02:37 > barry:    * Noodle's method could have better google foo, since it puts more relevant info in the <h1>. For example:
10:02:40 > barry:      || '''Define upstream link for mozilla-firefox in Ubuntu Jaunty''' <<BR>> Ubuntu >> 9.04 >> “mozilla-firefox” source package >> Define upstream link ||
10:02:43 > barry:  * Peanut gallery (anything not on the agenda)
10:02:46 > barry:  
10:02:47 > barry:  
10:02:53 > barry: danilos: cool, thanks
10:02:55 < abentley: me
10:02:57 > barry: [TOPIC] action items
10:02:58 < MootBot: New Topic:  action items
10:03:02 < danilos: +1 on barries method of view.label definition :)
10:03:09 < danilos: uhm, "barry's" :)
10:03:17 < * danilos!n=danilo@canonical/launchpad/danilos goes back to sprinting
10:03:22 < jml: barry, hi
10:03:23 > barry: as long as it's not berries :)
10:03:26 > barry: jml: hi!
10:03:27 < BjornT: me
10:03:31 > barry:  * gary_poster and barry will transfer review guidelines from the old wiki and old old wiki to the new wiki
10:03:37 > barry: we still suck
10:04:01 < gary_poster: oh we do!  It had been so long that I had forgotten I suck!
10:04:10 > barry: gary_poster: maybe we should admit defeat
10:04:15 < gary_poster: lol
10:04:28 < gary_poster: barry: we almost had Matt doing it
10:04:38 < gary_poster: barry: we just needed to tell him...something
10:04:50 < gary_poster: barry: I tried to do it but no longer had access for some reason
10:04:52 > barry: gary_poster: right!  i'll ping him on it and see if he can help out
10:04:58 < gary_poster: barry: cool
10:05:11 > barry: [TOPIC]  * UI review call update
10:05:12 < MootBot: New Topic:   * UI review call update
10:05:12 < gary_poster: action: barry to get matt to do the work he and gary were going to do ;-)
10:05:18 > barry: :)
10:05:23 > barry: i wonder if beuno is around?
10:05:42 > barry: intellectronica: can you give a quick summary of the meeting?
10:05:47 < intellectronica: sure
10:05:59 < intellectronica: two interesting items:
10:06:20 < intellectronica: 1. martin will start working with one or two ui reviewers towards graduating them
10:06:47 < intellectronica: as part of the process they will hopefully start collecting documentation of complete reviews
10:07:13 < intellectronica: 2. there's some concern about the timing of the upgrade to the latest version of YUI3
10:07:55 < intellectronica: 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
10:08:09 < sinzui: 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.
10:08:26 < intellectronica: indeed
10:08:55 < intellectronica: finally, now that some ui reviewers will graduate, reviewers are welcome to join as mentees. talk to martin if you're interested
10:09:06 -!- beuno!n=beuno@canonical/launchpad/beuno has joined #launchpad-meeting
10:09:32 > barry: hi beuno !  intellectronica gave a good summary of the meeting.  do you have an eta for ui reviewer graduations?
10:09:33 < flacoste: intellectronica: regarding 2.
10:09:49 < flacoste: gary scheduled that for this cycle when Maris comes back
10:09:55 < flacoste: with help from salgado
10:09:58 < intellectronica: awesome!
10:10:03 < flacoste: so we should have lazr-js updated by the sprint
10:10:11 < beuno: I've talked to Gary about upgrading YUI3 before the sprint
10:10:14 < flacoste: also, Bjorn is finishing the buildout migration to lazr-js
10:10:20 < gary_poster: yes
10:10:25 < flacoste: which will allow us to upgrade lazr-js to YUI3 without affecting LP
10:10:46 < gary_poster: yeah those are the key bits.
10:11:05 < gary_poster: Then the sprint would be able to work on migrating Launchpad itself to YUI 3 and the new lazr-js
10:11:10 < gary_poster: (in part)
10:11:52 > barry: gary_poster, beuno can we also spend time on making it easier to add js to launchpad?  it's still a very painful process :/
10:12:01 < intellectronica: gary_poster: in the ui call, we discussed how that might not be the best use of sprint time
10:12:17 < beuno: barry, we will have 7 people from other teams, we *need* to make it easier
10:12:18 < intellectronica: maybe this is the wrong meeting for dicussing this stuff, though
10:12:50 > barry: beuno: great.  i really think this is critical for our success here
10:12:59 > barry: intellectronica: true.
10:13:01 < gary_poster: intellectronica: yeah maybe so :-) but ok, then we migrate Launchpad after the sprint
10:13:14 < intellectronica: :)
10:13:19 > barry: so.  intellectronica, beuno anything else re: the ui meeting this week?
10:13:28 < beuno: I will be working with noodles775
10:13:30 < gary_poster: barry, beuno, that's a discussion to have with BjornT also I suspect.
10:13:43 < beuno: to graduate him, so please send UI reviews his and my way these next 2 weeks
10:13:43 > barry: gary_poster: good pint
10:13:50 < abentley: intellectronica, beuno: I heard something about a new requirement to report ui work?
10:14:08 < intellectronica: report?
10:14:14 < beuno: report?
10:14:28 < gary_poster: report?  (just helping out)
10:14:30 < abentley: rockstar said something about us having to report when we were doing ui work.
10:14:38 < intellectronica: report to whom, and in what format?
10:14:50 < abentley: intellectronica: Report at a new meeting, IIRC.
10:14:56 < beuno: I asked rockstar what your team was up to, that's all
10:15:00 < intellectronica: i've never heard of this before
10:15:43 < abentley: beuno, intellectronica: maybe I got it wrong.  I'll ask him.
10:15:57 < intellectronica: 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
10:16:48 > barry: intellectronica, beuno thanks.  let's move on...
10:16:58 < beuno: barry, did you get that about noodles775?
10:17:11 > barry: beuno: noodles775 is going to graduate, right?
10:17:20 > barry: beuno: or has he already graduated?
10:17:23 < noodles775: will start the process :)
10:17:31 > barry: noodles775: fantastic
10:17:44 < beuno: 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  :)
10:17:51 > barry: [AGREED] send your ui reviews to noodles775 and beuno so noodles775 can get graduated
10:17:52 < beuno: (within reason)
10:17:52 < MootBot: AGREED received:  send your ui reviews to noodles775 and beuno so noodles775 can get graduated
10:18:16 > barry: [TOPIC] drive-byes
10:18:17 < MootBot: New Topic:  drive-byes
10:18:35 > barry:  * Careful with those drive-bys, they make reviewing unnecessarily harder [intellectronica]
10:18:35 > barry:    * How can we better incorporate drive-bys and other tech debt payoff into our development process? [barry]
10:18:35 > barry:  
10:18:45 > barry: intellectronica: do you want to start?
10:18:51 < intellectronica: sure
10:19:13 < intellectronica: so, traditionally, we've encouraged people to do drive-by cleanups when working on unrelated branches
10:19:45 < intellectronica: but in reviews, i find that these cleanups actually make the review much less focused
10:20:14 < intellectronica: from a review pov, it would actually be much better if there were no unrelated cleanups in a branch
10:20:37 < intellectronica: so there's a trade-off here, and i wonder how to best get the right balanace
10:21:10 > barry: intellectronica: it's a great point.  i'm guilty of that.  and yet, how do we encourage more cleanups and tech debt payoff?
10:21:20 > barry: what do people think about trying an experiment?
10:21:22 < abentley: intellectronica: IME, bzr has the opposite problem, because it wants to avoid spurious changes.
10:21:30 < intellectronica: that's on the assumption that drive-by cleanups are in general a good thing. that's also something we should maybe re-examine
10:21:32 < sinzui: I favor landing drvie-bys in a first branch
10:21:47 > barry: where we rs pure drive-by branches?
10:21:50 < intellectronica: abentley: yes, i think avoiding spurious change is actually a desirable
10:22:10 < gary_poster: There's a silly but real issue:
10:22:17 < intellectronica: barry: so, we used to have that policy, and i think it got shot down for fear of abuse
10:22:30 < gary_poster: I usually set my editors to remove trailing whitespace
10:22:32 > barry: intellectronica: but was that fear warranted?
10:22:34 < gary_poster: I usually like this
10:22:36 < abentley: 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.
10:22:48 < gary_poster: And I usually don't notice this
10:22:53 < gary_poster: Because it is automatic
10:23:04 < gary_poster: And happens when I do work on something else
10:23:25 < intellectronica: gary_poster: i think that's acceptable exception
10:23:30 < gary_poster: cool
10:23:50 > barry: 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
10:24:01 < bac: abentley: so do you submit a drive-by diff after your main review?
10:24:46 < intellectronica: 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?
10:24:50 < abentley: bac: In this hypothetical, you'd submit them both at the same time, and then land the last pipe / top thread.
10:25:02 < abentley: bac: after both had been approved.
10:25:29 < gary_poster: I think pipelines will make it easier for me to do the non-whitespace cleanups
10:25:41 > barry: 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
10:26:04 < gary_poster: easier to do separately, I mean
10:26:43 < intellectronica: 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
10:27:27 > barry: intellectronica: i'm not quite willing to go that far yet :)
10:27:43 < intellectronica: in a way, drive-bys are unscheduled work which you're doing at the (marginal) expense of more important work
10:28:29 < gary_poster: (the team lead meeting did celebrate the idea of "slack": time spent on tech debt both opportunistically and scheduled)
10:28:33 < abentley: intellectronica: If you look at it that way, it's easy to build up technical debt.
10:29:00 > barry: abentley: exactly, because such low priority issues are never scheduled
10:29:03 < intellectronica: abentley: au contraire. it forces you to schedule technical debt payments
10:29:26 > barry: intellectronica: but in practice...?
10:29:50 < BjornT: 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?
10:29:53 < abentley: intellectronica: Perhaps we don't really disagree-- I thought you were saying that debt reduction was less important than other work.
10:29:55 < bigjools: pink.bikeshed.com
10:30:16 < BjornT: barry: that's way i always do, except that i generally create the new branch from scratch, since it's quick to do so.
10:30:45 < intellectronica: BjornT: yes, i think that's a good way to do it
10:30:52 > barry: 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?
10:31:35 < intellectronica: 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
10:31:41 < BjornT: barry: yeah. you probably don't even to have that branch laying around, you can create it when you need it.
10:32:24 < bigjools: 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.
10:32:34 > barry: 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
10:33:18 < BjornT: barry: i think the key here is that the review should be quick; the reviewers should give priority to drive-by diffs maybe.
10:33:20 < intellectronica: bigjools: true. but i've seen branches that are a third drive-by
10:33:31 > barry: 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
10:33:32 < sinzui: I often shelve the unwanted changes and unshelve in a new branch.
10:33:36 -!- beuno!n=beuno@canonical/launchpad/beuno has left #launchpad-meeting []
10:34:33 < abentley: sinzui: You mean "bzr shelve; bzr switch; bzr unshelve" ?
10:34:39 < intellectronica: 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
10:34:56 < BjornT: 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
10:35:20 > barry: intellectronica, BjornT i think those are both great ideas
10:35:27 < sinzui: abently no, I am idiot. That sounds like what I want to do. I have been moving the shelve to the new branch
10:35:48 -!- al-maisan!n=al-maisa@xxxxxxxxxxxxxxxxxxxxxxxxxxx has joined #launchpad-meeting
10:35:59 > barry: intellectronica: why don't you and i spend some time outside this meeting to formulate some guidelines and perhaps run an experiment?
10:36:10 < intellectronica: barry: works for me
10:36:42 > barry: [ACTION] intellectronica and barry to formulate guidelines/run an experiment for improving drive-by/tech debt payment
10:36:43 < MootBot: ACTION received:  intellectronica and barry to formulate guidelines/run an experiment for improving drive-by/tech debt payment
10:36:56 > barry: [TOPIC] * Noodles and I (Edwin) discovered that we were using different guidelines for what goes into the view.label property.
10:36:56 > barry:  
10:36:57 < MootBot: New Topic:  * Noodles and I (Edwin) discovered that we were using different guidelines for what goes into the view.label property.
10:37:06 < noodles775: 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 :)
10:37:09 > barry: noodles775, EdwinGrubbs the floor is yours
10:37:19 < sinzui: barry: This is a chance for you to formalise you trivial experiment
10:37:28 > barry: noodles775: i way behind on my email today :(
10:37:36 > barry: sinzui: +1 :)
10:37:40 < noodles775: 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:
10:37:40 < noodles775: https://translations.edge.launchpad.net/~danilo/+imports
10:37:40 < noodles775: With the first option the h1 would be 'Import queue'.
10:38:24 < noodles775: So barry, it might be worth discussing next week anyway (and end this meeting more quickly) ;)
10:38:27 < EdwinGrubbs: The main question is whether information is duplicated in the <h1> and the breadcrumbs, since the <h1> should give us better google juice.
10:38:42 < EdwinGrubbs: next week is fine
10:38:48 > barry: noodles775: sounds good!
10:38:52 > barry: [TOPIC] peanut gallery
10:38:54 < MootBot: New Topic:  peanut gallery
10:39:04 < danilos: 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
10:39:06 > barry: we have 7 minutes left.  does anybody have anything not on the agenda?
10:39:22 < danilos: anyway, left for next week when I hope I can participate, sorry for interruptions :)
10:39:59 > barry: 5
10:40:02 > barry: 4
10:40:05 > barry: 3
10:40:09 > barry: 2
10:40:11 > barry: 1
10:40:14 > barry: #endmeeting
}}}

=== asiapac ===

{{{
16:33:54 > barry: #startmeeting
16:33:55 < MootBot: Meeting started at 15:33. The chair is barry.
16:33:55 < MootBot: Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
16:34:02 < mwhudson: hi
16:34:05 < rockstar: ni!
16:34:10 > barry: hi!
16:34:17 > barry: welcome to our new earlier time
16:34:50 > barry: i guess i'll start with a review of ameu
16:35:00 > barry:  * barry will ask mrevell for help in converting the old wiki guidelines to the new dev wiki
16:35:09 > barry:  * beuno will work with noodles to get him ui graduated.   for the next 2 weeks, please send most of your ui reviews to them
16:35:16 > barry:  * talk to beuno if you're interested in becoming a ui mentat
16:35:22 > barry:  * intellectronica and barry will work out some guidelines for drive-by and tech debt payoff branches (contemporaneous drive-byes considered harmful)
16:35:40 > barry: (and we had some strategies to look at for improving drive-bys and tech debt)
16:35:50 > barry: that's it. is there anything you'd like to talk about?
16:37:16 > barry: rockstar, mwhudson ?
16:37:27 < mwhudson: i think the last bullet could use expansion
16:37:34 < mwhudson: "contemporaneous drive-byes considered harmful"
16:37:35 < mwhudson: ?
16:38:18 > barry: 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
16:38:28 < mwhudson: oh right yes
16:38:48 > barry: intellectronica even questioned whether drive-bys and the value they bring are worth the effort
16:39:11 > barry: i think they still are, so it's finding the right way to do them
16:39:15 > barry: some ideas:
16:39:28 > barry: * use bzr looms/pipelines to segregate the cleanups
16:39:42 < mwhudson: i think the cost of drive-bys to a review depends on how "easy" the review is
16:39:44 > barry: * use some of the schedule slack to do pure tech debt branches
16:39:54 > barry: (etc.)
16:39:55 < mwhudson: if it's a simple change to code you and the coder know well, it's no big deal
16:40:12 > barry: mwhudson: i usually don't mind them
16:41:50 > barry: i guess my goal is to make it even easier than it is now to clean up our code
16:42:01 > barry: how can we do that while not making reviewer lives hell?
16:43:30 > barry: mwhudson, rockstar any other thoughts for today?
16:43:39 < rockstar: barry, not from me.
16:44:29 > barry: mwhudson: ?
16:44:50 < mwhudson: oops, got taken away sorry
16:44:56 < mwhudson: nothing more from me
16:45:07 < mwhudson: barry: apart from
16:45:07 > barry: cool.  
16:45:13 > barry: ...
16:45:21 < mwhudson: i totally support effort to keep a clean code base
16:45:29 < mwhudson: it's worth a lot, possibly more than one realises
16:45:32 < mwhudson: .
16:45:39 > barry: mwhudson: i completely agree!  thanks
16:45:40 > barry: #endmeeting
}}}

Attachment: signature.asc
Description: PGP signature