Open Stack

Note that it's technically too late to change the release model
(milestone-1 is the deadline), but since that kills two birds with one
stone, I'd be willing to grant mistral an exception (as long as it's
done before milestone-2, which is next week).

Renat Akhmerov wrote:
> Thanks Thierry.
> 
> To me it sounds like even a better release model for us. We can discuss
> it with a team at the next team meeting and make a decision.
> 
> Renat Akhmerov
> @Nokia
> 
> On 1 Jun 2017, 17:06 +0700, Thierry Carrez <thierry at openstack.org>, wrote:
>> 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)
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Thierry Carrez (ttx)