21:00:54 #startmeeting 21:00:55 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 21:01:09 Welcome to the first Cactus weekly OpenStack team meeting... 21:01:11 ttx: I deliver. 21:01:22 Today's agenda is at: 21:01:28 #link http://wiki.openstack.org/Meetings 21:01:45 No last-minute addition apparently 21:01:48 No actions from last week meeting 21:02:02 #topic Nova Bexar post release issues 21:02:21 We realized after release that the tarballs have (always) been missing some elements. 21:02:29 #link https://bugs.launchpad.net/nova/+bugs?field.tag=bexar-post-release 21:02:43 The released tarball is most notably missing some extra files and directories, and the translated strings. 21:02:55 We should release a new tarball including the missing elements. 21:03:58 I just want to be sure that we only have to that once. 21:04:34 how can you be sure? 21:04:35 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 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 Option B is to create a new milestone (2011.1.1) and release nova-2011.1.1.tar.gz there 21:04:50 Thoughts ? 21:04:50 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 dendrobates: you're for option B, right 21:04:51 Anyone from Nova core with an opinion on this ? 21:04:54 It's not that hard. Clearly. It was noticed afterwards. 21:05:01 tyes 21:05:04 yes 21:05:09 I've been working on the missing files, jaypipes is working on the missing translations 21:05:31 my outsider's view is that B is better as it will make people realize something changed 21:05:34 that is the most honest and least confusing thing to do, IMO 21:05:39 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 B seems much cleaner to me 21:05:50 I'm also in favour of B. 21:05:52 soren: the process creating the tarball could simply check against a file list 21:05:58 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 soren: you wanted to add a test to catch differences between branch and tarball ? 21:06:19 ttx: Yeah. 21:06:23 it's mostly done. 21:06:38 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 ok, option B it is, then 21:06:41 It'll shout and scream until someone fixes it or acknowledges the change. 21:06:55 soren: :) 21:06:57 dendrobates: I wouldn't have checked that even if I was at 100% :) 21:07:15 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 ttx: I would have gone through it with you. 21:07:28 I wrongly assumed that the tarball generation was using bzr export 21:07:38 and not python setup.py sdist 21:07:41 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 Why is it that big of a deal to just make a bugfix release? 21:08:03 creiht: I think that is the decision 21:08:10 creiht: not a big deal. Option B it is 21:08:14 moving on 21:08:17 lol 21:08:19 creiht: and I don;t know why some resist it 21:08:28 * ttx shuts up now :) 21:08:31 #topic Current release stage: Development 21:08:44 Welcome to Cactus ! You can find the release schedule at: 21:08:45 Option B from my perspective 21:08:50 #link http://wiki.openstack.org/CactusReleaseSchedule 21:08:58 This is a short cycle with 7 weeks in the merge window. 21:09:06 (no design summit) 21:09:17 Feel free to propose any branch for merging until BranchMergeProposalFreeze, currently set to March 17. 21:09:27 Remember the sooner branches are proposed, the better. 21:09:50 any major changes should be proposed in the first 4 weeks 21:09:53 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 We've still got blueprints pending approval. What's the status of those? 21:10:31 ewanmellor: coming to it 21:10:37 #topic Cactus targets 21:10:42 * ttx passes the mike to dendrobates 21:11:00 So... 21:11:18 ttx and I were suposed to review and approve all blueprints last week 21:11:31 ... in Brussels 21:11:37 but illness and injury prevented that. 21:11:52 so we started going through them today. 21:12:24 we are first accepting them to the cactus release and then we will review the specs 21:12:35 do we have any plan for backporting fixes? 21:12:56 vishy: to Bexar ? 21:12:59 do not let spec approval delay your coding if your bp has been accepted 21:13:18 vishy: we will be discussing that in the POC meeting 21:13:18 i'm confused on whose job it is to approve blueprints 21:13:50 dendrobates: are you distinguishing between approval of the blueprint and approval of the spec? 21:13:58 Unfortunately there are no letters between B and C, so there can't be an intermediate release >:) 21:14:02 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 devcamcar: I'm not 21:14:17 ttx: yes to Bexar, there is one pretty nasty bug which made it in 21:14:29 vishy: link? 21:14:36 ewanmellor: no, between acceptance into the release and bp approval 21:14:54 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 which is not clear 21:15:06 https://bugs.launchpad.net/nova/+bug/713430 21:15:08 ttx helps me go through them 21:15:12 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 and has to track them 21:15:20 devcamcar: agreed. I think he meant he is accepting them whie I present the list to him 21:15:29 thanks, just wanted to clarify 21:15:34 dendrobates: So a blueprint can be "accepted into Cactus" but not actually approved as a specification? What does that mean? 21:16:04 soren: not what i was saying 21:16:08 ewanmellor: that means that we plan on the feature being included in Cactus, but... 21:16:14 devcamcar: ok 21:16:28 soren: just wanted to clarify roles so i understand 21:16:34 we have not completed a design review. 21:16:53 vishy: that's a good candidate indeed. Maybe we could squeeze it into a 2011.1.1 21:17:04 with the short cycle, don't we run the risk of bp/specs not being approved? 21:17:07 vishy: i would suggest fixing bug 713430 in the maintenance release 2011.1.1 (plan b) 21:17:15 it doesn't leave us much time for alternate plans 21:17:25 dendrobates: OK, makes sense. 21:17:39 pvo: I will finish this week 21:17:40 when/where is the design review for cactus? 21:17:47 but that brings up another issue 21:17:58 vishy: we won't rush 2011.1.1, so there is time to consider it. 21:18:18 we have more bp's proposed than we can accomplish in this short release 21:18:36 especially considering the focus on testing and stabilzation 21:19:31 if it is not imperative for your feature to hit in Cactus, please withdraw it and repropose for diablo 21:20:13 dendrobates: you're talking about Nova, right 21:20:19 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 yes 21:20:44 ewanmellor: yes that would be helpful 21:20:52 We have 30 specs proposed In Cactus for Nova, against 33 actually implemented in Bexar 21:20:58 Bexar had one more week 21:21:05 (and wasn't focused on stability) 21:21:38 That said the "number" of specs is not the important factor 21:22:10 I'd rather keep two small self-contained features and drop one disruptive refactoring spec 21:22:40 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 That should be a part of the BP ... how disruptive is it? 21:23:38 during this release, btw, 2 or more of our most productive devs will be focused on testing 21:23:52 so we will get far fewer bps done. 21:24:28 that's enough from me 21:24:38 ok 21:24:39 are there many unassigned BPs or BPs assigned to those devs? 21:24:49 westmaas: no 21:25:07 there is no "unassigned BP" since you basically sign up for doing iy when you file it 21:25:26 though that does not always happen 21:25:42 we have picked up orphaned bp's 21:25:53 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 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 or what you can hold off merging until April 21:27:28 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 Disruptive changes that land late, on the other hand... 21:27:58 ok, moving on in 10 seconds 21:28:12 SIGALRM 21:28:23 :) 21:28:30 #topic Documentation priorities for Cactus 21:28:37 annegentle: Floor is yours 21:28:40 thanks 21:29:02 I've been getting mixed messages about the docs - either they're really crap or they're teh awesome :) 21:29:30 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 I am also getting feedback requests for top priority: OpenStack API docs for Compute. Sound right? 21:30:37 from who? 21:30:39 Secondary items on the list include - reference info for flags, more images. 21:30:55 dendrobates: today's twitter feed for #OpenStack 21:31:04 honestly, most of the feedback has been overwhelmingly positive 21:31:13 but I do know that we have a ways to go 21:31:15 I just wondered if it's client devs 21:31:28 I think you've done great 21:31:30 dendrobates: yeah I want to find out who is underserved. 21:31:53 I still need a process for translating docs. Right now, the best I have is "use the wiki" 21:32:11 that said I like jaypipes suggestion that a new feature should come with a doc patch 21:32:14 I also wanted to check with this group on a priority to "eliminate redundancy" 21:32:27 ttx: agree with that one! 21:33:02 redundancy causes problems when one place gets maintained and the other does not 21:33:09 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 dendrobates: exactly. I now have 3 places to update multinode Nova install, for example. 21:34:15 Yikes. 21:34:16 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 and keep alternate methods for the wiki 21:34:41 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 We could do a "Choose your own adventure" style install doc :) 21:34:58 It needs to be clear what is official documentation and what is not 21:35:11 For 4) collaboration and single sourcing I need specific help 21:35:28 I don't have a "trunk" for official doc yet in the openstack-devel project 21:35:35 for example. That'll help me with collab and single-sourcing 21:35:53 which will help with 1) API doc 21:35:59 annegentle: do you want help setting that up? 21:36:02 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 ttx: alternate methods on the wiki works for me 21:36:25 ewanmellor: I believe that was the idea for API docs. 21:36:49 soren: OK, then the devs can do that, can't we? 21:37:05 ewanmellor: I actually thought xtoddx had already looked into this. 21:37:15 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 annegentle: we need some official documentation for glance as well 21:37:22 heh, the only page I use: http://wiki.openstack.org/XenServerDevelopment 21:37:43 sandywalsh_: that's because you're so narrow-minded :P 21:37:54 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 i agree its work for developers... doc writer might have problem understanding the problem.. developer has needed knowledge 21:38:18 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 ttx: no feature without docs and no bugfix without unit test is always a good plan 21:38:48 +1 21:38:51 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 yes on the "no feature with out docs" I'd go as far to say "no approval/merge without docs" 21:39:32 "feature" is hard to define 21:39:33 :) 21:39:44 annegentle: that's how you enforce it, right :) 21:39:50 ok I can barely type fast enough to ensure I get priorities out to you all. 21:39:52 annegentle: yah, better wording 21:40:20 annegentle: maybe summarize the plan on the ML for further discussion ? 21:40:27 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 ttx: yep, will do. Thanks all for the input. 21:41:09 ok, moving on then... 21:41:15 #topic Open discussion 21:41:31 I posted an ML thread about Bexar postmortem feedback, don't hesitate to answer, publicly or privately, I need your feedback :) 21:42:08 my feedback is that the Release manager should not get sick at release time 21:42:16 +1 on that 21:42:43 It's been two weeks and I still can't breathe normally. 21:42:56 thats hard to achive with certainty.... healthy food is best bet... 21:43:19 I think spectorclan is missing presentations for the OpenStack conference technical track, but he isn't around to ask for them 21:43:48 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 RichiH: are you talking about object storage? 21:44:34 if so -> http://swift.openstack.org/development_saio.html 21:44:39 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 That installs a dev cluster on one machine 21:45:29 also on Bexar postmortem, if you created a Blueprint, fill out the emailed survey about Blueprints from Stephen Spector. 21:46:11 ok, on those good words, we'll close for today 21:46:29 #endmeeting