= 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=der...@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=and...@ubuntu/member/beeseek.developer.andrea-bs has
quit [Remote closed the connection]
10:00:47 -!-
abentley!n=abent...@cpe001a7046c8f9-cm001e6b233d5a.cpe.net.cable.rogers.com 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=quas...@canonical/launchpad/bigjools stabs Google
calendar
10:02:12 < MootBot: New Topic: agenda
10:02:13 -!- [email protected] 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=dan...@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=be...@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=be...@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 -!- [email protected] 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
}}}
signature.asc
Description: PGP signature
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
