Open Stack

On Mon, 6 Apr 2020 at 14:46, Sean McGinnis <sean.mcginnis at gmx.com> wrote:
>
> On 4/6/20 8:20 AM, Mark Goddard wrote:
> > On Mon, 6 Apr 2020 at 13:50, Herve Beraud <hberaud at redhat.com> wrote:
> >> Hello ironic team,
> >>
> >> Quick reminder that we'll need a release very soon for a number of
> >> deliverables following a cycle-with-intermediary release model but which
> >> have not done *any* release yet in the Ussuri cycle:
> >>
> >> - bifrost
> >> - ironic-prometheus-exporter
> >> - ironic-ui
> >>
> >> Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release.
> > Can we please move to the cycle-with-optional-intermediary release
> > model? I realise it doesn't exist. We (ironic) would like the option
> > to release features outside the normal cadence of the OpenStack
> > release cycle, without being forced to do it. It would save a lot of
> > time, and avoid emails and autogenerated patches each cycle.
> >
> > I don't have a strong opinion on the Ironic top-level OpenDev project
> > discussion, but I think this is one example of where the team sees
> > unnecessary inflexibility in OpenStack's processes. Perhaps I'm
> > missing something.
> >
> > Mark
>
> The "independent" release model is basically a
> cycle-with-optional-intermediary release model, or at least it can be
> used that way.
>
> If there is nothing to be released for an entire cycle, then that
> deliverable really isn't cycle based. If the last release from the last
> cycle is still relevant to the next release, you don't do another
> release and you just keep using the old, existing release.
>
> So that would be my first suggestion. The other option that Thierry
> pointed out:
>
> "As swift has proven in the past, you can totally have a product
> strategy with the cycle-with-intermediary model. You can even maintain
> your own extra branches (think stable/2.0) if you want. The only extra
> limitations AFAIK in the integrated release are that (1) you also
> maintain stable branches at openstack common release points (like
> stable/train), and (2) that the openstack release management team has an
> opportunity to check the release numbering for semver sanity."
>
> The benefit of sticking with the cycle based model and making sure at
> least one release is done per cycle is that we can catch hidden bit rot
> that gets introduced and causes errors during the release process. This
> happens, sadly, more often than you might expect.
>
> Sticking with a cycle based model, it can either be
> cycle-with-intermediary, where we just want to make sure we get some
> updates along the way, or cycle-with-rc, where we at least always make
> sure there is a final release at the end of the cycle that picks up any
> changes. Additional beta releases can be done during the cycle if needed
> to test and validate changes before everyone is in the freeze at the end.
>
> The important thing is being able to communicate to downstream packagers
> and other consumers what to expect with these deliverables. If something
> is "cycle-*" based, but then we don't release anything, that makes it
> look like that deliverable got dropped. At least if we communicate it is
> "independent" then this would look normal and packagers know to just
> keep using that last version.
>
> If it is just an occasional thing that a package doesn't end up with any
> meaningful updates (I would be kind of suprised, even with low activity
> deliverables. There are always at least the usual cycle goal and other
> updates), then it is possible to tag a new version number on the same
> commit. This isn't great, but it allows us to test out the release
> process and make sure that is all working. And it allows a new point on
> which to branch, so should the need ever arise in the future, bug fixes
> can be backported to distinct branch points for each cycle that needs it.
>
> So we really don't want to introduce a release model that says "we
> follow the development cycle, maybe we'll release something this cycle,
> maybe we won't". That would be confusing and introduce uncertainty
> downstream.

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.

>
> Sean
>
>