[openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements
sigmavirus24 at gmail.com
Tue Apr 19 16:30:38 UTC 2016
From: Jeremy Stanley <fungi at yuggoth.org>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: April 19, 2016 at 09:50:27
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements
> On 2016-04-19 14:59:19 +0200 (+0200), Thomas Goirand wrote:
> > On 04/19/2016 01:01 PM, Chris Dent wrote:
> > > On Tue, 19 Apr 2016, Thomas Goirand wrote:
> > > > Most users are consuming packages from distributions. Also, if
> > > > you're using containers, probably you will also prefer using
> > > > these packages to build your containers: that's the most easy,
> > > > safe and fast way to build your containers.
> > >
> > > I predict that that is not going to last.
> > That's what everyone says, but I'm convinced the majority will be
> > proven wrong! :)
> Could just be that my beard has gotten a little too grey, but I
> still very much prefer using stabilized software packaged by
> traditional Linux distributions or similar Unix derivatives and
> covered under security patched backports. My hope has always been
> that as the rapid pace of development at the center of OpenStack
> starts to cool (and as the press moves on and OpenStack becomes a
> lot more boring to talk about), we'll approach the sort of ecosystem
> stabilization needed to make that less awkward downstream.
Perhaps my beard is not grey enough, but as a developer and maintainer of several of OpenStack's dependencies (some of which have needed security backports) I've argued with different downstream distributors about their own judgment of what portions of the patch to apply in order to fix an issue with an assigned CVE. It took much longer than should have been necessary in at least one of those cases where it did affect OpenStack, so perhaps I am too confident in my ability to use tooling outside of distribution provided packages but to date I've had better luck using the source with the *complete* fixes.
More information about the OpenStack-dev