On Thu, Aug 1, 2019 at 8:29 PM Dmitry Tantsur dtantsur@redhat.com wrote:

On 7/31/19 8:21 PM, Kendall Nelson wrote:

...

Hello Everyone!

Development Focus

We are now past the Train-2 milestone, and entering the last development phase of the cycle. Teams should be focused on implementing planned work for the cycle.Now is a good time to review those plans and reprioritize anything if needed based on the what progress has been made and what looks realistic to complete in the next few weeks.

General Information

The following cycle-with-intermediary deliverables have not done any intermediary release yet during this cycle. The cycle-with-rc release model is more suited for deliverables that plan to be released only once per cycle.

I respectfully disagree. I will reserve my opinion on whether cycle-with-rc suits *anyone*, but in our case I'd prefer to have an option of releasing something in the middle of a cycle even if we don't exercise this option way too often.

I'm not an ironic PTL, bit anyway please note that I'm -1 on the change for any of our projects.

I agree with Dmitry. cycle-with-intermediary model allows project teams to release somethings at any time during a release when they want. On the other hand, cycle-with-intermediary means at least one release along with a release cycle. "cycle-with-rc" means such deliverable can only *one* release per cycle. "cycle-with-rc" might be a good option for some projects but I think it is not forced.

If some deliverable tends to have less changes and it is not worth cutting a release, another option might be "independent". My understanding is that "independent" release model does not allow us to have stable branches, so it might be a thing considered carefully when we switch some deliverable to "independent".

Talking about horizon plugins, as a neutron release liaison, neutron-fwaas/vpnaas-dashboard hit similar situation to ironic-ui. we don't have any substantial changes till now in this cycle. I guess this situation may continues in further releases in most horizon plugins. I am not sure which release model is appropriate. horizon adopts release-with-rc model now and horizon plugins are usually assumed to work with a specific release of horizon, so "independent" might not fit. release-with-intermediary or release-with-rc may fit, but there are cases where they have only infra related changes in a cycle.

Thanks, Akihiro Motoki

Dmitry

...

As a result, we will be proposing to change the release model for the following deliverables:

blazar-dashboard

cloudkitty-dashboard ec2-api freezer-web-ui freezer heat-agents heat-dashboard ironic-ui karbor-dashboard karbor kuryr-kubernetes magnum-ui manila-ui masakari-dashboard monasca-agent monasca-api monasca-ceilometer monasca-events-api monasca-kibana-plugin monasca-log-api monasca-notification monasca-persister monasca-thresh monasca-transform monasca-ui murano-agent networking-baremetal networking-generic-switch networking-hyperv neutron-fwaas-dashboard neutron-vpnaas-dashboard requirements sahara-extra senlin-dashboard solum-dashboard tacker-horizon tricircle vitrage-dashboard vitrage watcher-dashboard

PTLs and release liaisons for each of those deliverables can either +1 the release model changewhen we get them pushed, or propose an intermediary release for that deliverable. In absence of answer by the start of R-10 week we'll consider that the switch to cycle-with-rc is preferable.

Upcoming Deadlines & Dates

Non-client library freeze: September 05 (R-6 week) Client library freeze: September 12 (R-5 week) Train-3 milestone: September 12 (R-5 week)

-Kendall (diablo_rojo) + the Release Management Team

Top-posting because I'm not answering to anything specific.

Have you considered allowing intermediary releases with cycle-with-rc? Essentially combining the two models into one?

On 8/1/19 9:02 PM, Doug Hellmann wrote:

...

On Aug 1, 2019, at 12:52 PM, Akihiro Motoki <amotoki@gmail.com mailto:amotoki@gmail.com> wrote:

On Thu, Aug 1, 2019 at 8:29 PM Dmitry Tantsur <dtantsur@redhat.com mailto:dtantsur@redhat.com> wrote:

...

On 7/31/19 8:21 PM, Kendall Nelson wrote:

...

Hello Everyone!

Development Focus

We are now past the Train-2 milestone, and entering the last development phase of the cycle. Teams should be focused on implementing planned work for the cycle.Now is  a good time to review those plans and reprioritize anything if needed based on the what progress has been made and what looks realistic to complete in the next few weeks.

General Information

The following cycle-with-intermediary deliverables have not done any intermediary release yet during this cycle. The cycle-with-rc release model is more suited for deliverables that plan to be released only once per cycle.

I respectfully disagree. I will reserve my opinion on whether cycle-with-rc suits *anyone*, but in our case I'd prefer to have an option of releasing something in the middle of a cycle even if we don't exercise this option way too often.

I'm not an ironic PTL, bit anyway please note that I'm -1 on the change for any of our projects.

I agree with Dmitry. cycle-with-intermediary model allows project teams to release somethings at any time during a release when they want. On the other hand, cycle-with-intermediary means at least one release along with a release cycle. "cycle-with-rc" means such deliverable can only *one* release per cycle. "cycle-with-rc" might be a good option for some projects but I think it is not forced.

If some deliverable tends to have less changes and it is not worth cutting a release, another option might be "independent". My understanding is that "independent" release model does not allow us to have stable branches, so it might be a thing considered carefully when we switch some deliverable to "independent”.

That’s not quite right. Independent deliverables can have stable branches, but they are not considered part of the OpenStack release because they are not managed by the release team.

...

Talking about horizon plugins, as a neutron release liaison, neutron-fwaas/vpnaas-dashboard hit similar situation  to ironic-ui. we don't have any substantial changes till now in this cycle. I guess this situation may continues in further releases in most horizon plugins. I am not sure which release model is appropriate. horizon adopts release-with-rc model now and horizon plugins are usually assumed to work with a specific release of horizon, so "independent" might not fit. release-with-intermediary or release-with-rc may fit, but there are cases where they have only infra related changes in a cycle.

There are far far too many deliverables for our small release team to keep up with everyone following different procedures for branching, and branching incorrectly has too many bad ramifications to leave it to chance. We have therefore tried to describe several release models to meet teams’ needs, and to allow the release team to automate managing the deliverables in groups that all follow the same procedures so we end up with consistent results. The fact that most of the rest of the community have not needed to pay much attention to issues around branch management says to me that this approach has been working.

As Thierry pointed out on IRC, there are reasons to require a release beyond the software having significant features or bug fixes. The reason we need a release for cycle-with-intermediary projects before the end of the cycle is that when we reach the final release deadline we need something to use as a place to create the stable branch (we only branch from tagged releases). In the past, we used the last release from the previous cycle as a fallback when teams missed other cycle deadlines. That resulted in creating a new stable branch that had none of the bug fixes or CI changes that had been on master, and which was therefore broken and required extra effort to fix. So, we now ask for an early release to give us a relatively recent one from the current cycle, rather than using the final release from the previous cycle.

The alternative, using the cycle-with-rc release model, means that the release team will automatically generate release candidates and a final release for the team. In cases where the team does not intend to release more than one version in a cycle, this is easier for the project team and not much more work for the release team since the deliverable is handled as part of the batch of all similar deliverables. Updating the release model is the default when there are no releases because it reflects what is actually happening with the deliverable and the release team can manage the change on its own, and Kendall’s email is the notification which is supposed to trigger the conversation for each deliverable so that project teams can decide how to proceed down one of the two paths proposed. Doing nothing isn’t really an option, though.

So, if you have a cycle-with-intermediary deliverable with changes that you haven’t considered “substantial” enough to trigger a release previously, and you do not want to change the release model, this is the point at which you should do a release anyway to avoid issues at the end of the cycle.

Doug

On Fri, Aug 2, 2019 at 5:39 AM Thierry Carrez thierry@openstack.org wrote:

The release management team discussed this topic at the meeting yesterday.

The current process works well in the case where you *know" you will only do one release (release-once), or you *know* you will do more than one release (release-often). We agree that it does not handle well the case where you actually have no idea how many releases you will do (release-if-needed).

We need to add a bit of flexibility there, but:

• the release team still needs to use a very limited number of standard

release models, and know as much as possible in advance. We handle hundreds of OpenStack deliverables, we can't have everyone use their own release variant.

• we don't want to disconnect project teams from their releases (we

still want teams to trigger release points and feel responsible for the resulting artifact).

Here is the proposal we came up with:

• The general idea is, by milestone-2, you should have picked your

release model. If you plan to release-once, you should use the cycle-with-rcs model. If you plan to release-often, you should be cycle-with-intermediary. In the hopefully rare case where you have no idea and would like to release-if-needed, continue to read.

• Between milestone-2 and milestone-3, we look up

cycle-with-intermediary things that have not done a release yet. For those, we propose a switch to cycle-with-rcs, and use that to start a discussion.

At that point four things can happen:

(1) you realize you could do an intermediary release, and do one now. Patch to change release model is abandoned.

(2) you realize you only want to do one release this cycle, and +1 the patch.

(3) you still have no idea where you're going for this deliverable this cycle and would like to release as-needed: you -1 the patch. You obviously commit to producing a release before RC1 freeze. If by RC1 freeze we still have no release, we'll force one.

(4) you realize that the deliverable should be abandoned, or should be disconnected from the "OpenStack" release and be made independent, or some other solution. You -1 the patch and propose an alternative.

In all cases that initial patch is the occasion to raise the discussion and cover that blind spot, well in advance of the final weeks of the release where we don't have time to handle differently each of our hundreds of deliverables.

This process seems reasonable, thanks Thierry! :)

// jim

Dmitry Tantsur wrote:

...

Have you considered allowing intermediary releases with cycle-with-rc? Essentially combining the two models into one?

You really only have two different scenarios.

A- the final release is more usable and important than the others B- the final release is just another release, just happens to have a stable branch cut from it

In scenario (A), you use RCs to apply more care and make sure the one and only release works well. You can totally do other "releases" during the cycle, but since those are not using RCs and are not as carefully vetted, they use "beta" numbering.

In scenario (B), all releases are equally important and usable. There is no reason to use RCs for one and not the others.

-- Thierry Carrez (ttx)