[openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

Ihar Hrachyshka ihrachys at redhat.com
Wed Aug 10 08:54:53 UTC 2016


Jeremy Stanley <fungi at yuggoth.org> wrote:

> On 2016-08-09 15:56:57 -0700 (-0700), Mike Perez wrote:
>> As others have said and as being a Cinder stable core myself, the  
>> status-quo
>> and this proposal itself are terrible practices because there is no  
>> testing
>> behind it, thereby it not being up to the community QA standards set.
> [...]
>
> In fairness to Sean, this thread stared because he was asking in
> #openstack-infra for help creating some long-lived driver fix
> branches because he felt it was against stable branch policy to
> backport bugfixes for drivers. Since this was an unprecedented
> request, I recommended he first raise the topic on this list to find
> out if this is a common problem across other projects and whether
> stable branch policy should be revised to permit driver fixes.
>

I think if infrastructure feels ok to leave this branch that is *not* named  
as stable/* for a longer time, then it should be ok, since stable program  
does not maintain that branch.

> There was a brief discussion of what to do if the Cinder team wanted
> driver fixes to EOL stable series, and I still firmly believe effort
> there is better expended attempting to help extend stable branch
> support since "convenience to package maintainers" (what he said
> this plan was trying to solve) is the primary reason we provide
> those branches to begin with.
>
> So I guess what I'm asking: If stable branches exist as a place for
> package maintainers to collaborate on a common set of backported
> fixes, and are not actually usable to that end, why do we continue
> to provide them?

Those branches *are* usable, for as long as upstream stable program  
participants and infrastructure feels like they can deliver fixes with  
advertised quality standards. Once we feel that we cannot proceed doing it,  
we stop supporting any more bug fixes, irrelevant whether it’s for drivers  
or core code. At that time, it’s up to consumers (distributions, vendors)  
to come up with another out-of-upstream solution on the way forward.

Ihar



More information about the OpenStack-dev mailing list