Open Stack

On Tue, 7 Apr 2020 at 10:41, Thierry Carrez <thierry at openstack.org> wrote:
>
> Sean McGinnis wrote:
> >>>> Thanks for the detailed response Sean. I don't have an issue with the
> >>>> cycle model - Ironic is still tied to the cyclical release model. The
> >>>> part that I disagree with is the requirement to create an intermediary
> >>>> release. It shouldn't be a problem if bifrost doesn't make a feature
> >>>> release between Train and Ussuri, we'll just do a final Ussuri
> >>>> release. It's the intermediary I'd like to be optional, rather than
> >>>> the final cycle release.
> >>>>
> >>> I would suggest switching these to cycle-with-rc then. There is one
> >>> release candidate that has to happen just before the final release for
> >>> the cycle, but that's mainly to make sure everything is in good shape
> >>> before we declare it done. That sounds like it might fit better with
> >>> what the team wants to do here.
> >> But what if we want to create a feature release mid-cycle? Some cycles
> >> we do, some we don't.
> >>
> > With cycle-with-rc, that does allow *beta* releases to be done at any
> > point during the cycle. But those would be marked as b1, b2, etc.
> > releases. This allows those that want to try out upcoming features to
> > grab them if they want them, but would prevent anyone else from
> > accidentally picking up something before it is quite ready.
> >
> > I'm guessing this might not be what you are looking for though.
> >
> > We do have another release model called cycle-automatic. This was
> > introduced for tempest plugins to just do a release at the end of the
> > cycle to make sure there is a tag to denote the tempest version the
> > plugin was originally developed for. Since some plugins are being picked
> > up more often downstream, this model does allow for additional releases
> > to be proposed at any point during the development cycle.
> >
> > We will need to discuss this as a team to see if this makes sense for
> > non-tempest plugins. It was intended only for those types of
> > deliverables. I just mention it here as something that we do have in
> > place that might be adapted to fit what the team needs. But we also need
> > to consider what we are communicating to downstream consumers of our
> > releases, so I'm not entirely sure at this point if it makes sense, or
> > would be a good thing, to allow other types of deliverables to use this
> > model.
>
> Yeah the general idea was to drive toward best practices (if you do a
> single release per cycle, it's important that it's good, so it should
> use feature freeze, release candidates...). That said today it's rare
> that we break things... and nobody tests RC releases anyway.
>
> So there is definitely a possibility for just having one single
> cycle-based release model: release once or more in a cycle, do not use
> betas or RCs. And if there is no release like two weeks before final,
> we'd cut automatically cut one from HEAD.
>
> I'd actually prefer that to switching to cycle-independent, since
> deliverables under that model are not part of "the openstack release".
>
> That said, it might be a bit late to roll that out for this cycle, two
> days before we actually feature-freeze cycle-with-rc projects...

This sounds like a nice idea to cut some of the overhead of releasing
and simplify the whole process. My experience is from two slightly
unusual projects - ironic (intermediary) and kolla (cycle-trailing) -
but I think this would help. I know that in kolla we typically end up
at RC2 before release, but I expect that's due to cutting the branch
before it's fully stable so that we can pick up feature work on
master. Also it's in the nature of having many dependencies outside of
our control.

>
> --
> Thierry Carrez (ttx)
>