[openstack-dev] [stable][neutron] How we handle Kilo backports

Assaf Muller amuller at redhat.com
Wed Nov 18 19:39:42 UTC 2015


On Wed, Nov 18, 2015 at 12:38 PM, Carl Baldwin <carl at ecbaldwin.net> wrote:
> On Wed, Nov 18, 2015 at 9:44 AM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
>> Hi all,
>>
>> as per [1] I imply that all projects under stable-maint-core team
>> supervision must abide the stable policy [2] which limits the types of
>> backports for N-2 branches (now it’s stable/kilo) to "Only critical bugfixes
>> and security patches”. With that, I remind all stable core members about the
>> rule.
>>
>> Since we are limited to ‘critical bugfixes’ only, and since there is no
>> clear definition of what ‘critical’ means, I guess we should define it for
>> ourselves.
>>
>> In Neutron world, we usually use Critical importance for those bugs that
>> break gate. High is used for those bugs that have high impact production
>> wise. With that in mind, I suggest we define ‘critical’ bugfixes as Critical
>> + High in LP. Comments on that?
>
> I was wondering about this today too.  Ihar is correct about how we
> use Critical importance in launchpad for Neutron bugs.  The number of
> Critical neutron bugs is very small and most of them are not relevant
> to stable releases because they are targeted at gate breakage incurred
> by new development in master.
>
> I'll +1 that we should extend this to Critical + High in launchpad.
> Otherwise, we would severely limit our ability to backport important
> bug fixes to a stable release that is only 6 months old and many
> deployers are only beginning to turn their attention to it.

+1

In many ways stable/kilo is more important than stable/liberty today.

>
>> (My understanding is that we can also advocate for the change in the global
>> policy if we think the ‘critical only’ rule should be relaxed, but till then
>> it makes sense to stick to what policy says.)
>
> +1
>
> Carl
>
> __________________________________________________________________________
> 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



More information about the OpenStack-dev mailing list