[tc] [ironic] Promoting ironic to a top-level opendev project?
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
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)