Open Stack

Renat Akhmerov wrote:
> On 31 May 2017, 15:08 +0700, Thierry Carrez <thierry at openstack.org>, wrote:
>>> [mistral]
>>> mistral - blocking sqlalchemy - milestones
>>
>> I wonder why mistral is in requirements. Looks like tripleo-common is
>> depending on it ? Could someone shine some light on this ? It might just
>> mean mistral-lib is missing a few functions, and switching the release
>> model of mistral itself might be overkill ?
> 
> This dependency is currently needed to create custom Mistral actions. It
> was originally not the best architecture and one of the reasons to
> create 'mistral-lib' was in getting rid of dependency on ‘mistral’ by
> moving all that’s needed for creating actions into a lib (plus something
> else). The thing is that the transition is not over and APIs that we put
> into ‘mistral-lib’ are still experimental. The plan is to complete this
> initiative, including docs and needed refactoring, till the end of Pike.
> 
> What possible negative consequences may we have if we switch release
> model to "cycle-with-intermediary”?

There are no "negative" consequences. There are just consequences in
choosing a new release model, so I don't want mistral to switch to that
model *only* because it didn't complete moving some code out of mistral
proper into a more consumable mistral-lib. It feels like we wouldn't be
having that discussion if the code was more adequately split :)

First, the cycle-with-intermediary model means that every tag is a
"release", which is expected to be consumed by users. You have to be
pretty sure that it works -- there won't be any release candidates to
protect you. This means your automated testing coverage needs to be
pretty good.

Second, the cycle-with-intermediary model is less "driven" by the
release team -- you won't have as many reminders (like milestones), or
best-practice deadlines (like feature freeze) to help you. Your team is
basically doing release management internally, deciding when to release,
when to slow down, etc.

As such, this model appeals either to very young projects (which need a
lot of flexibility and need to put things out fast), and very mature
projects (where automated testing coverage is pretty complete, release
liaisons take up much of the release management, and things don't change
that often). Projects in the middle usually prefer the
cycle-with-milestones model.

> Practically, all our releases, even
> those made after milestones, are considered stable and I don’t see
> issues if we’ll be producing full releases every time.

Yes, it sounds like you could switch to that model without too much pain.

> Btw, how does
> stable branch maintenance work in this case? I guess it should be the
> same, one stable branch per cycle. I’d appreciate if you could clarify this.

There is no change in terms of stable releases, you still maintain only
one branch per cycle. The last intermediary release in a given cycle is
where the stable branch for the cycle is cut.

-- 
Thierry Carrez (ttx)