21:00:42 #startmeeting 21:00:43 Meeting started Thu Feb 17 21:00:42 2011 UTC. The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:44 Useful Commands: #action #agreed #help #info #idea #link #topic. 21:00:45 * creiht bows 21:00:45 jesse and I only have 1/2 hour as well 21:00:52 so lets go quick :) 21:01:05 fine with me...agenda is here: http://wiki.openstack.org/Governance/POC 21:01:39 #topic Image format proposal 21:02:19 after the meeting last week, john circulated some additional comments and clarification on the image format proposal. did you all see that thread? 21:02:29 yep 21:02:31 yes 21:03:08 it seems like ewan got his questions answered and the initial scope of the image interchange format is narrowed to interop between openstack clouds 21:03:34 are there any other outstanding questions or concerns on that proposal? 21:03:41 no it lgtm 21:03:49 me too 21:04:14 ok...let's take a vote on approving it 21:04:31 * creiht doesn't vote as I have no background in this area 21:04:40 +1 21:04:57 +1 21:04:59 +1 21:05:04 * soren is here, too :) 21:05:27 +1 21:05:42 vishy, jmckenty: any desire to vote? 21:06:16 +1 21:06:22 oh sorry thought my lgtm counted 21:06:24 :) 21:06:25 ewanmellor: hi ewan...we were just voting on the image format proposal now that john circulated the updated comments 21:06:25 Sorry I'm late -- my last call overran. 21:06:31 +2 21:06:34 Ha 21:06:40 That was meant to be a +1 ;-) 21:06:50 But now it looks like I'm _really_ in favour! 21:06:55 btw, there had been some licensing concerns about vhd. RS legal and outside FOSS legal has looked at it and said we are fine 21:07:06 #agreed ImageFormat proposal approved with 6 approves 21:07:23 Good -- Citrix is already shipping open-source VHD code, so it would be a shame if that wasn't legal! 21:07:35 all right...moving on 21:07:37 #topic versioning and minor releases 21:08:51 #info proposal floated last week was that all projects should line up for the major releases on a fixed time schedule but that individual projects would have the flexibility to do an intermediate release if the core team felt it was needed. the release manager would facilitate the process and work to ensure quality 21:09:18 this seems to be the general approach that we are following currently with the one-off for bexar in nova 21:09:35 I'm ok with that, we definitely need a .1 release in nova, there are some pretty nasty bugs 21:09:40 I like this approach - what does swift thing? 21:09:42 think 21:09:51 jesse_: it was my idea :) 21:09:59 +1 for me 21:10:06 sorry, was on a plane last week ... 21:10:19 we will likely want to do a 1.2.1 release in the near future 21:11:18 +1 21:11:24 i'm ok with the proposal to give projects the flexibility to do what they need to, but i think it would be good to flesh out some sort of additional plan that makes it a little more clear how we work with downstream distributors 21:12:55 so creiht, jesse_, vishy are all on board--do the rest of you have any thoughts on it? 21:13:03 jbryce: is this something that we can say for the next two releases 21:13:05 we need a plan to support releases 21:13:14 creating releases is easy 21:13:31 dendrobates: yeah that is the next step once we decide that we are going to have point releases 21:13:35 jbryce: and re-evaluate post-diablo 21:13:43 dendrobates: I think that should be up to the individual projects as well 21:14:28 maybe, but is there is a combined integrated release, people expect the same support period 21:14:41 creiht: i think it would be nice for there to be some consistency at that level across openstack projects. if i'm a user, i would prefer to have at least a general idea of what to expect in terms of ongoing support and patching across all the projects 21:15:35 especially in terms of timing...if swift eols every 6 months and nova every 18 months and i'm using them both, that would be a pain 21:15:43 In my view the point releases would be bug fix/security fixes only 21:15:45 not features 21:16:09 jbryce: ahh good point 21:16:28 creiht: Certainly. 21:16:36 I agree, but for how long are you going to release bug fixes for a major release? that is where we need to standardize 21:16:53 I can see why there might be some divergence here. 21:17:08 Swift is way more mature than Nova. Doing bug fix releases further back makes more sense for Swift. 21:17:08 What I was thinking for swift is that we would support the last released version 21:17:21 ...or not :) 21:17:23 Ok :) 21:17:24 heh 21:17:31 haha 21:17:38 3 month eol cycle 21:17:39 I don't see many more big number releases for swift down the road 21:18:10 We are even stretching to call cactus a 1.3 release for swift 21:18:14 * soren puts that in a Quotes file. 21:18:18 lol 21:18:28 I *know* that will come in handy some day :) 21:18:46 so...i kind of like jesse_'s idea where we say for the next two release cycles we leave it up to the projects and during that time, come up with a unified plan that will be the default across projects 21:19:13 around that time is when distros will start playing a major role 21:19:16 agreed 21:19:28 I really like the way kvm handled supporting releases when they started out 21:19:40 I expect this to change down the road as all the projects mature more, and as more projects are brought in 21:19:50 dendrobates: how was that? 21:19:50 they made the distros do any packporting, until the rate of change slowed 21:20:19 If nothing else, the backporting/point releases makes it easier for us to manage swift releases to RS 21:20:19 soren did kvm backporting for ubuntu until the started maintaining a stable branch 21:21:45 we don't have very broad distribution support right now 21:22:00 Nor did kvm :) 21:22:40 we will soon, both fedora and ubuntu 21:22:55 And Debian. 21:23:07 When that happens, we can re-evaluate :) 21:23:17 we seem to already have quite a few users who are not consuming it through a distro 21:23:20 creiht: +1 21:23:41 as openstack + distro story matures we shoudl re-evalute 21:24:32 and then once the rate of feature change slows we should reevaluate again 21:24:40 sounds good 21:24:41 ok 21:24:44 #info revised proposal is to allow project core teams to decide to do point releases, facilitated by the release manager up to the diablo release 21:25:39 #info follow up with a unified release plan that takes into accounts division of upstream/downstream labor and support time frames 21:26:12 can we vote on the revised proposal? 21:26:26 +1 21:26:26 +1 21:26:28 sure 21:26:29 + 21:26:31 +1 21:26:47 +1 21:26:48 +1 21:26:56 +1 21:27:10 #agree revised proposal agreed to with 6 approves 21:27:28 #action jbryce to document and add to wiki 21:27:56 so we've only got a couple of minutes before several have to leave...do we want to postpone the other items and meet again next week? 21:28:20 +1 21:28:57 sure 21:28:59 +1 21:29:20 i'm sure jesse and vish agree since they have to leave. = ) 21:29:26 hehe 21:29:49 +1 21:30:14 although we might be able to keep going with 2 meetings at once 21:30:37 soren, ewanmellor: do you guys want us to try to alternate meeting times to something that's more normal for you? 21:31:08 I'll be in Santa Clara next week. 21:31:44 jbryce: Possibly. 21:32:17 jbryce: I've tried that a number of times, but it usually just ends up being at dinner time which is way worse than late evening. 21:32:57 soren: are you utc+1? 21:33:15 jbryce: At the moment, yes. 21:33:24 For another month and a half. 21:33:35 -ish. 21:33:56 soren: Where are you going? 21:34:07 Nowhere. 21:34:13 The Earth is. 21:34:42 (DST change) 21:34:51 :-) 21:35:06 well...i'm open to whatever as far as the time. i think you two have the biggest offset, so let us know if you want to alternate and make jesse, vish and josh wake up early for a change. 21:35:37 * jbryce offended jmckenty and he left 21:36:12 for now, we'll plan on same time next thursday. i'll send out a note and the leftover agenda items. 21:36:17 k 21:36:36 thanks guys! 21:36:38 #endmeeting