20:07:22 #startmeeting 20:07:22 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:07:55 #topic More frequent releases 20:08:18 chuck sent out a note talking about more frequent releases...there was some discussion on the list about it 20:09:06 Yup. 20:09:08 i'm wondering if the issue can be handled by projects self-identifying stable branches? 20:09:24 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 johnpur: i had a similar idea 20:09:26 rather than packaged releases? 20:09:39 there was always the intention to allow subproject to have more frequent releases 20:09:50 originally at least 20:10:18 they would then pick one release to be the version included in the overall openstack release 20:10:24 basically 3 repos: trunk . tested . release 20:10:35 this would be adequate for the RAX product teams, i think 20:11:00 and be simple 20:11:15 moving from trunk to "tested" would be determined by the team, either through automated or manual testing and qa 20:11:16 that means that they will be managing those releases outside of ttx's domain, right? 20:11:17 vishy: does that sync up at some point to an "openstack release"? 20:11:48 jbryce: my thought is that when we do an "openstack release" we just copy the most recent tested into "release" 20:12:01 jbryce: obviously there is a little more to it than that 20:12:02 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 dendrobates: yes, ttx is focussed on the OS idenified releases 20:12:10 jbryce: but that is the basic idea 20:12:39 dendrobates: right we need to put extra effort into integration and upgrade paths when we move things into release 20:12:48 i think the points ewanmellor brought up about longer term support are really valid too 20:13:27 also, the points that ewanmellor brought up about enterprise adoption and timing/testing cycles are right on 20:13:28 like ewanmellor said upgrade between openstack releases is important 20:13:32 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 it would be good to find out from chuck if this idea would work for them. 20:14:21 thiss is what chuck and the RAX CF team are doing now, essentially 20:14:25 we are planning a summit discussion about how we could do this and automate it for nova. 20:14:32 I don't think I fully understand what is being proposed. 20:14:34 it's very similar to what ubuntu does with lts releases 20:14:51 soren: i'm right there with you 20:15:05 sounds like a few different ideas being tossed around 20:15:08 soren: basically we have the current trunk 20:15:26 each build from trunk goes through automatic/manual testing 20:15:48 there is some process to move one of these builds into "testing" 20:16:00 not sure what the best name for this repo is 20:16:10 i think debian calls it "unstable"? 20:16:20 That would be trunk. 20:16:34 but they are basically "more stable/tested versions of the code" 20:16:48 vishy: That really feels like we're giving up on trunk. 20:17:27 I don't think stuff should hit trunk until it's gone through the test battery. 20:17:30 soren: I think it is very optimistic to think that trunk is going to be stable enough 20:17:37 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 vishy: How is it more optimistic to think that the same thing, named differently will be stable? 20:18:06 soren: think about how large the test battery is supposed to be. 20:18:31 vishy: *massive* 20:18:40 soren: merging will likely become a nightmare if every bugfix has to wait for the whole battery to run. 20:18:54 soren: ultimately I agree with you i would like trunk == testing 20:19:00 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 soren: I just don't think we are there in a reasonable amount of time 20:19:21 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 soren: + some projects may want to include manual testing. 20:19:40 soren: correct 20:20:05 vishy: I have some ideas how to pull this off. 20:20:17 soren: say we make a large change that breaks one little-used hypervisor 20:20:21 vishy: I firmly believe we can keep trunk stable without impeding development. 20:20:34 soren: if there are a lot of branches dependent on that change 20:20:48 soren: all merges are held up until the fix is in for that hypervisor 20:20:52 vishy: I'd love to have this discussion, but I think it's the wrong forum. 20:21:01 soren: agreed, i was just going to suggest 20:21:10 soren: this is the summit discussion we want to have 20:21:39 Sure. 20:21:41 ok 20:21:42 we also need to think about how much of this should be mandated by this board 20:22:01 soren: the more important question is can projects provide a "stable" branch that isn't the official openstack "release". 20:22:18 I think we need to leave most of this up to the sub project 20:22:26 dendrobates: agreed...i think it should mostly be around the major openstack releases where things need to work well together 20:22:29 I think that they should be able to, but I would prefer to not call it a "release" 20:22:52 for the reasons around upgrading that ewan mentioned 20:23:23 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 so it seems like there are 2 issues (tell me where i'm wrong): 20:25:01 1) getting updates/fixes/features out in individual projects between openstack releases 20:25:30 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 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 for #1 there has to be a stronger statement on interop and compatibility 20:27:42 it is useless to have a stable version (say of glance) that is broken from the stable version of nova 20:28:05 right 20:28:20 Well.. 20:28:36 See, if we're serious about having Ubuntu as our reference platform.. 20:28:51 Ubuntu promises to have a working upgrade path from one LTS to another. 20:29:24 In terms of OpenStack releases, that means that upgrades for N to N+8 must work, for specific N. 20:29:45 so we could use that as our goal. 20:29:54 So we at least line up with *something* 20:30:00 but ubuntu could do that work 20:30:22 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 soren: don't disagree, but this is a different topic than the one chuck brought up 20:31:04 johnpur: Sort of. 20:31:26 johnpur: It's a specific example of a consumer of our code that has specific requirements about upgrade paths. 20:31:44 we need to give guidance on what a project release is and what the expectations are 20:32:21 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 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 johnpur: you think project releases should be uniform across all the projects for every project release? 20:33:10 3) upgrade path between OS releases should be required 20:34:54 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 soren: do you foresee doing 3 mo releases forever (thinking in terms of your n+8 comment) 20:35:10 expectation on interop, etc. 20:35:36 fyi, in another meeting as well right now so I'll be a little slow to respond 20:35:52 jbryce: god I hope not 20:35:59 jbryce: At least for the foreseeable future. 20:36:35 jbryce: Once things start settling down, we might go for longer release cycles. 20:37:57 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 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 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 it may be that there is too much to handle less than 3 month cycles for compute 20:40:19 could swifts monthly releases just be milestones in lp? 20:40:53 dendrobates: likely, but they don't want to maintain private branches to match the deployed code 20:40:53 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 those milestones could be a part of a larger OS release 20:41:34 each milestone can have a branch/tarball associated with it 20:42:27 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 jbryce: Thanks, that would be useful. 20:44:22 johnpur: do you want to ask chuck or someone to work on that release description for swift? 20:44:39 sure 20:45:08 #action jbryce to schedule summit discussions on releases; include projects representatives and distro experts 20:45:40 #action johnpur to coordinate release process description for frequent swift releases 20:46:15 anyone have anything else on this topic they want to get out there now? 20:46:46 ok 20:46:58 #topic PTL nomination requirement 20:47:07 this was the other question chuck raised over email 20:47:20 "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 I agree. 20:47:48 +1 20:48:19 +1 20:48:57 +1 20:49:34 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 hm? 20:50:26 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 core teams have been overwhelmingly made up of rackspace employees 20:50:35 hard to imagine that a ptl could even be effective, having not been a core contributor 20:52:04 sounds like most people agree...ewanmellor do you have any thoughts on it? 20:53:18 #info agreed that PTL nominees should be members of the project's -core team 20:53:23 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 we are getting a little more diversity on the nova-core team at least 20:53:54 I think that the election should be enough to decide whether the person is capable of doing the job or not. 20:54:07 So I'm a +0. 20:54:48 ok 20:55:06 #topic Other stuff... 20:55:16 anyone have anything else they want to discuss? 20:55:20 perhaps "nominated by a core member is enough" 20:55:49 getting one core member to vouch for you is a lot easier than becoming a core member 20:56:12 that's not a bad idea 20:56:25 Yes, good compromise. 20:56:58 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 johnpur: which seems off? being able to do it or not being able to do it? 20:58:38 i vote that the ptl needs to be a core contributor. the ptl position should be hard to obtain! 20:59:02 I forget, who can vote for PTL's? 20:59:14 contributors to the project 20:59:20 anyone who has had code accepted for that project 20:59:21 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 people with a commit in the tree or members of ~openstack on lp? 20:59:25 Ok. 20:59:40 vishy: i agree that it's never going to happen 20:59:42 soren: they used the Authors file 21:00:05 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 soren: yes! 21:00:20 soren: yes, some rockstar added a test. 21:00:25 * jbryce pats soren on the back too 21:00:49 :) 21:00:55 ok...well...that's time. i'll send an email out on the PTL issue 21:01:15 thanks guys! 21:01:22 #endmeeting