Open Stack

On Apr 13, 2014, at 11:58 PM, Michael Still <mikal at 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