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)