Re: [openstack-dev] [stable][neutron] Kilo is 'security-supported'. What does it imply?
Thierry Carrezwrote: Carl Baldwin wrote: - StableBranch page though requires that we don’t merge non-critical bug fixes there: "Only critical bugfixes and security patches are acceptable” Seems a little premature for Kilo. It is little more than 6 months old. Some projects may want to continue backporting reasonable (even though non-critical) fixes to older stable branches. F.e. in neutron, I think there is will to continue providing backports for the branch. +1 I'd like to reiterate my support for backporting appropriate and sensible bug fixes to Kilo. "Stable" always had two conflicting facets: it means working well, and it means changing less. In the first stage of stable maintenance the focus is on "working well", with lots of backports for issues discovered in the initial release. But after some time you caught all of the major issues and the focus shifts to "changing less". This is what the support phases are about, gradually shifting from one facet to another. OK, I guess we are currently bound by stable policy [1], and without changing the document, we cannot proceed with non-critical backports. At this point I am not clear how huge interest from distributions to maintain the older (N-2) branches will be. [1]: http://docs.openstack.org/project-team-guide/stable-branches.html#support-phases That said, that can certainly be revisited. I suppose as long as extra care is taken in selecting appropriate fixes for older branches, we can get the best of both worlds. I will talk to team members whether they feel strongly about it, and if so, I’ll propose some policy change that would allow projects to extend the scope of backports for older stable branches. Note that we'll likely spin out the stable branch maintenance team into its own project team (outside of the release management team), now that its focus is purely on defining a common stable branch policy and making sure it's respected across a wide range of project-specific maintenance teams. So that new team could definitely change the common rules there :) More on that soon. Cheers, -- Thierry Carrez (ttx) __ 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] [stable][neutron] Kilo is 'security-supported'. What does it imply?
Carl Baldwin wrote: >> - StableBranch page though requires that we don’t merge non-critical bug >> fixes there: "Only critical bugfixes and security patches are acceptable” > > Seems a little premature for Kilo. It is little more than 6 months old. > >> Some projects may want to continue backporting reasonable (even though >> non-critical) fixes to older stable branches. F.e. in neutron, I think there >> is will to continue providing backports for the branch. > > +1 I'd like to reiterate my support for backporting appropriate and > sensible bug fixes to Kilo. "Stable" always had two conflicting facets: it means working well, and it means changing less. In the first stage of stable maintenance the focus is on "working well", with lots of backports for issues discovered in the initial release. But after some time you caught all of the major issues and the focus shifts to "changing less". This is what the support phases are about, gradually shifting from one facet to another. That said, that can certainly be revisited. I suppose as long as extra care is taken in selecting appropriate fixes for older branches, we can get the best of both worlds. Note that we'll likely spin out the stable branch maintenance team into its own project team (outside of the release management team), now that its focus is purely on defining a common stable branch policy and making sure it's respected across a wide range of project-specific maintenance teams. So that new team could definitely change the common rules there :) More on that soon. Cheers, -- Thierry Carrez (ttx) __ 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] [stable][neutron] Kilo is 'security-supported'. What does it imply?
+1 -Original Message- From: Carl Baldwin [mailto:c...@ecbaldwin.net] Sent: Thursday, November 05, 2015 10:20 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [stable][neutron] Kilo is 'security-supported'. What does it imply? On Thu, Nov 5, 2015 at 8:17 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote: > - Releases page on wiki [2] calls the branch ‘Security-supported’ (and > it’s not clear what it implies) I saw this same thing yesterday when it was pointed out in the DVR IRC meeting [1]. I have a hard time believing that we want to abandon bug fix support for Kilo especially given recent attempts to be more proactive about it [2] (which I applaud). I suspect that there has simply been a mis-communication and we need to get the story straight in the wiki pages which Ihar pointed out. > - StableBranch page though requires that we don’t merge non-critical > bug fixes there: "Only critical bugfixes and security patches are acceptable” Seems a little premature for Kilo. It is little more than 6 months old. > Some projects may want to continue backporting reasonable (even though > non-critical) fixes to older stable branches. F.e. in neutron, I think > there is will to continue providing backports for the branch. +1 I'd like to reiterate my support for backporting appropriate and sensible bug fixes to Kilo. > I wonder though whether we would not break some global openstack rules > by continuing with those backports. Are projects actually limited > about what types of bug fixes are supposed to go in stable branches, > or we embrace different models of stable maintenance and allow for > some freedom per project? Carl [1] http://eavesdrop.openstack.org/meetings/neutron_dvr/2015/neutron_dvr.2015-11-04-15.00.log.html [2] http://lists.openstack.org/pipermail/openstack-dev/2015-October/077236.html __ 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] [stable][neutron] Kilo is 'security-supported'. What does it imply?
On Thu, Nov 5, 2015 at 8:17 AM, Ihar Hrachyshkawrote: > - Releases page on wiki [2] calls the branch ‘Security-supported’ (and it’s > not clear what it implies) I saw this same thing yesterday when it was pointed out in the DVR IRC meeting [1]. I have a hard time believing that we want to abandon bug fix support for Kilo especially given recent attempts to be more proactive about it [2] (which I applaud). I suspect that there has simply been a mis-communication and we need to get the story straight in the wiki pages which Ihar pointed out. > - StableBranch page though requires that we don’t merge non-critical bug > fixes there: "Only critical bugfixes and security patches are acceptable” Seems a little premature for Kilo. It is little more than 6 months old. > Some projects may want to continue backporting reasonable (even though > non-critical) fixes to older stable branches. F.e. in neutron, I think there > is will to continue providing backports for the branch. +1 I'd like to reiterate my support for backporting appropriate and sensible bug fixes to Kilo. > I wonder though whether we would not break some global openstack rules by > continuing with those backports. Are projects actually limited about what > types of bug fixes are supposed to go in stable branches, or we embrace > different models of stable maintenance and allow for some freedom per > project? Carl [1] http://eavesdrop.openstack.org/meetings/neutron_dvr/2015/neutron_dvr.2015-11-04-15.00.log.html [2] http://lists.openstack.org/pipermail/openstack-dev/2015-October/077236.html __ 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] [stable][neutron] Kilo is 'security-supported'. What does it imply?
Hi all, there is contradictory info about what we do with kilo now that it’s not the latest stable release. - An old email thread [1] suggested that the branch can still receive all kinds of bug fixes as long as corresponding project teams want to spend time on it: "expanding the support scope for N-1 stable branch is fine if we can deliver it”; "IIRC "current stable release" was originally defined by markmc as the branch where stable-maint team proactively proposes backports by monitoring the trunk, but we have lost that mode long ago, backports are now done retroactively after bugs are reported.” - Releases page on wiki [2] calls the branch ‘Security-supported’ (and it’s not clear what it implies) - StableBranch page though requires that we don’t merge non-critical bug fixes there: "Only critical bugfixes and security patches are acceptable” Some projects may want to continue backporting reasonable (even though non-critical) fixes to older stable branches. F.e. in neutron, I think there is will to continue providing backports for the branch. I wonder though whether we would not break some global openstack rules by continuing with those backports. Are projects actually limited about what types of bug fixes are supposed to go in stable branches, or we embrace different models of stable maintenance and allow for some freedom per project? [1] http://lists.openstack.org/pipermail/openstack-stable-maint/2014-July/002404.html [2] https://wiki.openstack.org/wiki/Releases [3] https://wiki.openstack.org/wiki/StableBranch#Support_phases Ihar __ 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