On Apr 13, 2020, at 4:50 PM, Julia Kreger <juliaashleykreger@gmail.com> wrote:

On Thu, Apr 9, 2020 at 11:27 AM Doug Hellmann <doug@doughellmann.com> wrote:

On Apr 9, 2020, at 1:24 PM, Jeremy Stanley <fungi@yuggoth.org> wrote:

On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:

On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@yuggoth.org> wrote:

[...]

Why *can't* OpenShift include OpenStack projects? I haven't seen
this adequately explained.

It's less of a technical issue, but more of misunderstanding that
including an OpenStack project does not involve literally
installing OpenStack. And no matter what we think, for a lot of
people OpenStack==Nova (another marketing issue to address?).

[...]

I don't understand why that would make a difference in this case,
unless you're saying that the people who make architectural
decisions about what's included in OpenShift have no actual
familiarity with Ironic and OpenStack. If you know anyone who works
at that company, can you help them understand the difference?

This part of the argument has completely lost me. OpenShift 4 already includes Ironic. I’m not aware of any challenges that arose while making that happen that would have been solved or even made easier by Ironic being its own OIP.

I'm sure one time challenges would have been greater initially, but
ongoing headaches would be less IMHO. All headaches there are a result
of how people want to do their jobs and achieve/interpret goals with
perceptions while trying to match that up to policy and procedural
frameworks. In essence, without further delineation, it is an uphill
battle that focuses on finding the string "OpenStack" and directing it
to that process.

That may be true, but those problems are internal to Red Hat, aren’t they?

On one hand, large distributions want us to have stable branches
every year or two. Even what we have is too much.

On the other - we have small consumers who could benefit from just
pulling the latest(ish) release and knowing that if a serous bug
is found there, they won't have to update to the next feature (and
potentially major) release.

[...]

This sounds like a problem shared by, well, basically every other
project in OpenStack too. Perhaps it's an opportunity to collaborate
on finding solutions.
--
Jeremy Stanley