21:01:25 <ttx> #startmeeting
21:01:26 <openstack> Meeting started Tue Feb 22 21:01:25 2011 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:01:38 <ttx> Welcome to our weekly OpenStack team meeting...
21:01:42 <soren> o/
21:01:46 <ttx> Today's agenda:
21:01:50 <ttx> #link http://wiki.openstack.org/Meetings
21:01:55 <soren> Is it too late to add stuff to the agenda?
21:02:01 <ttx> soren: no
21:02:07 <soren> \o/
21:02:15 <ttx> if you do it reaalllly quick.
21:02:27 <ttx> #topic Actions from previous meeting
21:02:40 <ttx> * ttx and johnpur to ensure the stability goals are defined and properly tracked
21:02:54 <ttx> We started the discussion, and a few threads have spawned on the ML.
21:03:13 <ttx> As part of the "release status" topic in the meeting I'll track the number of new bugs (which reflects testing) and fixed bugs (which reflects stabilization effort).
21:03:45 <ttx> * ttx to create the diablo series: DONE
21:03:58 <ttx> * ttx to target bugs to 2011.1.1 and post proposed list of fixes for last-minute comments: DONE
21:04:02 <ttx> * POC to rule on point release policy for the different projects
21:04:18 <ttx> Any POC member available to comment ? Last time Ewan said you were waiting on some answers from the distributions side.
21:04:50 <soren> Uh..
21:06:19 <creiht> hrm
21:06:37 * creiht waits
21:06:38 <creiht> :)
21:08:53 <creiht> yay for netsplits :/
21:09:18 <soren> \œ/
21:09:18 <dendrobates> thanks annegentle
21:09:18 <soren> craptastic timing for a netsplit.
21:09:18 <annegentle> "# follow up with a unified release plan that takes into accounts division of upstream/downstream labor and support time frames (jbryce, 21:25:39)"
21:09:18 <ttx> annegentle: thanks !
21:09:19 * ttx likes to facilitate, though those are a bit of a testing pain.
21:09:19 <ttx> ok, moving on
21:09:19 <ttx> #topic Current release stage: Development
21:09:19 <ttx> We are almost at half-time for this cycle feature merge window.
21:09:19 <ttx> we lost the meetbot
21:09:30 <ttx> oh, no it catches up
21:09:38 <ttx> #info The next date is BranchMergeProposalFreeze, on March 17. You should have your feature branches proposed before that date.
21:09:51 <ttx> #topic Cactus Release status
21:09:58 <ttx> #link http://wiki.openstack.org/releasestatus/
21:10:15 <ttx> I'd like to make sure this reflects what you plan to work on for Cactus, so please take 2 minutes to check
21:10:29 <ttx> If your stuff is missing please ping dendrobates (nova), jaypipes (glance) or creiht (swift)
21:10:48 <ttx> Also if your stuff is listed but with an incorrect state (like it's marked "not started" while you started it), feel free to fix implementation status on the blueprint itself. See:
21:10:55 <ttx> #link http://wiki.openstack.org/BlueprintsLifecycle#Blueprints_Fields_reference
21:11:24 <ewanmellor> dendrobates: xenapi-basic-network-injection is ready for approval.  The branch is already subject to merge request too.
21:11:26 <ttx> dendrobates: I'd like to have priorities set on the remaining nova specs. Can you get to that soon ?
21:11:42 <dendrobates> yes, by tomorrow
21:11:52 <ttx> #action dendrobates to set priorities for last nova specs
21:12:06 <ttx> jaypipes: Could you set tentative assignees for the unassigned Glance specs ? You can always fix that later
21:12:11 <ttx> hm, no jaypipes
21:12:22 <ttx> #action jaypipes to set tentative assignees for Glance specs
21:12:31 <ttx> creiht: same for https://blueprints.launchpad.net/swift/+spec/cactus-checksum-get
21:12:58 <creiht> ttx: done
21:13:01 <ewanmellor> dendrobates: Also xenapi-vlan-network-manager is Pending Approval.
21:13:05 <ttx> cool.
21:13:28 <ttx> On the completion rate, based on the data I have:
21:13:40 <dendrobates> ewanmellor: I'm on it.
21:13:41 <ttx> #info Glance is 38% completed,  6% proposed, 13% in progress, 43% not started
21:13:53 <ttx> #info Nova   is  3% completed, 17% proposed, 54% in progress,  9% not started
21:13:56 <vishy> o/
21:14:02 <ttx> #info Swift  is  0% completed,  0% proposed, 25% in progress, 75% not started
21:14:15 <ttx> Nothing critical, but it's pretty obvious we need to land the already-proposed branches
21:14:19 <ewanmellor> dendrobates: Thanks!
21:14:28 <ttx> #info We have 23 merge proposals open on Nova, 2 on Glance and 4 on Swift.
21:14:42 <ttx> Hopefully the recent nova-core additions and the set up of daily reviewers will help in clearing the backlog.
21:14:51 <ttx> On the stabilization effort:
21:15:01 <ttx> #info 39 new bugs filed, 28 bugfixes merged over the last week
21:15:08 <ttx> That's quite impressive.
21:15:46 <ttx> Specail thanks to newcomers that help test, file and fix bugs
21:16:06 <ttx> Any question on the Cactus release status ?
21:16:51 <ttx> alrighty
21:16:52 <ttx> #topic Nova 2011.1.1 release status
21:17:12 <ttx> So we are now ready to land branches at https://code.launchpad.net/~hudson-openstack/nova/bexar/+activereviews -- please review and approve them, if possible today
21:17:23 <ttx> #action nova-core to review and approve proposals blocking 2011.1.1
21:17:44 <ttx> If that's done, I'll generate candidate tarballs and Ubuntu packages tomorrow, which we'll use to test that the targeted bugs have indeed been fixed, and that we didn't introduce regressions.
21:18:03 <ttx> I'll ping some of you for bugfix validation. Everyone else feel free to spend some cycles on checking the candidates when they will be available.
21:18:15 <ttx> If everything goes well, we'll release Nova 2011.1.1 early next week.
21:18:28 <ttx> Questions ?
21:18:45 <soren> Nope.
21:19:05 <ttx> #topic Review days for nova-core
21:19:12 <ttx> soren: floor is yours.
21:20:03 <soren> Cool.
21:20:46 <soren> So, the proposal that's been floating on the mailing list is that each day, there will be a member of nova-core who's responsible for doing reviews.
21:21:04 <soren> Everyone else is still encouraged to do reviews, of course.
21:21:33 <soren> It's meant as a tool to guarantee that proposed branches don't rot because noone wants to look at them.
21:21:46 <soren> If it's your review day, you have to review stuff that is still outstanding.
21:22:18 <soren> As a corrolary, if you're not ready to accept this responsibility, you don't get to be part of nova-core anymore.
21:22:23 <soren> That ensures currency of that team.
21:22:27 <justinsb> Do we need one or two core approves to get something merged?
21:22:32 <soren> Two.
21:22:34 <creiht> It seems a bit silly to me to have "assigned days"
21:22:44 <termie> There was a different (though not exclusive) proposal to require core devs to explicitly target their reviews to people appropriate for the review
21:22:47 <soren> So if the branch is perfect, it should never take more than two days to get something merged.
21:23:09 <vishy> soren: If the review is about an unfamiliar section of the code, should the guideline be to review for coding style and explicitely target someone who is familiar with that section?
21:23:16 <jk0> I like the idea of targeting core reviewers
21:23:18 <soren> I think it would be perfectly reasonable for the first person reviewing that branch to target other reviewers.
21:23:27 <jk0> it might take one person out of context 10x as long to review code
21:23:28 <justinsb> Why don't we have two people 'on base', so that things can get done same-day?
21:23:43 <soren> Like, if it's a network related one, you might expliclity add vishy as a reviewer.
21:23:58 <kpepple> soren: +1
21:24:02 <creiht> Would it also be reasonable to have 2 reviews, with at least 1 core reviewer?
21:24:09 <creiht> That would seem to encourage outside reviews more
21:24:10 <termie> justinsb: i don't think same day is always the best if the extra day lets somebody with relevant opinions get a chance to look at it
21:24:20 <creiht> otherwise, a non-core review seems pointless
21:24:27 <soren> creiht: So far, the requirement has been two core devs.
21:24:41 <creiht> soren: I know, that's why I am offering an alternative
21:24:42 <jk0> creiht: ++, that leaves little incentive for non-core reviews
21:24:52 <termie> creiht: non-core reviews still elicit changes in the code
21:24:55 <soren> creiht: Reviews are not only a tool for getting stuff merged. It's a way for reviewer and proposer to both improve.
21:25:10 <soren> creiht: So no, I wouldn't say a non-core review is pointless at all.
21:25:26 <jk0> not pointless, but it might be harder to get non-core reviews
21:25:27 <soren> creiht: Oh, right I see what you're saying.
21:25:28 <creiht> soren: From the reviewers point of view, it feels pointless
21:25:33 <ttx> incentive for non-core reviews is to get noticed as a potential -core member
21:25:38 <justinsb> How about this: there's a daily core reviewer that does a faster first review (for style etc), and they ping the domain-expert core member once it's OK in terms of style.
21:25:45 <soren> creiht: With all due respect, then I think you're doing review wrong :)
21:25:49 <ttx> you have to do non-core reviews to convince people that you're a good reviewer
21:25:52 <termie> justinsb: that sounds pretty good
21:26:07 <creiht> wow
21:26:07 <vishy> justinsb: +1, they can also do extensive reviews for the parts of code that they are familiar with
21:26:25 <creiht> I'm just trying to get more interest in getting outsiders to review
21:26:27 <creiht> but meh
21:26:31 <jk0> here's another way to look at it
21:26:49 <vishy> soren: i think he's talking about the non-core reviewers POV
21:26:53 <jk0> personally I am more familiar with xenapi, and have no dev envs available for testing kvm (for example)
21:26:53 <creiht> glad trunk never breaks for nova because you have 2 *core* reviewers
21:27:14 <jk0> how can one do a thorough kvm review w/o having a kvm test env?
21:27:14 <vishy> soren: as in if you aren't in core, why bother to review, because it doesn't "seem" to help
21:27:36 <soren> creiht: The "problem" is that we have no group in between nova-core and "complete stranger who happens to manage to click a button on a web ui".
21:27:48 <termie> vishy, soren, creiht: reviews help as much as contributing code
21:28:09 <termie> contirbuting code does not require core status, neither does reviewing
21:28:10 <ttx> vishy: maybe we should make it more obvious that it helps, even if it doesn't strictly count toward acceptance ?
21:28:17 <vishy> termie: i understand that, but to a new contributor i can see how it would feel "pointless"
21:28:20 <soren> vishy: What termie says, basically.
21:28:20 <creiht> termie: I agree, and is why I am making suggestions in an effort to try to increase the chance that you get others to review
21:28:28 <vishy> ttx: +1
21:28:45 <creiht> soren: I would suggest that it would be the core reviewer who would determine if an outsiders review is reasonable
21:28:54 <soren> The point of review isn't one of gatekeeping. It's just as much about improving as a programmer and to get to learn the code base. This is true for both reviewer and proposer.
21:28:55 <jk0> any feedback on not being able to give a thorough review if you don't have a particular test env?
21:29:02 <ttx> My point is that if you want to join nova-core, you should do "community" reviews, that should help with your application
21:29:03 <termie> ttx: one could think of it this way: it is unlikely that points raised in a treview by a non-core member would not be addressed
21:29:12 <vishy> can we create a master list somewhere (wiki perhaps) of sections of the code, where people can mention that they want to be included in reviews about a section
21:29:35 <vishy> the daily person can use the list to assign one (or more) specific reviews
21:29:49 <soren> vishy: That sounds like a good idea.
21:29:50 <ttx> we clearly need reference docs about reviews :)
21:30:06 <creiht> a review board!
21:30:06 <vishy> ttx: i think termie volunteered to do that
21:30:07 <termie> ttx: that's an action item for me
21:30:08 <creiht> :)
21:30:17 <soren> Does anyone have strong feelings against the corolary?
21:30:32 <soren> "corollary"
21:30:35 <jk0> I have a concern
21:30:37 <jk0> any feedback on not being able to give a thorough review if you don't have a particular test env?
21:30:38 <soren> Shoot.
21:30:57 <vishy> jk0: style review + request a specific review from someone
21:30:59 <termie> jk0: point the review at somebody else so they can check also
21:31:00 <jk0> I personally like to test as much as possible unless it's an obvious one-liner
21:31:03 <vishy> using the wiki
21:31:23 <soren> jk0: It kind of feeds back into our need for better test infrastructure.
21:31:23 <vishy> +3 for functional testing of arbitrary branches
21:31:27 <soren> jk0: Ideally, we
21:31:40 <soren> 'd have means for testing any/all sort of setup.
21:31:47 * creiht would hope someone actually tries to run the code they review
21:32:06 <jk0> creiht: that's my point.. right now, we really can't
21:32:21 <jk0> so I think that wiki would be a good idea
21:32:22 <soren> jk0: Do you have specific examples?
21:32:39 <jk0> yep, for example we only use XenServer in our labs
21:32:41 <termie> soren, jk0: his specific examples were kvm vs xen
21:32:57 <jk0> so there's no way for us to test something that requires kvm or anything else like that
21:32:58 <ttx> I think we are drifting from the main subject, which is "review days, yes or no"
21:33:35 <jk0> I think the review days would work if we ensured we all had the appropriate testing envs
21:33:47 <soren> creiht: Re: your suggestion above: Do you have a specific proposal? How would you differentiate between someone who just created an lp account and went and randomly clicked approve on stuff vs someone who's actually a useful reviewer?
21:33:50 <ttx> jk0: oh, I see your point.
21:33:57 <vishy> +1 for review days (with primary job being to find another tester if you can't test it)
21:34:05 <ttx> jk0: currently you have the choice to ignore branches you can't test
21:34:12 <justinsb> I don't think a reviewer can ever test all environments, so that implies that we'll need to have automated testing.  Which also implies that trunk is going to be 'unstable'.  Once it passes testing, we could auto-merge it with a 'tested-trunk' branch
21:34:41 <ttx> jk0: with the proposal, if you can't test you have to point the review to someone that can.
21:35:02 <jk0> that sounds good to me
21:35:11 <soren> Reposting: Does anyone have strong feelings against the corollary (removing people from nova-core that cannot accept a review day every N days (where N is the number of human beings on the nova-core team)?
21:35:22 <ttx> jk0: not perfect by any means, but probably better that what we have now
21:35:43 <jk0> it should work -- we just need that wiki vishy mentioned where everyone lists their preferences
21:35:53 <creiht> It is my opinion that if you have to assign days to people to get reviews done, then you are doing it wrong
21:36:04 <ttx> soren: someone should be able to skip one day for various reasons without losing -core
21:36:20 <soren> ttx: Certainly.
21:36:39 <soren> creiht: We saw it very clearly coming up to feature freeze last time.
21:37:00 <soren> creiht: Very few people were doing reviews. Most were just working on their own, new features.
21:37:20 <creiht> I'm not saying the problem wasn't there, I just don't think that is the right way to solve it
21:37:36 <eday> creiht: I kind of agree, what if we have lots of API branches, but all the API experts don't have a "day" for a while? Seems like we should keep it open and just point folks out more
21:38:05 <jk0> perhaps we should just try targeting reviews for a while before assigning days?
21:38:16 <jk0> set that wiki up, see who can review it, and point it to them
21:38:25 <annegentle> soren: you'd have to run a schedule and have people swap review days if it landed on a day they couldn't do
21:38:25 <annegentle> soren: I think you'll have to have a certain percentage of missed review days before removing from core
21:38:28 <justinsb> ttx: Or they could swap!
21:38:32 <soren> eday: If the reviewer-of-the-day identifies it as a API sort of branch, they would assign it to API people. If a review is assigned to you, you're not supposed to wait two weeks until your review day comes up.
21:39:00 <soren> Again, this is not meant as an excuse for people to postpone doing reviews. It's meant to ensure that reviews get done.
21:39:12 <eday> soren: ok, so it's more of a review manager/assignee (and can handle simple reviews)?
21:39:20 <creiht> How about everyone do the responsible thing, and get reviews done?
21:39:21 <creiht> :)
21:39:23 <soren> annegentle: Sure, sure, we're reasonable people. Mostly.
21:39:27 <eday> err, assigner
21:39:32 <ttx> creiht: eh.
21:40:12 <soren> creiht: I wish it were that simple.
21:40:43 <soren> eday: I guess you could phrase it that way.
21:40:47 <eday> soren: I do think giving someone the review cattle prod is a good idea
21:40:52 <ttx> we can always backpedal if we realize that review days are not efficiently solving the nova review backlog
21:41:24 <jk0> in theory there should never be a backlog :)
21:41:34 <ttx> jk0: exactly.
21:42:00 <ttx> soren: do you have what you need out of this, can we move on ?
21:42:05 <soren> Ok, I'll send out an e-mail to all current nova-core members to see if anyone doesn't want to be part of this. If they say no, they're off the team. The rest end up on a schedule on the wiki where people of course are free to swap, etc., etc.
21:42:11 <soren> ttx: Yes, thanks.
21:42:22 <ttx> #topic Open discussion
21:42:22 <creiht> lol
21:42:58 <eday> I'd like to announce the new queue service will be named: burrow
21:43:12 <creiht> soren: shouldn't that have to go through the POC first? :)
21:43:14 <vishy> \o/
21:43:18 <ttx> we can continue to discuss how much more responsible swift core reviewers are :)
21:43:34 * ttx looks up burrow in a dictionary
21:43:44 <soren> It's like a warren, isn't it?
21:43:51 <vishy> soren: aye
21:43:56 <eday> burrow: A burrow is a hole or tunnel dug into the ground by an animal.
21:44:05 <vishy> soren: lots of little rabbits?
21:44:06 <annegentle> nice, it's a noun and a verb :)
21:44:11 <eday> soren: warren was already taken by a ruby amqp project
21:44:16 <soren> Imagine that.
21:44:18 <soren> :)
21:44:20 * ttx looks up urbandictionary for funnier definitions
21:44:36 <soren> creiht: At this point, I don't know.
21:45:04 <eday> AND, we'll be going with Erlang. More later on the ML, but there seems to be more enthusiasm there. If it is a mistake, we'll make the mistake faster with Erlang too :)
21:46:13 <eday> if you're an Erlang pro and want to be on the burrow-core list for reviews, let me know :)
21:47:18 * vishy is not a pro, but I'll subscribe nonetheless
21:47:51 <vishy> POC isn't necessary for internal project decisions
21:48:04 <creiht> vishy: My only question was on core team removal
21:48:20 <vishy> but we may need to draft the proposal
21:48:27 <creiht> true
21:48:33 <vishy> because it overrides the POC one
21:50:29 <ttx> "to be lazy, lame, or without purpose."
21:50:29 <ttx> sounds good.
21:50:30 <ttx> any other news people want to share before we close the bar ?
21:50:30 <ttx> #info the new queue service will be named: burrow
21:50:30 <ttx> ok, I guess we are done
21:50:30 <ttx> #endmeeting