Open Stack

> -----Original Message-----
> From: Ihar Hrachyshka [mailto:ihrachys at redhat.com]
> Sent: Thursday, November 19, 2015 10:43 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [stable][neutron] How we handle Kilo
> backports
> 
> 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

Stability fixes might make sense case by case basis. And I have been looking all the backport more or less case by case basis anyways. Anything that throws 500 from the api and the fix does not change other behavior is IMO critical fix.

Typo fixes are not good idea for stable branches. As it might be bit annoying or amusing for the English user fixing typos in kilo will mean that it breaks translation for all the rest and I haven't seen any translation patches being proposed to older stable branches. 

- Erno