Open Stack

On Mon, 2020-04-06 at 13:28 -0500, 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.
for what its worth i was suprised with the requirement to make more then one
release with the cycle-with-intermediary cycle too.
i orginally tought when os-vif moved to it we could make intermediat release if we
wanted too not that we were required to make them at each milestone.

looking at the text 
https://github.com/openstack/releases/blob/35595343ddba5db598a80ce9238df28f27c43a14/doc/source/reference/release_models.rst#cycle-with-intermediary

The "cycle-with-intermediary" model describes projects that produce multiple full releases during the development cycle,
with a final release to match the end of the cycle.

    "cycle-with-intermediary" projects commit to produce a release near the end of the 6-month development cycle to be
used with projects using the other cycle-based release models that are required to produce a release at that time.
    Release tags for deliverables using this tag are reviewed and applied by the Release Management team.

im not actully sure where that requirem of 1 relase per miles stone came from but we were told to do it by
the release team so we do.

releaes are relitvely cheap so its not a burden to do this but as we did between m2 and non clinet lib freeze
we often have period where we dont need to do a release yet or we would prefer to wait for a patch to merge which
we expect to merge a few days out after a milestone and its has been annoying to have to release a milestone release
under the cycle-with-intermediary release model in those cases. if there was a corss poject depency i have just asked
for a release a day or two later when the patch i was waiting for merged if waited to the next milestoen if it was an
internal fix.

its also possible that the reqirements for a release at each milestone was misscomunicated for 
cycle-with-intermediary but since it has happened at 2 or 3 times i now just assume its required even if its not
documented as such.

> > > > 
> > > 
> > > 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.
> 
> Sean
> 
>