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