Tony Breeds <t...@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 ofbackports 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 therule. 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 productionwise. 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 ownerif 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
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
