On Apr 13, 2014, at 11:58 PM, Michael Still <mi...@stillhq.com> wrote:
> First off, thanks for electing me as the Nova PTL for Juno. I find the > outcome of the election both flattering and daunting. I'd like to > thank Dan and John for running as PTL candidates as well -- I strongly > believe that a solid democratic process is part of what makes > OpenStack so successful, and that isn't possible without people being > will to stand up during the election cycle. Congrats! > > I'm hoping to send out regular emails to this list with my thoughts > about our current position in the release process. Its early in the > cycle, so the ideas here aren't fully formed yet -- however I'd rather > get feedback early and often, in case I'm off on the wrong path. What > am I thinking about at the moment? The following things: > > * a mid cycle meetup. I think the Icehouse meetup was a great success, > and I'd like to see us do this again in Juno. I'd also like to get the > location and venue nailed down as early as possible, so that people > who have complex travel approval processes have a chance to get travel > sorted out. I think its pretty much a foregone conclusion this meetup > will be somewhere in the continental US. If you're interested in > hosting a meetup in approximately August, please mail me privately so > we can chat. Yeah this was a great opportunity to collaborate and keep the project pointed in the right direction during Icehouse. > > * specs review. The new blueprint process is a work of genius, and I > think its already working better than what we've had in previous > releases. However, there are a lot of blueprints there in review, and > we need to focus on making sure these get looked at sooner rather than > later. I'd especially like to encourage operators to take a look at > blueprints relevant to their interests. Phil Day from HP has been > doing a really good job at this, and I'd like to see more of it. I have mixed feelings about the nova-specs repo. I dig the open collaboration of the blueprints process, but I also think there is a danger of getting too process-oriented here. Are these design documents expected to call out every detail of a feature? Ideally, I’d like to see only very high level documentation in the specs repo. Basically, the spec could include just enough detail for people to agree that they think a feature is worth inclusion. More detailed discussion could remain on the code reviews since they are the actual end work product. Thanks, Brian _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
