21:00:54 <ttx> #startmeeting
21:00:55 <openstack> Meeting started Tue Feb  8 21:00:54 2011 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:01:09 <ttx> Welcome to the first Cactus weekly OpenStack team meeting...
21:01:11 <soren> ttx: I deliver.
21:01:22 <ttx> Today's agenda is at:
21:01:28 <ttx> #link http://wiki.openstack.org/Meetings
21:01:45 <ttx> No last-minute addition apparently
21:01:48 <ttx> No actions from last week meeting
21:02:02 <ttx> #topic Nova Bexar post release issues
21:02:21 <ttx> We realized after release that the tarballs have (always) been missing some elements.
21:02:29 <ttx> #link https://bugs.launchpad.net/nova/+bugs?field.tag=bexar-post-release
21:02:43 <ttx> The released tarball is most notably missing some extra files and directories, and the translated strings.
21:02:55 <ttx> We should release a new tarball including the missing elements.
21:03:58 <soren> I just want to be sure that we only have to that once.
21:04:34 <dendrobates> how can you be sure?
21:04:35 <soren> Once is bad enough. If there's something people want in the tarball, it would be totally awesome if they would check that it was actually there. Just once. Ever.
21:04:49 <ttx> Option A is to release a new tarball (nova-2011.1-full.tar.gz) on https://launchpad.net/nova/+milestone/2011.1
21:04:50 <ttx> Option B is to create a new milestone (2011.1.1) and release nova-2011.1.1.tar.gz there
21:04:50 <ttx> Thoughts ?
21:04:50 <ttx> Advantage of option A is that it makes it clear it's just missing files that were added, nothing else changed. Advantage of option B is that it clearly acknowledges the tarball fumble and encourages people to switch to the complete one.
21:04:50 <ttx> dendrobates: you're for option B, right
21:04:51 <ttx> Anyone from Nova core with an opinion on this ?
21:04:54 <soren> It's not that hard. Clearly. It was noticed afterwards.
21:05:01 <dendrobates> tyes
21:05:04 <dendrobates> yes
21:05:09 <ttx> I've been working on the missing files, jaypipes is working on the missing translations
21:05:31 <RichiH> my outsider's view is that B is better as it will make people realize something changed
21:05:34 <dendrobates> that is the most honest and least confusing thing to do, IMO
21:05:39 <ttx> We should also make sure that doesn't happen again. I mistakenly thought that our tarball generation included all files, and that translations were automatically merged, so I admit not having double-checked that.
21:05:43 <dabo> B seems much cleaner to me
21:05:50 <soren> I'm also in favour of B.
21:05:52 <RichiH> soren: the process creating the tarball could simply check against a file list
21:05:58 <ttx> When we add a new file we need to make sure it's properly covered in setup.py or MANIFEST.in if needed.
21:06:06 <ttx> soren: you wanted to add a test to catch differences between branch and tarball ?
21:06:19 <soren> ttx: Yeah.
21:06:23 <soren> it's mostly done.
21:06:38 <dendrobates> to be fair, ttx was very ill on release, and I hit my head and ended up in the hospital.  Last release I checked the file and the manifest
21:06:38 <ttx> ok, option B it is, then
21:06:41 <soren> It'll shout and scream until someone fixes it or acknowledges the change.
21:06:55 <dendrobates> soren: :)
21:06:57 <ttx> dendrobates: I wouldn't have checked that even if I was at 100% :)
21:07:15 <soren> RichiH: It doesn't help if noone bothers to make sure said file list is complete. The manifest basically is this file list.
21:07:18 <dendrobates> ttx: I would have gone through it with you.
21:07:28 <ttx> I wrongly assumed that the tarball generation was using bzr export
21:07:38 <ttx> and not python setup.py sdist
21:07:41 <diegoparrilla> A suggestion from an outsider: once a tarball is released any change can make confusion. It's better to create a 'maintenance' release
21:07:43 <creiht> Why is it that big of a deal to just make a bugfix release?
21:08:03 <dendrobates> creiht: I think that is the decision
21:08:10 <ttx> creiht: not a big deal. Option B it is
21:08:14 <ttx> moving on
21:08:17 <creiht> lol
21:08:19 <dendrobates> creiht: and I don;t know why some resist it
21:08:28 * ttx shuts up now :)
21:08:31 <ttx> #topic Current release stage: Development
21:08:44 <ttx> Welcome to Cactus ! You can find the release schedule at:
21:08:45 <diegoparrilla> Option B from my perspective
21:08:50 <ttx> #link http://wiki.openstack.org/CactusReleaseSchedule
21:08:58 <ttx> This is a short cycle with 7 weeks in the merge window.
21:09:06 <ttx> (no design summit)
21:09:17 <ttx> Feel free to propose any branch for merging until BranchMergeProposalFreeze, currently set to March 17.
21:09:27 <ttx> Remember the sooner branches are proposed, the better.
21:09:50 <dendrobates> any major changes should be proposed in the first 4 weeks
21:09:53 <soren> Also remember that proposing a branch by MArch 17 doesn't mean it'll get merged. It means it'll get reviewed.
21:10:23 <ewanmellor> We've still got blueprints pending approval.  What's the status of those?
21:10:31 <ttx> ewanmellor: coming to it
21:10:37 <ttx> #topic Cactus targets
21:10:42 * ttx passes the mike to dendrobates
21:11:00 <dendrobates> So...
21:11:18 <dendrobates> ttx and I were suposed to review and approve all blueprints last week
21:11:31 <ttx> ... in Brussels
21:11:37 <dendrobates> but illness and injury prevented that.
21:11:52 <dendrobates> so we started going through them today.
21:12:24 <dendrobates> we are first accepting them to the cactus release and then we will review the specs
21:12:35 <vishy> do we have any plan for backporting fixes?
21:12:56 <ttx> vishy: to Bexar ?
21:12:59 <dendrobates> do not let spec approval delay your coding if your bp has been accepted
21:13:18 <dendrobates> vishy: we will be discussing that in the POC meeting
21:13:18 <devcamcar> i'm confused on whose job it is to approve blueprints
21:13:50 <ewanmellor> dendrobates: are you distinguishing between approval of the blueprint and approval of the spec?
21:13:58 <creiht> Unfortunately there are no letters between B and C, so there can't be an intermediate release >:)
21:14:02 <devcamcar> ttx is a release manager, correct? it seems that if he is in charge of approving blueprints, then that bypasses all of the governance structures
21:14:13 <ttx> devcamcar: I'm not
21:14:17 <vishy> ttx: yes to Bexar, there is one pretty nasty bug which made it in
21:14:29 <ttx> vishy: link?
21:14:36 <dendrobates> ewanmellor: no, between acceptance into the release and bp approval
21:14:54 <devcamcar> ttx: thats what i thought, but dendrobates just said "member:ttx and I were suposed to review and approve all blueprints last week"
21:15:00 <devcamcar> which is not clear
21:15:06 <vishy> https://bugs.launchpad.net/nova/+bug/713430
21:15:08 <dendrobates> ttx helps me go through them
21:15:12 <soren> devcamcar: Just because we have a structure with various boards and whatnot doesn't mean that noone else can make a decision about anything at all. That would grind the project to a halt.
21:15:14 <dendrobates> and has to track them
21:15:20 <ttx> devcamcar: agreed. I think he meant he is accepting them whie I present the list to him
21:15:29 <devcamcar> thanks, just wanted to clarify
21:15:34 <ewanmellor> dendrobates: So a blueprint can be "accepted into Cactus" but not actually approved as a specification?  What does that mean?
21:16:04 <devcamcar> soren: not what i was saying
21:16:08 <dendrobates> ewanmellor: that means that we plan on the feature being included in Cactus, but...
21:16:14 <soren> devcamcar: ok
21:16:28 <devcamcar> soren: just wanted to clarify roles so i understand
21:16:34 <dendrobates> we have not completed a design review.
21:16:53 <ttx> vishy: that's a good candidate indeed. Maybe we could squeeze it into a 2011.1.1
21:17:04 <pvo> with the short cycle, don't we run the risk of bp/specs not being approved?
21:17:07 <berendt> vishy: i would suggest fixing bug 713430 in the maintenance release 2011.1.1 (plan b)
21:17:15 <pvo> it doesn't leave us much time for alternate plans
21:17:25 <ewanmellor> dendrobates: OK, makes sense.
21:17:39 <dendrobates> pvo:  I will finish this week
21:17:40 <pvo> when/where is the design review for cactus?
21:17:47 <dendrobates> but that brings up another issue
21:17:58 <ttx> vishy: we won't rush 2011.1.1, so there is time to consider it.
21:18:18 <dendrobates> we have more bp's proposed than we can accomplish in this short release
21:18:36 <dendrobates> especially considering the focus on testing and stabilzation
21:19:31 <dendrobates> if it is not imperative for your feature to hit in Cactus, please withdraw it and repropose for diablo
21:20:13 <ttx> dendrobates: you're talking about Nova, right
21:20:19 <ewanmellor> dendrobates: Would it help if people estimated their own blueprints for instability risk and likely branch proposal date?  We could put this in the Whiteboard.  Low risk branches that will be ready before BMPF would be preferred, obviously.
21:20:20 <dendrobates> yes
21:20:44 <dendrobates> ewanmellor: yes that would be helpful
21:20:52 <ttx> We have 30 specs proposed In Cactus for Nova, against 33 actually implemented in Bexar
21:20:58 <ttx> Bexar had one more week
21:21:05 <ttx> (and wasn't focused on stability)
21:21:38 <ttx> That said the "number" of specs is not the important factor
21:22:10 <ttx> I'd rather keep two small self-contained features and drop one disruptive refactoring spec
21:22:40 <dendrobates> true, we really want to improve the qa process during this release, my main fear is that if we accept too many features we will lose sight of that in the rush to push features
21:22:42 <sandywalsh_> That should be a part of the BP ... how disruptive is it?
21:23:38 <dendrobates> during this release, btw, 2 or more of our most productive devs will be focused on testing
21:23:52 <dendrobates> so we will get far fewer bps done.
21:24:28 <dendrobates> that's enough from me
21:24:38 <ttx> ok
21:24:39 <westmaas> are there many unassigned BPs or BPs assigned to those devs?
21:24:49 <ttx> westmaas: no
21:25:07 <ttx> there is no "unassigned BP" since you basically sign up for doing iy when you file it
21:25:26 <dendrobates> though that does not always happen
21:25:42 <dendrobates> we have picked up orphaned bp's
21:25:53 <ttx> each group should just have a realistic look at what they can deliver in the timeframe we have... and withdraw what they can't do
21:26:32 <ttx> and in parallel dendrobates can try to weed out the most disruptive stuff, for the sake of the stability of the release
21:26:33 <dendrobates> or what you can hold off merging until April
21:27:28 <ttx> I don't really mind if some targeted stuff ends up not being delivered. That's overconfidence for the group that proposed it, but it doesn't derail the release
21:27:44 <ttx> Disruptive changes that land late, on the other hand...
21:27:58 <ttx> ok, moving on in 10 seconds
21:28:12 <soren> SIGALRM
21:28:23 <dendrobates> :)
21:28:30 <ttx> #topic Documentation priorities for Cactus
21:28:37 <ttx> annegentle: Floor is yours
21:28:40 <annegentle> thanks
21:29:02 <annegentle> I've been getting mixed messages about the docs - either they're really crap or they're teh awesome :)
21:29:30 <annegentle> I think this means that there are distinct audiences and there's wayy too much redundant info, plus sites are not laser targeted to DEV or USER
21:30:01 <annegentle> I am also getting feedback requests for top priority: OpenStack API docs for Compute. Sound right?
21:30:37 <dendrobates> from who?
21:30:39 <annegentle> Secondary items on the list include - reference info for flags, more images.
21:30:55 <annegentle> dendrobates: today's twitter feed for #OpenStack
21:31:04 <annegentle> honestly, most of the feedback has been overwhelmingly positive
21:31:13 <annegentle> but I do know that we have a ways to go
21:31:15 <dendrobates> I just wondered if it's client devs
21:31:28 <dendrobates> I think you've done great
21:31:30 <annegentle> dendrobates: yeah I want to find out who is underserved.
21:31:53 <annegentle> I still need a process for translating docs. Right now, the best I have is "use the wiki"
21:32:11 <ttx> that said I like jaypipes suggestion that a new feature should come with a doc patch
21:32:14 <annegentle> I also wanted to check with this group on a priority to "eliminate redundancy"
21:32:27 <annegentle> ttx: agree with that one!
21:33:02 <dendrobates> redundancy causes problems when one place gets maintained and the other does not
21:33:09 <annegentle> However, the redundancy is something introduced by not using RST as source for docs.openstack.org. I'd like to use RST > DocBook but need some dev help to do so.
21:33:28 <annegentle> dendrobates: exactly. I now have 3 places to update multinode Nova install, for example.
21:34:15 <soren> Yikes.
21:34:16 <ttx> annegentle: I think in some cases (install instructions) we'll need to make some opinated choices rather than present 4 alternate methods
21:34:28 <ttx> and keep alternate methods for the wiki
21:34:41 <annegentle> I believe my priorities for Cactus are 1) API doc 2) reference info 3) images but I need to move 4) collaboration and single-sourcing into a higher position.
21:34:44 <soren> We could do a "Choose your own adventure" style install doc :)
21:34:58 <dendrobates> It needs to be clear what is official documentation and what is not
21:35:11 <annegentle> For 4) collaboration and single sourcing I need specific help
21:35:28 <annegentle> I don't have a "trunk" for official doc yet in the openstack-devel project
21:35:35 <annegentle> for example. That'll help me with collab and single-sourcing
21:35:53 <annegentle> which will help with 1) API doc
21:35:59 <dendrobates> annegentle: do you want help setting that up?
21:36:02 <ewanmellor> Could we not autogenerate an API doc from doc-comments?  It sounds like a waste of a skilled doc writer writing API definitions.
21:36:12 <annegentle> ttx: alternate methods on the wiki works for me
21:36:25 <soren> ewanmellor: I believe that was the idea for API docs.
21:36:49 <ewanmellor> soren: OK, then the devs can do that, can't we?
21:37:05 <soren> ewanmellor: I actually thought xtoddx had already looked into this.
21:37:15 <westmaas> one of the devs here in blacksburg did some work on a sphinx plugin to autogenerate REST api docs with supporting URI examples, let me know if that could be useful
21:37:16 <devcamcar> annegentle: we need some official documentation for glance as well
21:37:22 <sandywalsh_> heh, the only page I use: http://wiki.openstack.org/XenServerDevelopment
21:37:43 <ttx> sandywalsh_: that's because you're so narrow-minded :P
21:37:54 <annegentle> ewanmellor: yep, though there's 2 approaches I suppose - does the RST source already contain API docs? Is it possible to source all of it from RST?
21:37:59 * sandywalsh_ nods
21:38:02 <alekibango> i agree its work for developers...   doc writer might have problem understanding the problem.. developer has needed knowledge
21:38:18 <annegentle> Ah yes, Glance is also a priority. I have 2 chapters written and just haven't included them in the builds until I get more end-user install info.
21:38:37 <RichiH> ttx: no feature without docs and no bugfix without unit test is always a good plan
21:38:48 <alekibango> +1
21:38:51 <annegentle> one idea Mike Mayo and Josh Kearney floated for API docs is to set up a web server you can send curl commands to
21:39:20 <annegentle> yes on the "no feature with out docs" I'd go as far to say "no approval/merge without docs"
21:39:32 <annegentle> "feature" is hard to define
21:39:33 <annegentle> :)
21:39:44 <ttx> annegentle: that's how you enforce it, right :)
21:39:50 <annegentle> ok I can barely type fast enough to ensure I get priorities out to you all.
21:39:52 <RichiH> annegentle: yah, better wording
21:40:20 <ttx> annegentle: maybe summarize the plan on the ML for further discussion ?
21:40:27 <annegentle> I do think I have a good idea that my next 7 weeks are going to be spent on reference docs - API and flags. Plus rounding out the Glance doc.
21:40:39 <annegentle> ttx: yep, will do. Thanks all for the input.
21:41:09 <ttx> ok, moving on then...
21:41:15 <ttx> #topic Open discussion
21:41:31 <ttx> I posted an ML thread about Bexar postmortem feedback, don't hesitate to answer, publicly or privately, I need your feedback :)
21:42:08 <dendrobates> my feedback is that the Release manager should not get sick at release time
21:42:16 <ttx> +1 on that
21:42:43 <ttx> It's been two weeks and I still can't breathe normally.
21:42:56 <alekibango> thats hard to achive with certainty....    healthy food is best bet...
21:43:19 <ttx> I think spectorclan is missing presentations for the OpenStack conference technical track, but he isn't around to ask for them
21:43:48 <RichiH> soren mentioned that OS has mainly been tested with triple copies of everything which makes playing with it on just a few boxes harder/impossible -- it would be nice if there was a test mode that supported, and is tested, with fewer copies
21:44:19 <creiht> RichiH: are you talking about object storage?
21:44:34 <creiht> if so -> http://swift.openstack.org/development_saio.html
21:44:39 <ewanmellor> I have updated the network-service blueprint with some goals for NaaS for Diablo.  Don't hesitate to give me feedback on those. I'll be adding some more detailed design once I've got through the older specs and the feedback that I've received so far.
21:45:06 <creiht> That installs a dev cluster on one machine
21:45:29 <annegentle> also on Bexar postmortem, if you created a Blueprint, fill out the emailed survey about Blueprints from Stephen Spector.
21:46:11 <ttx> ok, on those good words, we'll close for today
21:46:29 <ttx> #endmeeting