[all] Dangerous trend toward too many release-independent components
zigo at debian.org
Tue Sep 7 09:09:45 UTC 2021
As I'm packaging Xena in Debian, I've seen more and more components
switching to release-independent. This poses a number of problems which
I'm really unsure how to address. Let me explain.
First of all, once an OpenStack release reaches a distribution stable
release, there will be no update of it (ie: no new upstream release),
unless there's a security problems, or important bugfixes that cannot be
backported individually. At least, that's how Debian works, and why we
call our suite "stable" (ie: it doesn't change).
However, if a component is declared release-independent, the OpenStack
community expects it to be updated for all downward releases. But that's
not what's going on in reality. Also, if there's a security fix, we're
supposed to get this through an update of a new version, which may
include changes not suitable for a distribution update. The danger is
that the update may be refused by the Debian Stable release team, for
very good reasons (which I agree on).
I'm also questioning myself: since we have pinned global requirements,
will these new updates be included in the tests of older OpenStack
releases? Is this really the case right now?
So, while I do understand why it's nicer to set release-independent tags
on some components, it is my opinion that this doesn't help stability
and poses numerous problems to downstream distributions.
Could we limit the number of such release-independent released
components to the strict minimum low-profile (ie: with the least amount
of code) components, rather than constantly increasing the list?
Thomas Goirand (zigo)
More information about the openstack-discuss