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