Open Stack

Thomas Goirand wrote:
> 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?

Hi Thomas,

Those are all good points, and we will discuss them at the release team 
level.

For context, recently the release team has encouraged a number of stale 
components (stable libraries etc.) to move to release-independent since 
they were not even seeing one release per cycle. There was no point in 
forcing releases every cycle that were just changing the branch name in 
.gitreview.

Regards,

-- 
Thierry Carrez (ttx)