On 4/6/20 8:20 AM, Mark Goddard wrote:

On Mon, 6 Apr 2020 at 13:50, Herve Beraud <hberaud@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. Sean

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.

...

...

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

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... -- Thierry Carrez (ttx)

On Tue, 7 Apr 2020 at 10:41, Thierry Carrez <thierry@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)