Re: [release] (a bit belated) Release countdown for week R-11, July 29 - August 2
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
>>> 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,
>> 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.