Jeremy Stanley <fu...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
