Open Stack

On Wed, 2021-12-08 at 19:04 +0100, Jean-Philippe Evrard wrote:
> Hello,
> 
> On Wed, Dec 8, 2021, at 13:44, Erno Kuvaja wrote:
> > Absolutely, as someone who needs to think both upstream and downstream aspects of the release and has cared a lot about stable maintenance of OpenStack for years, what you're proposing here is literally pushing all our stable maintenance work to downstream and not even trying to share the efforts with the rest of the community.
> 
> Not at all. I am fine with sharing the effort with the community. We just need to be "smarter" about the branching, and do the efforts right.
i dont nessisarly think our corrent branching is in anyway not smart.
> 
> > I also feel like this would turn really quickly to the point where if you're not following master on your deployment or using our product directly, I'd be happy to avice you to upgrade to the latest release and see if your problem still exists or go and talk to your deployment tool guys if they have seen the issue with whatever hashes they happen to deploy.
> 
> Let's be honest, when we are finding a bug, the first question we ask is "which version do you run", no? We don't ask for a branch, we ask for a SHA. Nothing changes there ;)
> 
> > I could have seen this as a tempting model 8-9 years ago when the competition was who is trailing master the closest and everyone was focusing on getting the next absolutely necessary feature set in to make OpenStack usable. Not now when we have matured considerably and are looking to provide stable production environments rather than rolling new code into production on a weekly basis. I'm not sure I even managed to grasp your proposal fully, but it really feels like half a step forward and mile, mile and half backwards.
> 
> I don't think it's ever a race to follow the latest master branch. It's never been for me at least.
> 
> For me it's about:
> - being smart about the definition of branching
> - forcing certain requirements on when branch, to be consistent in the community, WHILE bringing useful features for users
> - giving freedom to projects (of course while keeping consistency with the help of the TC).
for me creating a branch ahs alwasy been to state tha twe have forzen the feature set for a given releas andy you can integrate it into your product or produciton
with the expectation that it will only recive bug fixes goign forward.

unless we decide just to adopt a semver branching model i dont really see how what your propsoing will be benifical to consuming upstream release or prodcutising downstream
to me this woudl be a regression and make my life harder.


if we take a semver apprcoh and bump the major version only when backward incomaptable change are made and defience some suport boundary on when tha tis allowed then that might be
an alternive branchign stragy that could work but nova at least still recived enough feature reuqest that we may still need to bump the major version every 6 months.
with that said we did not make db schema change between train and wallaby so we have stablised some what compared to the early years where we had several in each release.
> 
> Being stable is fine.  In fact, it's the dream. Stable doesn't mean stale, however ;)
> 
> > > 
> > > I see people talking about changing releases for years now, I haven't seen a single change in our behaviour. (or maybe I missed something?). Is that stockholm syndrome? ;)
> > > 
> > I see this as a matter that handful few want to bring up every few months (for years now, we've had this discussion probably close to dozen times) and I have a feeling that the majority of the community is just tired of copypasting the same arguments every round to avoid breaking what works and genuinely is waiting for the thread being buried for the next few months so they can get back to work.
> 
> I feel the same. But instead of burying I would like to act.
> 
> Regards,
> JP