Re: [openstack-dev] [stable][neutron] Kilo is 'security-supported'. What does it imply?

2015-11-13 Thread Ihar Hrachyshka

Thierry Carrez  wrote:


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?

2015-11-06 Thread Thierry Carrez
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?

2015-11-05 Thread Vasudevan, Swaminathan (PNB Roseville)
+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?

2015-11-05 Thread Carl Baldwin
On Thu, Nov 5, 2015 at 8:17 AM, Ihar Hrachyshka  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-dev] [stable][neutron] Kilo is 'security-supported'. What does it imply?

2015-11-05 Thread Ihar Hrachyshka

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