20:07:22 <jbryce> #startmeeting
20:07:22 <openstack> Meeting started Thu Mar 31 20:07:22 2011 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:07:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:07:55 <jbryce> #topic More frequent releases
20:08:18 <jbryce> chuck sent out a note talking about more frequent releases...there was some discussion on the list about it
20:09:06 <soren> Yup.
20:09:08 <johnpur> i'm wondering if the issue can be handled by projects self-identifying stable branches?
20:09:24 <jbryce> the existing temporary policy that we had put in place previously basically said that all core projects would release together on a time basis, but that in between that releases were basically up to the individual projects
20:09:25 <vishy> johnpur: i had a similar idea
20:09:26 <johnpur> rather than packaged releases?
20:09:39 <dendrobates> there was always the intention to allow subproject to have more frequent releases
20:09:50 <dendrobates> originally at least
20:10:18 <dendrobates> they would then pick one release to be the version included in the overall openstack release
20:10:24 <vishy> basically 3 repos: trunk . tested . release
20:10:35 <johnpur> this would be adequate for the RAX product teams, i think
20:11:00 <johnpur> and be simple
20:11:15 <vishy> moving from trunk to "tested" would be determined by the team, either through automated or manual testing and qa
20:11:16 <dendrobates> that means that they will be managing those releases outside of ttx's domain, right?
20:11:17 <jbryce> vishy: does that sync up at some point to an "openstack release"?
20:11:48 <vishy> jbryce: my thought is that when we do an "openstack release" we just copy the most recent tested into "release"
20:12:01 <vishy> jbryce: obviously there is a little more to it than that
20:12:02 <dendrobates> all that an openstack realease has to mean is that these are the versions that we have tested and work together well
20:12:02 <johnpur> dendrobates: yes, ttx is focussed on the OS idenified releases
20:12:10 <vishy> jbryce: but that is the basic idea
20:12:39 <vishy> dendrobates: right we need to put extra effort into integration and upgrade paths when we move things into release
20:12:48 <jbryce> i think the points ewanmellor brought up about longer term support are really valid too
20:13:27 <johnpur> also, the points that ewanmellor brought up about enterprise adoption and timing/testing cycles are right on
20:13:28 <dendrobates> like ewanmellor said upgrade between openstack releases is important
20:13:32 <vishy> jbryce: exactly i think we only need to provide upgrade paths between the "release", but it gives more frequent options for bleeding edge deployments that can't handle the instability of trunk.
20:13:56 <vishy> it would be good to find out from chuck if this idea would work for them.
20:14:21 <johnpur> thiss is what chuck and the RAX CF team are doing now, essentially
20:14:25 <vishy> we are planning a summit discussion about how we could do this and automate it for nova.
20:14:32 <soren> I don't think I fully understand what is being proposed.
20:14:34 <dendrobates> it's very similar to what ubuntu does with lts releases
20:14:51 <jbryce> soren: i'm right there with you
20:15:05 <jbryce> sounds like a few different ideas being tossed around
20:15:08 <vishy> soren: basically we have the current trunk
20:15:26 <vishy> each build from trunk goes through automatic/manual testing
20:15:48 <vishy> there is some process to move one of these builds into "testing"
20:16:00 <vishy> not sure what the best name for this repo is
20:16:10 <vishy> i think debian calls it "unstable"?
20:16:20 <soren> That would be trunk.
20:16:34 <vishy> but they are basically "more stable/tested versions of the code"
20:16:48 <soren> vishy: That really feels like we're giving up on trunk.
20:17:27 <soren> I don't think stuff should hit trunk until it's gone through the test battery.
20:17:30 <vishy> soren: I think it is very optimistic to think that trunk is going to be stable enough
20:17:37 <johnpur> the one add is that we need to be able to "freeze" a stable branch... this is the interim "release" that chuck talks about, perhaps it is a production version for someone that will only take show-stopping bug fixes
20:17:47 <soren> vishy: How is it more optimistic to think that the same thing, named differently will be stable?
20:18:06 <vishy> soren: think about how large the test battery is supposed to be.
20:18:31 <soren> vishy: *massive*
20:18:40 <vishy> soren: merging will likely become a nightmare if every bugfix has to wait for the whole battery to run.
20:18:54 <vishy> soren: ultimately I agree with you i would like trunk == testing
20:19:00 <johnpur> this branch will not only get the OS automated testing, it will likely be the version that devops in target organizations will be testing extensively
20:19:08 <vishy> soren: I just don't think we are there in a reasonable amount of time
20:19:21 <soren> The alternative seems to be that once a broken thing lands in trunk, *everything* after it will also fail to reach the "stable" thing, until the original breakage is fixed.
20:19:32 <vishy> soren: + some projects may want to include manual testing.
20:19:40 <vishy> soren: correct
20:20:05 <soren> vishy: I have some ideas how to pull this off.
20:20:17 <vishy> soren: say we make a large change that breaks one little-used hypervisor
20:20:21 <soren> vishy: I firmly believe we can keep trunk stable without impeding development.
20:20:34 <vishy> soren: if there are a lot of branches dependent on that change
20:20:48 <vishy> soren: all merges are held up until the fix is in for that hypervisor
20:20:52 <soren> vishy: I'd love to have this discussion, but I think it's the wrong forum.
20:21:01 <vishy> soren: agreed, i was just going to suggest
20:21:10 <vishy> soren: this is the summit discussion we want to have
20:21:39 <soren> Sure.
20:21:41 <jbryce> ok
20:21:42 <dendrobates> we also need to think about how much of this should be mandated by this board
20:22:01 <vishy> soren: the more important question is can projects provide a "stable" branch that isn't the official openstack "release".
20:22:18 <dendrobates> I think we need to leave most of this up to the sub project
20:22:26 <jbryce> dendrobates: agreed...i think it should mostly be around the major openstack releases where things need to work well together
20:22:29 <vishy> I think that they should be able to, but I would prefer to not call it a "release"
20:22:52 <vishy> for the reasons around upgrading that ewan mentioned
20:23:23 <vishy> people should know that if they are using these other branches that upgrades crossing multiple versions and integration with other components aren't supported
20:24:42 <jbryce> so it seems like there are 2 issues (tell me where i'm wrong):
20:25:01 <jbryce> 1) getting updates/fixes/features out in individual projects between openstack releases
20:25:30 <jbryce> this one i think should mostly be up to the projects as long as the projects are able to have stable, compatible software when combined release time comes around
20:26:12 <jbryce> 2) longer term support for organizations who don't want to/aren't able to update on less than X month bases (12? 18? 24?)
20:27:04 <johnpur> for #1 there has to be a stronger statement on interop and compatibility
20:27:42 <johnpur> it is useless to have a stable version (say of glance) that is broken from the stable version of nova
20:28:05 <jbryce> right
20:28:20 <soren> Well..
20:28:36 <soren> See, if we're serious about having Ubuntu as our reference platform..
20:28:51 <soren> Ubuntu promises to have a working upgrade path from one LTS to another.
20:29:24 <soren> In terms of OpenStack releases, that means that upgrades for N to N+8 must work, for specific N.
20:29:45 <soren> so we could use that as our goal.
20:29:54 <soren> So we at least line up with *something*
20:30:00 <dendrobates> but ubuntu could do that work
20:30:22 <vishy> as long as we are clear in our messaging about the difference between an "openstack release" and a "project release" I think we are fine.
20:30:38 <johnpur> soren: don't disagree, but this is a different topic than the one chuck brought up
20:31:04 <soren> johnpur: Sort of.
20:31:26 <soren> johnpur: It's a specific example of a consumer of our code that has specific requirements about upgrade paths.
20:31:44 <johnpur> we need to give guidance on what a project release is and what the expectations are
20:32:21 <soren> johnpur: One that is well-defined and known *right now*. We can make all sorts of guesses about what sort of upgrade frequency this or the other enterprise wants, but this is known, existing data.
20:32:41 <vishy> expectations: 1) they need a project release that lines up with openstack release schedule.  2) They should expect to spend time on that release focusing on interop and upgrades
20:32:59 <jbryce> johnpur: you think project releases should be uniform across all the projects for every project release?
20:33:10 <vishy> 3) upgrade path between OS releases should be required
20:34:54 <johnpur> jbryce: hmmm... i just don't want there to be a random proliferation of "project releases" that all have differing expectations on what is delivered, what needs to be upgradable, etc.
20:35:06 <jbryce> soren: do you foresee doing 3 mo releases forever (thinking in terms of your n+8 comment)
20:35:10 <johnpur> expectation on interop, etc.
20:35:36 <vishy> fyi, in another meeting as well right now so I'll be a little slow to respond
20:35:52 <dendrobates> jbryce: god I hope not
20:35:59 <soren> jbryce: At least for the foreseeable future.
20:36:35 <soren> jbryce: Once things start settling down, we might go for longer release cycles.
20:37:57 <jbryce> it doesn't seem like we're really coalescing around a specific plan on this one right now. i think discussing at design summit is a good idea
20:39:26 <jbryce> also, i have to admit that i have a lot less experience shipping software that users are going to deploy on their own than building software that i get to push to them, so i'd love if someone who has more experience there wanted to volunteer to help coordinate this
20:39:28 <johnpur> suggestion: let's have someone actually describe what the monthly release for swift will look like, workflow and repository-wise. Swift is easy, as it has no dependencies. then, let's look at Nova and how we would manage keeping glance, network, volume, and compute in sync
20:40:11 <johnpur> it may be that there is too much to handle less than 3 month cycles for compute
20:40:19 <dendrobates> could swifts monthly releases just be milestones in lp?
20:40:53 <johnpur> dendrobates: likely, but they don't want to maintain private branches to match the deployed code
20:40:53 <ewanmellor> I agree that this would be good to discuss at the summit.  We need representatives from Nova & Swift at least.  Also, I think it would be good to have representatives from distros (e.g. Ubuntu, Citrix).Could someone own this, and co-ordinate the discussion at the summit?
20:41:03 <dendrobates> those milestones could be a part of a larger OS release
20:41:34 <dendrobates> each milestone can have a branch/tarball associated with it
20:42:27 <jbryce> ewanmellor: i can organize the discussion and ask a lot of dumb questions if there will be smarter people there to help answer them. = )
20:42:57 <ewanmellor> jbryce: Thanks, that would be useful.
20:44:22 <jbryce> johnpur: do you want to ask chuck or someone to work on that release description for swift?
20:44:39 <johnpur> sure
20:45:08 <jbryce> #action jbryce to schedule summit discussions on releases; include projects representatives and distro experts
20:45:40 <jbryce> #action johnpur to coordinate release process description for frequent swift releases
20:46:15 <jbryce> anyone have anything else on this topic they want to get out there now?
20:46:46 <jbryce> ok
20:46:58 <jbryce> #topic PTL nomination requirement
20:47:07 <jbryce> this was the other question chuck raised over email
20:47:20 <jbryce> "I would like to propose the requirements of the PTL should be changed so that in order to be nominated, and serve as PTL, that person must also be a core contributor to that project.  Currently, the only requirement is that the PTL has a commit to the code base.  I don't foresee this being an issue in this election, but could see it being an issue down the road."
20:47:43 <johnpur> I agree.
20:47:48 <vishy> +1
20:48:19 <dendrobates> +1
20:48:57 <soren> +1
20:49:34 <jbryce> one of the reasons why it was laid out the way it was is because of the makeup of the core teams with respect to rackspace employees
20:49:51 <soren> hm?
20:50:26 <vishy> it doesn't really block people, it just means that they have to go through the "get added to core" process before they can be nominated.
20:50:35 <jbryce> core teams have been overwhelmingly made up of rackspace employees
20:50:35 <johnpur> hard to imagine that a ptl could even be effective, having not been a core contributor
20:52:04 <jbryce> sounds like most people agree...ewanmellor do you have any thoughts on it?
20:53:18 <jbryce> #info agreed that PTL nominees should be members of the project's -core team
20:53:23 <ewanmellor> I'm ambivalent.  I agree with johnpur that the person likely won't be effective unless they've done the job, but I agree with jbryce that it's good not to put additional barriers that make it look like non-Rackers are kept out.
20:53:54 <jbryce> we are getting a little more diversity on the nova-core team at least
20:53:54 <ewanmellor> I think that the election should be enough to decide whether the person is capable of doing the job or not.
20:54:07 <ewanmellor> So I'm a +0.
20:54:48 <jbryce> ok
20:55:06 <jbryce> #topic Other stuff...
20:55:16 <jbryce> anyone have anything else they want to discuss?
20:55:20 <vishy> perhaps "nominated by a core member is enough"
20:55:49 <vishy> getting one core member to vouch for you is a lot easier than becoming a core member
20:56:12 <jbryce> that's not a bad idea
20:56:25 <ewanmellor> Yes, good compromise.
20:56:58 <johnpur> do we want the person who is leading the project to not be able to approve merges on their own? Seems a little off to me, but hey...
20:57:47 <jbryce> johnpur: which seems off? being able to do it or not being able to do it?
20:58:38 <johnpur> i vote that the ptl needs to be a core contributor. the ptl position should be hard to obtain!
20:59:02 <soren> I forget, who can vote for PTL's?
20:59:14 <johnpur> contributors to the project
20:59:20 <jbryce> anyone who has had code accepted for that project
20:59:21 <vishy> if someone wins the ptl and they aren't in core, we should add them.  I honestly think this is never going to happen...
20:59:22 <soren> people with a commit in the tree or members of ~openstack on lp?
20:59:25 <soren> Ok.
20:59:40 <jbryce> vishy: i agree that it's never going to happen
20:59:42 <vishy> soren: they used the Authors file
21:00:05 <soren> Isn't it awesome how that is guaranteed to be up-to-date? :)
21:00:12 * soren pats himself on the back
21:00:14 <jbryce> soren: yes!
21:00:20 <vishy> soren: yes, some rockstar added a test.
21:00:25 * jbryce pats soren on the back too
21:00:49 <soren> :)
21:00:55 <jbryce> ok...well...that's time. i'll send an email out on the PTL issue
21:01:15 <jbryce> thanks guys!
21:01:22 <jbryce> #endmeeting