Open Stack

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 at gmail.com 
>> <mailto: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
>