21:01:24 <ttx> #startmeeting 21:01:25 <openstack> Meeting started Tue Nov 23 21:01:24 2010 UTC. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic. 21:01:31 <ttx> Welcome to our weekly OpenStack team meeting... 21:01:38 <ttx> Today's agenda is at: http://wiki.openstack.org/Meetings 21:01:45 <ttx> #info Remember you can add topics to the agenda by editing the wiki directly... 21:01:59 <ttx> #topic Actions from previous meeting 21:02:08 <ttx> * Dissenters to start a blueprint process thread on the MLs 21:02:25 <ttx> I saw the thread on openstack@lists.l.n, make sure your point is heard there 21:02:45 <ttx> #topic Current release stage: Implementation 21:02:58 <ttx> For the curious I documented the release cycle at: 21:03:05 <ttx> #link http://wiki.openstack.org/ReleaseCycle 21:03:15 <ttx> Comments/critics welcome :) 21:03:34 <ttx> So at this point you should be busy writing code, reviewing proposed branches, and pinging dendrobates so that he approves your design :) 21:03:51 <ttx> Any question on the current stage ? 21:04:27 <jk0> yes 21:04:43 <jk0> how are bug reports prioritized over blueprints? 21:04:43 <ttx> jk0: ask and you may get an answer. 21:04:52 <jk0> or vice versa 21:04:52 <soren> Carefully. 21:05:13 <jk0> or to put it another way, should we be focusing more on bugs or blueprints right now? 21:05:15 <ttx> jk0: the further you go into the cycle, the more focus the bugs should get 21:05:31 <vishy> late o/ 21:05:44 <ttx> jk0: it depends on the bug, I'd say. A critical issue should be fixed asap 21:05:49 <dendrobates> jk0: new feature work is the focus, unless pvo directs different for you 21:06:04 <jk0> great, thanks 21:06:12 <ttx> OK, moving on to a closely related topic... 21:06:17 <ttx> #topic Release status 21:06:36 <ttx> dendrobates is working on the bexar blueprint lists, so until we have them I don't really know what we want to track, so I don't really have a release status yet... 21:06:48 <dendrobates> ooh, blame me 21:06:59 <ttx> I will. 21:07:07 <ttx> #info I'm just a bit worried by the state of bexar-network-service, since it has a few specs depending on it and it looks stuck in Drafting... 21:07:19 <dendrobates> I have approved most everything, it seems like an unreasonable ammount of work for a release though 21:07:34 <ttx> #link https://blueprints.launchpad.net/nova/+spec/bexar-network-service 21:08:01 <ttx> dendrobates: approving the design is not the same as taregting to a specific release... especially since we planned for two 21:08:06 <dendrobates> ttx: I agree it needs to be ironed out early 21:08:25 <dendrobates> I mean just for bexar 21:08:47 <ttx> I agree the Nova list seems unrealistic, but I'm new around here :) 21:09:24 <ttx> dendrobates: should we have a cleaner and more realistic set of targets by next week ? 21:09:43 <dendrobates> I will be modifying priorities as soon as I get feedback from stakeholders 21:09:51 <ttx> dendrobates: i've been working on Glance bexar targeting with jaypipes 21:09:57 <ttx> it's almost clean. 21:10:09 <dendrobates> a large number of which, have been busy partying in Japan 21:10:11 <ttx> dendrobates: ok 21:10:35 <ttx> anything else on that subject ? 21:11:16 <ttx> #topic Bugs status meaning discussion 21:11:31 <ttx> OK, so in the same spirit as http://wiki.openstack.org/BlueprintsLifecycle, I need to document the Bugs lifecycle 21:11:45 <ttx> that is write in a reference doc what each status means to us. 21:11:55 <ttx> I'd like your input on that, since I have no strong opinion... 21:12:08 <ttx> In particular what meaning do you want for "Fix Committed" and "Fix Released" ? 21:12:41 <xtoddx> released = in trunk, committed = in branch proposed for merge ? 21:12:48 <jk0> ^ ++ 21:12:56 <soren> It's worth noting that bugs in "fix committed" are still listed on bugs pages. 21:13:04 <soren> "fix released" are not. 21:13:07 <ttx> xtoddx: I like that 21:13:26 <eday> well, one issue there 21:13:43 <eday> for non-developers who want something fixed, knowing it's in a release is good 21:13:52 <soren> So if we go with "in trunk "== "fix released", people may stumble upon a bug in a released version of Openstack, and not find it in the bug lists and report it again. 21:13:54 <ttx> basically, we say there is more value in seeing a bugfix is proposed for merging, than saying a release contains it 21:14:04 <eday> I could see users thinking since they got an official release, it's fixed, only to be disappointed 21:14:12 <soren> Conversely, keeping things at "fix committed" is really noisy to developers trying to get an overview of bugs. 21:14:40 <eday> soren: that's a LP bug then, we should be able to filter non-commited bugs, if we cant already :) 21:14:45 <ttx> I agree, ons solution is more user-oriented (users of releases) while the other is a bit developer-centric 21:14:55 <soren> eday: I'm sure we can. 21:15:03 <soren> eday: It's just the default list of open bugs. 21:15:12 <soren> eday: Bugs in "fix committed" are still "open". 21:15:42 <soren> Just as a data point, Ubuntu uses "fix released" as soon as a fix has been uploaded t othe archive. 21:15:50 <eday> soren: yup, and perhaps that's a bug we should file: default lists should not include comitted 21:16:02 <soren> eday: I'm not sure I'd agree with that. 21:16:15 <dendrobates> soren: but ubuntu targets bugs to specific releases 21:16:20 <xtoddx> we're building nightlies right? so landing trunk == releasing that day? 21:16:29 <ttx> hmm, sounds like this discussion would benefit from a larger forum. I'll kick a thread on the MLs about it 21:16:30 <soren> xtoddx: We're builing per commit. 21:16:38 <soren> xtoddx: building, even. 21:16:43 <soren> xtoddx: So more often than nightly. 21:16:54 <xtoddx> right, so i stand by landing in trunk == released 21:17:00 <soren> dendrobates: Not sure where you're going with that. 21:17:29 <soren> xtoddx: I'm slightly in favour of that as well, but could probably be convinced otherwise. 21:17:34 <ttx> #action ttx to start a thread about LP bug statuses (in particular FixCommitted meaning) 21:17:42 <soren> I just mentioned Ubuntu as a data point, not really as an argument either way. 21:17:43 <dendrobates> they can mark a bug fixed in the current dev release when it is uploaded, but not others 21:17:52 <soren> dendrobates: Oh, right. So can we. 21:17:55 <dendrobates> perhaps we should do the same 21:18:00 <dendrobates> that was my point 21:18:13 <soren> dendrobates: Gotcha. 21:18:18 <eday> so, I'm for whatever ubuntu does, because in the past I've found trying to use LP in a way ubuntu does not can be painful 21:18:33 <eday> but I do have that one concern 21:18:49 <dendrobates> Ubuntu is not known for great bug handling 21:18:57 <zul> heh 21:18:59 <ttx> soren, xtoddx, dendrobates, eday: I'll rehash the discussion on the ML to make sure everyone can expose his opinion. 21:19:03 <dendrobates> but they have a bazillion 21:19:37 <ttx> OK to move on ? 21:20:07 <soren> yup 21:20:16 <ttx> #topic Mailing list consolidation 21:20:20 <ttx> dendrobates: floor is yours 21:20:44 <dendrobates> ah yes 21:20:56 <dendrobates> at the summit we discussed the mailing lists 21:21:14 <dendrobates> and it was the nearly unanimous opinion that we had too many 21:21:26 <soren> Hear hear! 21:21:35 <dendrobates> We should cull the lists back to one main dev list and and announce list 21:21:50 <ttx> "too many" as in "too many without a single message posted in them" 21:22:00 <dendrobates> and revisit it when traffic for any one topic gets high 21:22:11 <soren> Can we make the announce list an actual announce list and not a medium for distributing news letters? 21:22:20 <dendrobates> I plan on culling the nova and swift lists, but... 21:22:24 <spectorclan> soren: i only sent the newsletter once to that list 21:22:36 <soren> Ok. 21:22:45 <dendrobates> soren: what announce list are you talking about 21:23:02 <soren> dendrobates: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce 21:23:02 <spectorclan> dendrobates: mailing lists from openstack.lists.org 21:23:13 <soren> An announce list is useful. 21:23:13 <dendrobates> ok 21:23:25 <soren> For announcing new releases and such. 21:23:25 <spectorclan> this holds the complete 4,000+ people who registered on the website during launch of openstack 21:23:31 <dendrobates> I need to ask LP what to do about the archives 21:24:07 <soren> dendrobates: You want to consolidate all of {openstack,nova,swift}@lists.launchpad.net into one? 21:24:15 <dendrobates> yes 21:24:19 <soren> Sounds great. 21:24:30 <dendrobates> only openstack would remain 21:24:40 <soren> Right. 21:24:50 <ttx> yes, we should divide them when traffic gets too heavy, not before they get any traffic. 21:24:55 <dendrobates> do you agree that not losing the archives is important? 21:25:11 <dendrobates> Figuring that out will delay it a little bit. 21:25:14 <soren> Can't we just disable the mailing list, keeping the archives? 21:25:23 <xtoddx> dendrobates: i could care less about the archives 21:25:27 <soren> I should know the answer to that, really. 21:25:36 <dendrobates> I don't assume anything with LP 21:25:40 * soren checks 21:25:51 <eday> I think thats the case, I disabled a list once 21:25:58 <eday> and the archives remained 21:25:59 <dendrobates> great 21:26:01 <spectorclan> We should keep the archives 21:26:20 <dendrobates> are there any objections to dropping nova and swift? 21:26:33 <ttx> there is /some/ value in keeping the archives... but not enough to prevent us from merging in the near future 21:26:51 <soren> So what wil happen to the teams? 21:27:00 <dendrobates> ttx: I just wanted to know how hard to work at it, if it wasn;t easy 21:27:03 <eday> does glance have it's own too we should include? 21:27:08 <soren> They exist mostly to have these mailing lists, afaik. 21:27:14 <dendrobates> the teams will not change 21:27:32 <xtoddx> you can use teams to request reviews of merge proposals 21:27:47 <ttx> glance has a list too 21:27:52 <xtoddx> for that reason alone they are worth keeping 21:28:05 <ttx> nothing posted to it in the archives. 21:28:20 <dendrobates> I don;t want to change the teams right now. One painful change at a time please 21:28:46 <soren> dendrobates: No problem. I was just wondering if they were going to be repurposed. 21:28:52 <eday> i see no need to change teams 21:29:00 <ttx> #action dendrobates to merge (or delegate merging of) the MLs, keep the archives 21:29:02 <dendrobates> OK, I'll send an email to all the list explaining the changes. 21:29:14 <dendrobates> so please ignore multiple copies 21:29:35 <ttx> anything more on that subject ? 21:29:55 <dendrobates> nope 21:30:02 <ttx> #topic Merge queue backup in nova 21:30:06 <ttx> eday: floor is yours 21:30:19 <eday> so, there are two thigns here I wanted to address 21:30:49 <eday> First, we have a lot of things in the queue, we all need to review more :) 21:31:16 <eday> If you have an oustanding branch, don't be afriad to ping people in IRC to get a review 21:31:38 <eday> Second, there are a few branches that are quite stale 21:31:49 <eday> Some dated in Sept/Oct... what should we do with these? 21:31:56 <dendrobates> I can purge those 21:32:09 <eday> They most likely will not merge, but I don't want to lose the work 21:32:11 <dendrobates> but some, i.e. raw disk images need to be picked up 21:32:24 <dendrobates> the branches don't go anywhere 21:32:41 <eday> But if no one pushes them forward, they're as good as gone :) 21:32:47 <dendrobates> true 21:33:05 <eday> I guess we should ping the folks who proposed them and see what each status is 21:33:16 <eday> ie: xtoddx, what is the plan for auth-server? 21:33:19 <ttx> eday: if they are linked to a blueprint or a bug, they should still be found 21:33:38 <dendrobates> ttx most of the old ones are not 21:33:51 <eday> ttx: yup, but I'm just saying we should piss or get off the pot with the merge props :) 21:33:52 <xtoddx> eday: need to do gap with what has been merged with the osapi to see what else needs to happen 21:34:02 <xtoddx> eday: the only critical part is a middleware for swift auth 21:35:42 <eday> xtoddx: ok, so we should probably remove the merge prop until thats ready 21:35:52 <xtoddx> indeed 21:36:24 <eday> Ok, that's all, I just wanted to get things moving to keep the merge prop page clean, rather than having to remember which ones are actually valid or not 21:36:40 <dendrobates> thanks for bringing it up 21:36:48 <eday> Also, some things are hard to approve becuse there's no way some of us can test certain configs, but that's another issue 21:37:17 <ttx> So cleaning it up is a recurrent work that everybody with enough power should help with, right 21:37:43 <ttx> it = the activereviews page(s) 21:38:01 <dendrobates> right 21:38:40 <ttx> for the record, I plan to work on a dashboard that should start blinking when we reach some absuive situation 21:39:01 <ttx> like say, having 2-month old reviews stuck or too many of them unreviewed 21:39:14 <eday> ttx: cool 21:39:27 <ttx> that should help us with the overall "health" of the project 21:39:34 <eday> ttx: and wire that up to tazers for all nova-core 21:39:45 <ttx> I like that. 21:39:54 <ttx> #topic Open discussion 21:40:30 <ttx> Anything else on your mind ? 21:40:57 <dendrobates> anyone pissed off about anything :) 21:41:40 <spectorclan> I will have the new Events Page up later today with all links of slides and videos from Design Summit 21:41:50 <spectorclan> Watch twitter for announcement 21:41:54 <eday> any word yet on location for next design summit? 21:42:00 <xtoddx> it looks like not all the blog posts are going to the wiki sidebar 21:42:08 <spectorclan> we are thinking Silicon Valley as 20% of all attendees were from there. 21:42:35 <spectorclan> I have created a new wiki page to plan the event in the open and will launch that next Monday after the holiday 21:42:35 <ttx> spectorclan: better beer in Dublin, and starts with a D ;) 21:42:49 <zykes-> will there be any events in europe ? 21:42:53 <spectorclan> ttx: we are going to Europe as well in 2011, just not sure when yet but we will be there 21:43:01 <zul> heh there is more to this world than silicon valley 21:43:05 <spectorclan> We are planning on LinuxTAG and others 21:43:20 <zykes-> spectorclan: any in britain / nordics ? 21:43:20 <spectorclan> We will have a Europe Design Summit in the summer some time, weather is nicer 21:43:27 <annegentle> xtoddx: re: blog > wiki, what do you mean? 21:43:34 <spectorclan> Where in Europe is open to this group? 21:43:49 <xtoddx> sorry, not wiki, but http://openstack.org/ 21:43:51 <spectorclan> I like Munich 21:43:57 <eday> spectorclan: rackspace UK offices? 21:44:04 <xtoddx> annegentle: the right sidebar of "latest" doesn't have all the blog content 21:44:05 <soren> ttx: Good idea! I have a couple of Guiness vouchers left from my last visit. 21:44:09 <ttx> spectorclan: Brussles is the most central, due to high speed trains 21:44:12 <zykes-> Munich, plan it right after CEBIT : p 21:44:15 <ttx> Brussels 21:44:27 <ttx> Munich is almost unreachable. 21:44:32 <spectorclan> as you can see, lots of ideas. Will let you know and we are thinking CEBIT for OpenStack also 21:44:36 <spectorclan> OK, Brussels?? 21:44:40 <annegentle> xtoddx: ah yeah I see what you mean. I'll ping Todd Morey on that. Maybe it's highly selective :) 21:44:51 <ttx> spectorclan: or Paris or Amsterdam, but those are more expensive. 21:45:11 <zykes-> What about london ? Copenhagen ? 21:45:15 <spectorclan> I have been to all three and do like Brussels, not a big fan of Paris and Amsterdam has too many distractions. 21:45:23 <spectorclan> zykes: London is very $$$$ 21:45:29 <spectorclan> Don't know much about Cophenhagen 21:45:31 <dendrobates> London is expensive and Copenhagen is full of Danes 21:45:42 <zykes-> poor soren (: 21:45:48 <ttx> also Copenhagen is just reachable by plane. Or boat. 21:45:48 <soren> It's true. 21:46:00 <spectorclan> Will look at 2011 event plan and see what timing looks best and get your thoughts. 21:46:14 <zykes-> spectorclan: will there be any blog posts regarding that ? 21:46:18 <spectorclan> So, plan is May in Silicon Valley; Fall in Japan and Summer in Europe 21:46:25 <ttx> In Europe we have that thing called high speed train than the Swiss, French, BeneLux and English can use to go all over the place. 21:46:52 <dendrobates> I think there will be resistance to the valley 21:46:52 <spectorclan> zykes: Yes I will post blogs on the options as well as use IRC to pre-discuss. All event planning will be in the open in the wiki. 21:47:06 <dendrobates> it seemed like there was at the summit 21:47:13 <spectorclan> dendrobates: I know this but it is hard to ignore the 20% of the attendees from there 21:47:16 <dendrobates> but it is easy to get ot 21:47:16 <eday> folks in the valley are always looking for excuses to get out, just fyi :) 21:47:30 <dendrobates> no it's not. Which attendees 21:47:39 <soren> ttx: Yeah, much better than high speed buses: http://www.theonion.com/video/obama-replaces-costly-highspeed-rail-plan-with-hig,18473/ 21:47:42 <spectorclan> I have the lists and can pass them along to you 21:48:02 <zykes-> spectorclan: question, would it be possible to drag in ZenOSS as well ? 21:48:18 <ttx> ok, we'll close now, I guess dendrobates and spectorclan need convince each other now 21:48:21 <spectorclan> zykes: We can contact them. Right now there is a CloudCamp that wants to be at Design Summit in May 21:48:33 <zykes-> CloudCamp ? 21:48:36 <ttx> feel free to continue the discussion on #openstack (or here if you really want to 21:48:37 <ttx> ) 21:48:43 <zykes-> ok 21:48:47 <spectorclan> i can stay here 21:49:04 <ttx> #endmeeting