Open Stack

What is the logic for that? It's a massive duplication of effort, and it
leads to defacto forks and inconsistencies between clouds - exactly what
the OpenStack mission is against.

Many/most of the clouds actually in production are already out of upstream
stable policy. The more convergence we can get on what happens after that
the better. There are zero advantages I can see to each vendor going it
alone.

On 22 Aug 2016 19:31, <Arkady_Kanevsky at dell.com> wrote:

> Sorry if touch 3rd rail.
>
> But should backport bug fixes to older releases be done in distros and not
> upstream?
>
> -----Original Message-----
> From: Walter A. Boring IV [mailto:walter.boring at hpe.com]
> Sent: Tuesday, August 09, 2016 12:34 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Cinder] [stable] [all] Changing stable
> policy for drivers
>
> On 08/08/2016 02:28 PM, Ihar Hrachyshka wrote:
> > Duncan Thomas wrote:
> >
> >> On 8 August 2016 at 21:12, Matthew Treinish
> >> wrote:
> >> Ignoring all that, this is also contrary to how we perform testing in
> >> OpenStack.
> >> We don't turn off entire classes of testing we have so we can land
> >> patches, that's just a recipe for disaster.
> >>
> >> But is it more of a disaster (for the consumers) than zero testing,
> >> zero review, scattered around the internet
> >> if-you're-lucky-with-a-good-wind you'll maybe get the right patch
> >> set? Because that's where we are right now, and vendors, distributors
> >> and the cinder core team are all saying it's a disaster.
> >
> > If consumers rely on upstream releases, then they are expected to
> > migrate to newer releases after EOL, not switch to a random branch on
> > the internet. If they rely on some commercial product, then they
> > usually have an extended period of support and certification for their
> > drivers, so it’s not a problem for them.
> >
> > Ihar
> This is entirely unrealistic. Force customers to upgrade. Good luck
> explaining to a bank that in order to get their cinder driver fix in, they
> have to upgrade their entire OpenStack deployment. Real world customers
> simply will balk at this all day long.
>
> Walt
> >
> > ______________________________________________________________________
> > ____
> >
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160822/78f814bb/attachment.html>