Open Stack

Jean-Philippe Evrard wrote:
> On Sat, Dec 4, 2021, at 15:56, Thierry Carrez wrote:
>> Jean-Philippe Evrard wrote:
>>> [...]
>>> Here is what I read:
>>> 1) Many want more releases, not less. I haven't seen a complaint about tagging more releases.
>>> 2) More than one person is proposing to abandon the integrated release, and nobody has complained about it.
>>
>> Here are a few drawbacks of abandoning the integrated release (which is
>> really a "synchronized release"):
>>
>> - You would no longer have a baseline of components that are heavily
>> tested together which we do community QA on and (collectively) clearly
>> sign off on, so downstream integrators are on their own and have much
>> more work to do
> 
> I don't think so. We can still have that without the synchronized release. We decide what we test together.
> (Maybe the TC can define that?). For example, with Zuul, we can test the master branch of all projects together to ensure the latest branch always work according to the set criteria. (No change there!)
> 
> Then, what becomes "openstack version x" is just about a manifest of the SHAs or the tags of the projects, tested together. (No change again). (Let's call this proposition 1)

I'm still wrapping my head around your proposal... It appears you want 
to drop the "stable branch" part of the release rather than the regular 
tagging and tracking of what has been tested together (the "integrated 
release").

It definitely sounds possible to me to:
- have all components use an intermediary-released model (release as 
needed, no common feature freeze, no RCs)
- have regular points in time where we communicate combinations of 
components that work together
- not create stable branches for those components, not backport any 
bugfix and just roll forward (single branch development)

Then you would still have a comparison baseline ("I run X"), and you 
would still have "openstack releases" that you can communicate and 
generate excitement around. And it would definitely reduce the 
backporting work happening upstream.

However I am not sure I see how that proposal solves the upgrade 
pressure, or make downstream distribution work any easier... which are 
the two major reasons people ask for a longer cycle in the current 
system. If anything, that would make both worse, no?

-- 
Thierry Carrez (ttx)