Open Stack

Dmitry Tantsur wrote:
> [...]
> TL;DR I’m proposing to make Ironic a top-level project under opendev.org 
> <http://opendev.org> and the OpenStack Foundation, following the same 
> model as Zuul. I don’t propose severing current relationships with other 
> OpenStack projects, nor making substantial changes in how the project is 
> operated.
> [...]

I agree that in the current situation, you have to explain that 
OpenStack is a collection of tools and it's OK if you install just one, 
while a lot of people assume "OpenStack" means "lots of services". So I 
think I understand the problem you're trying to solve.

The main risk I see here is the slippery slope. Other OpenStack projects 
can be run standalone (Cinder, Swift...), so under that same reason 
could also move to be their own top-level project. At which point we end 
up with a collection of projects under the OSF, very much like we 
currently have a collection of projects under the TC. The only 
difference will be that the integration between the various components 
(currently the role of the TC) will no longer be under the 
responsibility of anyone. I'm not really sure that with less 
integration, we'll be collectively better off as a result.

So I think we need to dig deeper in the strategy for Ironic, the 
adoption obstacles we are trying to remove, and discuss the options. 
Being set up as a separate top-level project is one option. But I feel 
like changing governance (i.e. no longer be under the TC) has a lot less 
impact to change the perception than, say, creating a separate ironic 
product website that explains Ironic completely outside of the OpenStack 
context (which we could do without changing governance).

The release management issue is, I think, mostly a red herring. As swift 
has proven in the past, you can totally have a product strategy with the 
cycle-with-intermediary model. You can even maintain your own extra 
branches (think stable/2.0) if you want. The only extra limitations 
AFAIK in the integrated release are that (1) you also maintain stable 
branches at openstack common release points (like stable/train), and (2) 
that the openstack release management team has an opportunity to check 
the release numbering for semver sanity.

-- 
Thierry Carrez (ttx)