Open Stack

On Tue, Apr 7, 2020 at 11:43 AM 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.
>

Unfortunately yes :(


>
> 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 warmly welcome this.

Dmitry


>
> 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...
>
> --
> Thierry Carrez (ttx)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200407/f9e4d6d3/attachment.html>