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

Ihar Hrachyshka ihrachys at redhat.com
Thu Nov 19 10:42:35 UTC 2015


Tony Breeds <tony at bakeyournoodle.com> wrote:

> On Wed, Nov 18, 2015 at 05:44:38PM +0100, Ihar Hrachyshka 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?
>
> So I'm not a core but I check the severity of the bug and query the  
> review owner
> if it is < High.  My rationale is that sometimes bugs are mis-classified,
> someone took the time to backport it so it's critical to that person if not
> the project.
>
> Note that doesn't mean they'll get in but it facilitates the discussion.
>
> Anyway we can iterate on this: https://review.openstack.org/247229

I believe it’s fine to change bug importance later based on revealed data,  
or when initial triaging was not correct. I think making clear that  
discussion about backport applicability for a branch should be set around  
LP importance field may add more transparency to how we select backport  
candidates.

I also believe that we should not be afraid of other backport types, as  
long as we may guarantee their safety (f.e. it’s ok to backport a fix  
stability fix; a fix that adds more test coverage; a fix for a typo in a  
message or a config file; etc.; yes, those types of bugs are not high  
impact, but there is no real reason not to deliver them to users).

I sent a patch to stable policy to clarify the latter:

https://review.openstack.org/247415

Ihar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151119/375288e5/attachment.pgp>


More information about the OpenStack-dev mailing list