Re: [openstack-dev] Deprecation Policies (related to Heka)

[Michał Jastrzębski]

Agree with Christian, this is our internal wiring. As long as we
provide automated upgrade procedure which will seamlessly migrate from
heka to alternative we want, we should be good without deprecation per
se.

Cheers,
Michal

On 29 September 2016 at 04:36, Christian Berendt
 wrote:
>> On 29 Sep 2016, at 06:26, Steven Dake (stdake)  wrote:
>>
>> If you have a different parsing of the deprecation policy, feel free to 
>> chime in.
>
> Heka is only used as an internal component of Kolla and is not provided as a 
> service for the operators. It should be sufficient to replace Heka by 
> something else without deprecating it.
>
> Christian.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Deprecation Policies (related to Heka)

[Christian Berendt]

> On 29 Sep 2016, at 06:26, Steven Dake (stdake)  wrote:
> 
> If you have a different parsing of the deprecation policy, feel free to chime 
> in.

Heka is only used as an internal component of Kolla and is not provided as a 
service for the operators. It should be sufficient to replace Heka by something 
else without deprecating it.

Christian.


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Deprecation Policies (related to Heka)

[Steven Dake (stdake)]

First off, apologies for missing most of the team meeting today.  I have read 
through the logs and saw a discussion about deprecating heka.  We need to 
ensure that we follow the deprecation policy.  My understanding of the 
deprecation policy is as follows (in a nutshell):


1.   We must mail the 
openstack-operat...@lists.openstack.org
 mailing list and ask if the change impacts operators

2.   If it does impact operators, we have to propose a migration path that 
works and makes sense

3.   We have to *at minimum* keep the feature in the release for 3 months.  
Major features that are not technical preview should stay in the release for 2 
cycles and *extra care* should be taken when communicating our intent with the 
operator list.

4.   Once 1-3 are done, we must make official notice in the release notes 
for the release in which the deprecation occurred and deliver on that 
commitment of the stated deprecation time in O or P or Q.

5.   The thread on openstack-operators should be linked in the review of 
the deprecation of the work. (this last part of the policy isn’t stated, 
however, it will help avoid misunderstandings between the Kolla team, 
operators, and the technical committee)

I appreciate everyone’s interest in deprecating Heka in Ocata as it is entering 
security-fix only maintenance mode.  However, we need to follow the standard 
OpenStack deprecation policies, not make up new ones.  Heka will not be 
deprecated for Newton because we lack time to sort out 1-3 (especially #2 
above, the migration path) between now and Oct 12th (hopefully when we tag rc2, 
13th is drop dead date).

If you have a different parsing of the deprecation policy, feel free to chime 
in.

The standardized deprecation policy can be found here:

https://github.com/openstack/governance/blob/master/reference/tags/assert_follows-standard-deprecation.rst

Regards,
Steve
`~
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev