[openstack-dev] [tc] [all] OpenStack moving both too fast and too slow at the same time

Doug Hellmann doug at doughellmann.com
Mon May 8 22:10:33 UTC 2017

Excerpts from Jeremy Stanley's message of 2017-05-08 20:18:35 +0000:
> On 2017-05-08 11:24:00 -0600 (-0600), Octave J. Orgeron wrote:
> [...]
> > none of those products that those drivers are written for are open
> > sourced and they meet less resistance to committing code upstream.
> > So I have to call BS on your comment that the community can't work
> > with us because Solaris isn't open sourced.
> Totally not what I said.
> My point was that constantly reminding management of one of the
> primary sources of friction might help. Working with free software
> communities becomes easier when you don't outright reject their
> values by deciding to cancel your open version of the thing you want
> them to help you support.
> > Now for Oracle, we definitely need more 3rd party CI to make it
> > easier to test our drivers, components, and patches against so
> > that it's easier for the community to validate things. However, it
> > takes time, resources, and money to make that happen. Hopefully
> > that will get sorted out over time.
> And _this_ was entirely the rest of my point, yes. Your needs seem
> quite similar to to those of VMWare, XenServer and HyperV, so I
> fully expect Nova's core reviewers will hold Solaris support patches
> to the same validation requirements. We can't run Solaris in our
> upstream testing for the same reasons we can't run those other
> examples (they're not free software), so the onus is on the vendor
> to satisfy this need for continuous testing and reporting instead.
> > But even if we make all of the investments in setting that up, we
> > still need the upstream teams to come to the table and not shun us
> > away just because we are Oracle :)
> [...]
> Smiley or no, the assertion that our quality assurance choices are
> based on personal preference for some particular company over
> another is still mildly offensive.

Yes, let's keep in mind that the answer to these questions about
stable branches are and have been the same no matter who asked them.
Early in this thread we pointed out that this topic comes up
regularly, from different sources, and the answer remains the same:
Start by contributing to the existing stable maintenance, and either
improve the processes and tools to make it easier to do more and/or
recruit more people to spread the work around.


More information about the OpenStack-dev mailing list