Open Stack

On 2/18/19 4:28 PM, Lance Bragstad wrote:
> 
> 
> On 2/18/19 3:38 PM, Ben Nemec wrote:
>>
>>
>> On 2/18/19 3:19 PM, Colleen Murphy wrote:
>>>
>>>
>>> On Mon, Feb 18, 2019, at 6:11 PM, Ben Nemec wrote:
>>>>
>>>>
>>>> On 2/15/19 11:23 AM, Colleen Murphy wrote:
>>>>> ## Milestone Outlook
>>>>>
>>>>> https://releases.openstack.org/stein/schedule.html
>>>>>
>>>>> Feature freeze as well as final client release are both in 3 weeks.
>>>>> Non-client release deadline is in two weeks, which means changes
>>>>> needed for keystonemiddleware, keystoneauth, and the oslo libraries
>>>>> need to be proposed and reviewed ASAP.
>>>>
>>>> Reading this, it occurred to me that we probably shouldn't be applying
>>>> Oslo feature freeze to co-owned libraries. Most of those function more
>>>> as non-client libraries than the oslo.* libs, so there's no need to
>>>> freeze early.
>>>>
>>>> I've proposed https://review.openstack.org/637588 to reflect that in
>>>> the
>>>> Oslo policy. If you have an opinion on it please vote!
>>>>
>>>> -Ben
>>>>
>>> Thanks for mentioning that, I didn't even notice that Oslo had an
>>> earlier freeze date. Arguably oslo.policy should be held to the same
>>> standard as the other Oslo libraries since it has such far reach.
>>> Oslo.limit not so much yet.
>>
>> Oh, hmm. I forgot we had oslo.* libraries that were co-owned too. I
>> agree those should probably be kept to the Oslo feature freeze date.
>> I'll update the policy change to reflect that, and maybe make a note
>> that the policy is a guideline, not a hard and fast rule. If it makes
>> sense to freeze a library earlier then we should do that regardless of
>> what the policy says. I'm just trying to avoid stepping on other
>> teams' toes unnecessarily.
>>
>> Note that oslo.limit falls under the "not released yet" exception
>> (unfortunately) so feature freeze doesn't apply to it at all.
> 
> ++
> 
> This will apply once we get a 1.0 release, I think? We could release
> oslo.limit after feature freeze and still make changes to it up until we
> release a 1.0... then we're are the point of no return (dun dun dun!).

I think it's more about when a library has consumers than a strict 
version. Castellan technically just went 1.0 this cycle, but we've 
observed feature freeze for it because it had consumers (and really 
should have been 1.0). Ideally we want "has consumers" and "declared 
1.0" to happen fairly close together so we aren't breaking people, but 
if the latter doesn't happen in a timely fashion we still need to not 
break people. :-)

And just to tie a bow on the policy change discussion, I'm planning to 
abandon it. I discovered that both my examples were used in other 
non-client libraries, which means the rationale for freezing them early 
still applies. Maybe there is an Oslo library that doesn't need to, but 
we have the FFE process precisely for such exceptional cases. It seems I 
jumped the gun a bit on wanting to change the policy. Sorry for 
subjecting everyone to the noise of my train of thought, but hey, we are 
going back to Denver! ;-)

> 
>>
>>>
>>> Colleen
>>>
>>
> 
>