Open Stack

> On Aug 1, 2019, at 12:52 PM, Akihiro Motoki <amotoki at gmail.com> wrote:
> 
> On Thu, Aug 1, 2019 at 8:29 PM Dmitry Tantsur <dtantsur at redhat.com <mailto:dtantsur at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190801/c27e588a/attachment-0001.html>