BUSY DRAFTING

This is the Launchpad Users Team Meeting, started on 18 August 2007, 16H00 - 17H00 (Etc/GMT).

Attendance

• barry
• Hobbsee
• statik
• kiko
• bac
• jtv
• Kmos

Agenda

• Roll call
• Next meeting
• Queue status.

Minutes

• Roll Call
  • Done
• Next Meeting
  • The next meeting will held "same time and place" - 16H00-17H00, IRC @ #ubuntu-launchpad, date: TBA
• Queue Status
  • bac reported the queue is on 22 red and 8 not.
  • statik noted that he has two in his queue of which both will be done today (15/08/2007) and he'll be able to take more from 16/08/2007, but he has mentioned that he'll be on leave Friday, 17/08/2007.
  • barry noted "looks like 6 in conflict in the needs-review section"

  • barry enquired if anybody think they /won't/ be able to get to all their reviews in the next day or two? bac & kiko confirmed that it will be done, reviewed ad possibly reviewed.

  • barry noted that carlos's branch will be worked on later. barry will focus on things that can make the cut off time for now. kiko agreed.
• Huge Branches
  • How do we go about working with huge branches?

    • kiko noted: "i'll send him my review so far and let's get him to split this branch up and resubmit for 1.1.9" ACTION : kiko to forward review to carlos.

    • kiko noted further that to stop any further delays, barry should complete the branch for now. In future this type of thing will not be tolerated. ACTION: barry to complete carlos's branch.

    • kiko noted that a limit of a 1000 lines per patch should be considered in future to counter huge patches/branches. Deleted/removals and sample data must be counted in this line count.

    • ACTION : barry to send a message to the launchpad list describing the new policy.

• Notes to reviewers
  • Get a message across to reviewers that does not belong in the code.
    • Example: "I'll file a bug for thix XXX when you approve the branch (doesn't make sense before then)"

      • kiko noted that XXX: REVIEWER would be fine

      • ACTION : jtv to communicate the above to the launchpad list.

• Graduations and new reviewers
  • barry noted that there are two graduates (bac and statik) that are ready for graduation.

  • New recruits. ACTION : barry to send an email to launchpad-reviews asking for nominations.

Any Other Business

• None

IRC Logs

04:06   barry   kiko: hah!  zee power it eez all mine!
04:07   barry   statik, kiko, bac: okay thanks for coming.  see you next week
04:07   barry   oh wait
04:07   Hobbsee statik: for changelogs, use dch -D RELEASENAME, iirc
04:07   statik  Hobbsee: thanks! that sounds promising
04:08   barry   == Agenda ==   * Roll call  * Next meeting  * Queue status.
04:08   barry   heh
04:08   kiko    that was the roll call!
04:08   Hobbsee statik: i believe you can also upload to ubuntu/targetrelease, in dput.cf (i think thatwas covered in a LP thread).
04:08   barry   do we expect anybody else?
04:08   Hobbsee apologies for disrupting the meeting, as i didnt read and action the backscroll quick enough!
04:09   barry   no?  okay, moving on
04:09   kiko    barry, not salgado or jtv I suspect
04:09   bac     barry: i think most of the world seems to be off celebrating one thing or another today
04:09   bac     has jtv been recruited?
04:09   jtv     oh, hi
04:10   barry   bac: not officially afaik, though we should talk about that in a moment
04:10   barry   okay, next meeting.  same time and place?
04:10   kiko    fine by me, I'm not on vacation then.
04:10   statik  +1
04:10   barry   done.
04:11   barry   * Queue status
04:11   bac     i just counted:  22 red, 8 not red
04:11   statik  I have 2 in my queue now which will go out today, I can take one more for tomorrow but will be on vacation on friday
04:12   barry   looks like 6 over the limit in the needs-review section
04:12   kiko    I have like a million
04:12   kiko    but I am reviewing them right now
04:12   kiko    so I will be finished in 4h
04:12   barry   oops, not over the limit. in conflict
04:12   kiko    SOMEBODY gave me two huge patches
04:12   barry   kiko: yeah, let's talk about that in a minute
04:13   kiko    okay.
04:13   barry   does anybody think they /won't/ be able to get to all their reviews in the next day or two?
04:13   kiko    I'll be able.
04:13   bac     i will
04:13   kiko    barry, but really, they should be done by today.
04:14   kiko    tomorrow and friday are already too late
04:14   statik  i'll be able to
04:14   bac     kiko: do you mean reviewed and approved today or just through the initial review?
04:15   kiko    bac, the latter, though we're trying hard for the former
04:15   barry   kiko: well, then i wonder if it's even worth me completing carlos's branch.  it's huge.  i've spent 4.5 hours on it already and i'm about 20% done.  and he's not available today so he won't even respond on it until tomorrow.  i think that makes it impossible to get into 1.1.8 and i should concentrate on things that /do/ have a possibility of making it in
04:15   kiko    barry, I agree. if it had been done yesterday we'd have been in better shape.
04:15   Kmos    how about to enable for launchpad beta testers ?
04:15   Kmos    we can start checking for bugs :)
04:15   kiko    jtv, I am really crazy mad about this massive branch. carlos knows better.
04:16   jtv     At least he split up the next big one...
04:16   barry   kiko: okay, let's move on to the items then.  huge branches
04:16   kiko    barry, what I meant was that if you had managed to finish reviewing yesterday it'd have been a bit better.
04:17   barry   kiko: yeah, but i couldn't spend 20 hours on it yesterday
04:17   kiko    jtv, no excuses for carlos, he's been with us long enough to know he's not meant to do that. be sure it /never/ happens again as I'm at the limit of my patience on this sort of thing
04:17   jtv     aye-aye, sir
04:17   kiko    it's just plain lack of discipline and IT DRIVES ME CRAZY
04:17   barry   kiko: agreed
04:17   kiko    okay.
04:17   kiko    so huge branches
04:18   kiko    we should have a bonfire at allhands and burn people who post branches above 1000 lines.
04:18   kiko    any other ideas?
04:18   barry   kiko, jtv: i'm going to punt this back to carlos then.  i'll send him my review so far and let's get him to split this branch up and resubmit for 1.1.9
04:18   kiko    maybe a symbolic burning?
04:18   kiko    barry, I think splitting the branch up is going to make the problem worse
04:18   barry   kiko: :(
04:18   kiko    barry, so I think that a) it should miss 1.1.8 and b) you should finish reviewing it by early next week so he lands it early
04:18   kiko    barry, sorry, but mitigation at this point is going to be better
04:19   barry   kiko: sounds good.
04:19   kiko    sending carlos back to the drawing board is going to delay things even further. I'm sorry you have to run the pain of doing it but as we said it's the last time
04:19   barry   yep, np
04:19   jtv     Food for tomorrow's Translations meeting.
04:20   kiko    more seriously, we should have a hard limit of 1000 lines per patch
04:20   barry   it will take a few back-and-forths to get it into shape, so i have no problem seeing it through, but i will give higher priority to things that can actually make it into 1.1.8
04:20   kiko    if it goes over that, you need to a) talk to a reviewer ahead of time and make sure there is time reserved for you
04:20   kiko    or b) go back to the drawing board
04:20   kiko    and c) not plan on landing it on week 3
04:21   kiko    barry, agreed
04:21   statik  kiko: if by hard limit you mean not enforced automatically, then I'm on board with that. I wouldn't want PQM rejecting patches based on line counts because of things like sampledata that shouldn't really count against a branch
04:21   barry   kiko: in principle i agree (obviously).  but is 1k lines enough?  (he says with a 1500 line patch in the queue)
04:21   barry   statik: yes, i agree.  also removed lines shouldn't count against
04:22   kiko    barry, I think that any limit is arbitrary, but that there's a conway's law for patch sizes
04:22   bac     1000 is a good target.  can the counter be changed to not count deletions?
04:23   kiko    statik, I say hard limit in that reviewers will reject as soon as they see the mess that they are being invited into.
04:23   kiko    not any sort of automatic process
04:23   barry   i'd agree on 1k lines if we don't count removals and stuff like sampledata.  that's difficult to capture automatically tho
04:23   kiko    bac, it's a rule-of-thumb thing, so I would prefer it be a simple measure
04:23   statik  I'm definitely on board then
04:23   kiko    so it needs to be the number that is displayed here:
04:23   kiko    https://devpad.canonical.com/~jamesh/pending-reviews/
04:23   jtv     grep -c ^+?
04:24   kiko    that way the reviewer can scan the list and say WTF
04:24   kiko    and you can convince jamesh to change the way counts are done there to get what you want
04:24   kiko    but it needs to be a number that you can decide upon at a glance
04:24   barry   kiko: yes.  and if a reviewer rejects a 1k+ line diff automatically, the author can say "but 800 of them are deletions!".  i.e. there's some back and forth negotiations and it doesn't need to be automatic
04:24   kiko    barry, sure, that's fine.
04:25   barry   +1 from me then
04:25   kiko    deletions are tricky though
04:25   kiko    because you need to actually read them to make sure he's not doing something crazy like deleting tests
04:25   kiko    so it's not as cheap as you're led to believe
04:25   barry   kiko: yes, definitely agreed
04:25   bac     i notice jtv's patch under the wire at 998.  good job.
04:25   jtv     phew
04:25   barry   it's like the price is right for diffs
04:26   jtv     kiko: didn't you ask me to merge that 998-line diff with a related branch?
04:26   barry   i'm fine with getting some push back from authors if they think the 1k+ charge isn't fair
04:26   kiko    jtv, well, the problem there is that the changes were all related and I wanted to get a general overview there. but maybe I was wrong in asking that, in hindsight
04:27   barry   kiko: can you send a message to the launchpad list describing the new policy?
04:27   kiko    barry, how about you do that? :)
04:27   barry   kiko: will do
04:28   kiko    thanks
04:28   barry   okay, anything else to get off y'all's chests about huge branches?
04:28   barry   5
04:28   barry   4
04:28   barry   3
04:28   barry   2
04:28   barry   1
04:28   barry   moving on.  jtv: notes to reviewers.  you're up
04:29   jtv     Says it all, really.  Sometimes I need to get a message across to reviewers that does not belong in the code.
04:29   jtv     Examples:
04:29   jtv     A message saying "I'll file a bug for thix XXX when you approve the branch (doesn't make sense before then)"
04:30   kiko    jtv, it's okay to leave an XXX in the code with no bug number and expect the reviewer to sign off on it.
04:30   jtv     Or "This code flatly denied the comment above it, but the change repairs that.  No comment needed, but the diff may look weird."
04:30   barry   kiko: or give a TBD for the bug id in the XXX
04:30   kiko    barry, right.
04:31   kiko    jtv, I don't see an easy way of doing that beyond having per-branch comments which would not scale well to the wikipage approach we currently have.
04:31   bac     i don't understand why the bug can't be filed?
04:31   jtv     Do we have a convention for TBDs?
04:31   kiko    not really
04:31   jtv     bac: in my example, it didn't make sense to file a bug for something that was still in an unreviewed branch.
04:31   kiko    but anything that the reviewer wouldn't be confused with would be fine
04:31   barry   bac: i think jtv is saying that during the review process, the XXX bug might go away so it makes no sense to file it before the branch is approved
04:32   kiko    bac, what if the bug is actually not warranted? what if the XXX is a hunch? I think this is what jtv is driving towards
04:32   jtv     Could be, just no telling at that stage.
04:32   bac     ok
04:32   barry   jtv: i've always used XXX itself as a hint to the reviewer
04:32   jtv     What I had in mind was not advanced: just writing something similar to XXX in the code
04:32   barry   jtv: though i'd be okay with XXX REVIEWER: hey lookie here
04:32   kiko    do that
04:32   kiko    that'd be fine.
04:32   jtv     SteveA pointed out to me today that XXX might not be appropriate here
04:33   bac     jtv: and it is meant to disappear before submitting?
04:33   jtv     Exactly
04:33   kiko    look
04:33   kiko    I use XXXs for this
04:33   barry   jtv: it's a temporary XXX but we're so trained to spot those things that it's more of a marker that something needs attention, either during review or some time down the road
04:33   barry   kiko: yes, exactly
04:34   jtv     I also suggested the "XXX: REVIEWER" thing, but...
04:34   kiko    XXX: I am not sure about this. the problem is that getBranchesByName() can return a tuple in this specific situation and I am unsure of whether it's best to fix the callsite or the API.
04:34   kiko    etc
04:34   kiko    and the reviewer can look at that
04:34   kiko    XXX: REVIEWER would be fine
04:34   barry   kiko: agreed
04:34   jtv     Add to XXXPolicy?
04:34   bac     i'd think some of those questions might be better addressed in a call
04:35   kiko    sure
04:35   barry   yep
04:35   barry   jtv: yes, please do so.  feel free to communicate that to the launchpad list too
04:35   jtv     ok
04:35   barry   thanks
04:35   barry   anything else?
04:35   barry   5
04:35   barry   4
04:35   barry   3
04:35   barry   2
04:35   barry   1
04:36   barry   okay, last item, which isn't on the agenda...
04:36   barry   graduations and new reviewers
04:36   barry   so we have at least two graduations pending that i know of.  kiko give me the okay and i will send out an official graduation notice
04:37   statik  ooh, official notices
04:37   barry   i think it's important to do that
04:37   barry   are there any other mentored reviewers that are ready for graduation?
04:38   bac     i don't think there are any other mentored reviewers period
04:38   statik  I think bac and I were the only two left, and once we graduated we were going to set up a new batch
04:38   barry   bac: maybe not ;)
04:39   barry   as for new recruits, i will send an email to launchpad-reviews asking for nominations.  then next week we can go over them and decide who to invite.  any objections?
04:39   statik  sounds good to me
04:39   bac     i'm all for more reviewers.  it's a good time in the cycle, too
04:40   barry   bac: agreed!
04:40   barry   okie dokie.  unless kiko wakes up and disagrees, i'll do both these later today.
04:40   barry   :)
04:41   barry   5 minutes left.  is there anything else not on the agenda?
04:41   statik  I've got nothing

LaunchPad