settingsLogin | Registersettings

[openstack-dev] [stable] Making stable maintenance its own OpenStack project team

0 votes

Hi everyone,

A few cycles ago we set up the Release Cycle Management team which was a
bit of a frankenteam of the things I happened to be leading: release
management, stable branch maintenance and vulnerability management.
While you could argue that there was some overlap between those
functions (as in, "all these things need to be released") logic was not
the primary reason they were put together.

When the Security Team was created, the VMT was spinned out of the
Release Cycle Management team and joined there. Now I think we should
spin out stable branch maintenance as well:

  • A good chunk of the stable team work used to be stable point release
    management, but as of stable/liberty this is now done by the release
    management team and triggered by the project-specific stable maintenance
    teams, so there is no more overlap in tooling used there

  • Following the kilo reform, the stable team is now focused on defining
    and enforcing a common stable branch policy[1], rather than approving
    every patch. Being more visible and having more dedicated members can
    only help in that very specific mission

  • The release team is now headed by Doug Hellmann, who is focused on
    release management and does not have the history I had with stable
    branch policy. So it might be the right moment to refocus release
    management solely on release management and get the stable team its own
    leadership

  • Empowering that team to make its own decisions, giving it more
    visibility and recognition will hopefully lead to more resources being
    dedicated to it

  • If the team expands, it could finally own stable branch health and
    gate fixing. If that ends up all falling under the same roof, that team
    could make decisions on support timeframes as well, since it will be the
    primary resource to make that work

So.. good idea ? bad idea ? What do current stable-maint-core[2] members
think of that ? Who thinks they could step up to lead that team ?

[1] http://docs.openstack.org/project-team-guide/stable-branches.html
[2] https://review.openstack.org/#/admin/groups/530,members

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Nov 9, 2015 in openstack-dev by Thierry_Carrez (57,480 points)   3 8 13

29 Responses

0 votes

Excerpts from Thierry Carrez's message of 2015-11-09 17:41:53 +0100:

Hi everyone,

A few cycles ago we set up the Release Cycle Management team which was a
bit of a frankenteam of the things I happened to be leading: release
management, stable branch maintenance and vulnerability management.
While you could argue that there was some overlap between those
functions (as in, "all these things need to be released") logic was not
the primary reason they were put together.

When the Security Team was created, the VMT was spinned out of the
Release Cycle Management team and joined there. Now I think we should
spin out stable branch maintenance as well:

  • A good chunk of the stable team work used to be stable point release
    management, but as of stable/liberty this is now done by the release
    management team and triggered by the project-specific stable maintenance
    teams, so there is no more overlap in tooling used there

  • Following the kilo reform, the stable team is now focused on defining
    and enforcing a common stable branch policy[1], rather than approving
    every patch. Being more visible and having more dedicated members can
    only help in that very specific mission

  • The release team is now headed by Doug Hellmann, who is focused on
    release management and does not have the history I had with stable
    branch policy. So it might be the right moment to refocus release
    management solely on release management and get the stable team its own
    leadership

  • Empowering that team to make its own decisions, giving it more
    visibility and recognition will hopefully lead to more resources being
    dedicated to it

  • If the team expands, it could finally own stable branch health and
    gate fixing. If that ends up all falling under the same roof, that team
    could make decisions on support timeframes as well, since it will be the
    primary resource to make that work

So.. good idea ? bad idea ? What do current stable-maint-core[2] members
think of that ? Who thinks they could step up to lead that team ?

[1] http://docs.openstack.org/project-team-guide/stable-branches.html
[2] https://review.openstack.org/#/admin/groups/530,members

+1

Doug


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 9, 2015 by Doug_Hellmann (87,520 points)   3 4 12
0 votes

On 11/9/2015 10:41 AM, Thierry Carrez wrote:
Hi everyone,

A few cycles ago we set up the Release Cycle Management team which was a
bit of a frankenteam of the things I happened to be leading: release
management, stable branch maintenance and vulnerability management.
While you could argue that there was some overlap between those
functions (as in, "all these things need to be released") logic was not
the primary reason they were put together.

When the Security Team was created, the VMT was spinned out of the
Release Cycle Management team and joined there. Now I think we should
spin out stable branch maintenance as well:

  • A good chunk of the stable team work used to be stable point release
    management, but as of stable/liberty this is now done by the release
    management team and triggered by the project-specific stable maintenance
    teams, so there is no more overlap in tooling used there

  • Following the kilo reform, the stable team is now focused on defining
    and enforcing a common stable branch policy[1], rather than approving
    every patch. Being more visible and having more dedicated members can
    only help in that very specific mission

  • The release team is now headed by Doug Hellmann, who is focused on
    release management and does not have the history I had with stable
    branch policy. So it might be the right moment to refocus release
    management solely on release management and get the stable team its own
    leadership

  • Empowering that team to make its own decisions, giving it more
    visibility and recognition will hopefully lead to more resources being
    dedicated to it

  • If the team expands, it could finally own stable branch health and
    gate fixing. If that ends up all falling under the same roof, that team
    could make decisions on support timeframes as well, since it will be the
    primary resource to make that work

Isn't this kind of already what the stable maint team does? Well, that
and some QA people like mtreinish and sdague.

So.. good idea ? bad idea ? What do current stable-maint-core[2] members
think of that ? Who thinks they could step up to lead that team ?

[1] http://docs.openstack.org/project-team-guide/stable-branches.html
[2] https://review.openstack.org/#/admin/groups/530,members

With the decentralizing of the stable branch stuff in Liberty [1] it
seems like there would be less use for a PTL for stable branch
maintenance - the cats are now herding themselves, right? Or at least
that's the plan as far as I understood it. And the existing stable
branch wizards are more or less around for help and answering questions.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-November/078281.html

--

Thanks,

Matt Riedemann


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 9, 2015 by Matt_Riedemann (48,320 points)   3 9 22
0 votes

On Mon, Nov 09, 2015 at 05:41:53PM +0100, Thierry Carrez wrote:
Hi everyone,

A few cycles ago we set up the Release Cycle Management team which was a
bit of a frankenteam of the things I happened to be leading: release
management, stable branch maintenance and vulnerability management.
While you could argue that there was some overlap between those
functions (as in, "all these things need to be released") logic was not
the primary reason they were put together.

When the Security Team was created, the VMT was spinned out of the
Release Cycle Management team and joined there. Now I think we should
spin out stable branch maintenance as well:

  • A good chunk of the stable team work used to be stable point release
    management, but as of stable/liberty this is now done by the release
    management team and triggered by the project-specific stable maintenance
    teams, so there is no more overlap in tooling used there

  • Following the kilo reform, the stable team is now focused on defining
    and enforcing a common stable branch policy[1], rather than approving
    every patch. Being more visible and having more dedicated members can
    only help in that very specific mission

  • The release team is now headed by Doug Hellmann, who is focused on
    release management and does not have the history I had with stable
    branch policy. So it might be the right moment to refocus release
    management solely on release management and get the stable team its own
    leadership

  • Empowering that team to make its own decisions, giving it more
    visibility and recognition will hopefully lead to more resources being
    dedicated to it

  • If the team expands, it could finally own stable branch health and
    gate fixing. If that ends up all falling under the same roof, that team
    could make decisions on support timeframes as well, since it will be the
    primary resource to make that work

So.. good idea ? bad idea ? What do current stable-maint-core[2] members
think of that ? Who thinks they could step up to lead that team ?

So I don't see the point, do we really think this needs to be a thing? Most of
the backports and reviews are done by project specific teams. What are you
actually proposing the team produce? With the point releases going away the only
actual thing the team is responsible before disappears. Right now most of [1] is
inactive when it comes to do day to day stable branch activities.

It seems to me with besides a few of us looking at gate issues when we have to
backport something and find nothing working the only thing [1] does is respond
to requests to add people to project specific stable core teams. (which is
something I've argued against in the past) I don't think adding a separate team
to governance for this really makes sense.

That being said I can understand your point of view that Doug doesn't want to
worry about stable, something I can't really blame him for because apparently
neither do most people (including myself on most days).

-Matt Treinish


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Nov 9, 2015 by Matthew_Treinish (11,200 points)   2 5 5
0 votes

Excerpts from Matt Riedemann's message of 2015-11-09 16:05:29 -0600:

On 11/9/2015 10:41 AM, Thierry Carrez wrote:

Hi everyone,

A few cycles ago we set up the Release Cycle Management team which was a
bit of a frankenteam of the things I happened to be leading: release
management, stable branch maintenance and vulnerability management.
While you could argue that there was some overlap between those
functions (as in, "all these things need to be released") logic was not
the primary reason they were put together.

When the Security Team was created, the VMT was spinned out of the
Release Cycle Management team and joined there. Now I think we should
spin out stable branch maintenance as well:

  • A good chunk of the stable team work used to be stable point release
    management, but as of stable/liberty this is now done by the release
    management team and triggered by the project-specific stable maintenance
    teams, so there is no more overlap in tooling used there

  • Following the kilo reform, the stable team is now focused on defining
    and enforcing a common stable branch policy[1], rather than approving
    every patch. Being more visible and having more dedicated members can
    only help in that very specific mission

  • The release team is now headed by Doug Hellmann, who is focused on
    release management and does not have the history I had with stable
    branch policy. So it might be the right moment to refocus release
    management solely on release management and get the stable team its own
    leadership

  • Empowering that team to make its own decisions, giving it more
    visibility and recognition will hopefully lead to more resources being
    dedicated to it

  • If the team expands, it could finally own stable branch health and
    gate fixing. If that ends up all falling under the same roof, that team
    could make decisions on support timeframes as well, since it will be the
    primary resource to make that work

Isn't this kind of already what the stable maint team does? Well, that
and some QA people like mtreinish and sdague.

So.. good idea ? bad idea ? What do current stable-maint-core[2] members
think of that ? Who thinks they could step up to lead that team ?

[1] http://docs.openstack.org/project-team-guide/stable-branches.html
[2] https://review.openstack.org/#/admin/groups/530,members

With the decentralizing of the stable branch stuff in Liberty [1] it
seems like there would be less use for a PTL for stable branch
maintenance - the cats are now herding themselves, right? Or at least
that's the plan as far as I understood it. And the existing stable
branch wizards are more or less around for help and answering questions.

The same might be said about releasing from master and the release
management team. There's still some benefit to having people dedicated
to making sure projects all agree to sane policies and to keep up with
deliverables that need to be released.

Doug

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-November/078281.html


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 9, 2015 by Doug_Hellmann (87,520 points)   3 4 12
0 votes

-----Original Message-----
From: Thierry Carrez [mailto:thierry@openstack.org]
Sent: 09 November 2015 16:42
To: OpenStack Development Mailing List
Subject: [openstack-dev] [stable] Making stable maintenance its own
OpenStack project team

Hi everyone,

A few cycles ago we set up the Release Cycle Management team which was a
bit of a frankenteam of the things I happened to be leading: release
management, stable branch maintenance and vulnerability management.
While you could argue that there was some overlap between those functions
(as in, "all these things need to be released") logic was not the primary
reason they were put together.

When the Security Team was created, the VMT was spinned out of the
Release Cycle Management team and joined there. Now I think we should
spin out stable branch maintenance as well:

  • A good chunk of the stable team work used to be stable point release
    management, but as of stable/liberty this is now done by the release
    management team and triggered by the project-specific stable maintenance
    teams, so there is no more overlap in tooling used there

  • Following the kilo reform, the stable team is now focused on defining and
    enforcing a common stable branch policy[1], rather than approving every
    patch. Being more visible and having more dedicated members can only help
    in that very specific mission

  • The release team is now headed by Doug Hellmann, who is focused on
    release management and does not have the history I had with stable branch
    policy. So it might be the right moment to refocus release management
    solely on release management and get the stable team its own leadership

  • Empowering that team to make its own decisions, giving it more visibility
    and recognition will hopefully lead to more resources being dedicated to it

  • If the team expands, it could finally own stable branch health and gate
    fixing. If that ends up all falling under the same roof, that team could make
    decisions on support timeframes as well, since it will be the primary resource
    to make that work

So.. good idea ? bad idea ? What do current stable-maint-core[2] members
think of that ? Who thinks they could step up to lead that team ?

[1] http://docs.openstack.org/project-team-guide/stable-branches.html
[2] https://review.openstack.org/#/admin/groups/530,members

--
Thierry Carrez (ttx)

Hi Thierry,

Thanks for bringing this up. The timing couldn't have been better.

I had lengthy discussion with Flavio Percoco in Tokyo. He asked me what would be the things I'd like to see TC taking on and fix over next cycle. After ranting to him over 20min how I'd like to have actual stable branches in OpenStack, not just tag and branch called stable and find the will and resources to do that, I turned to him and asked "But we really do not need TC for that do we?"

I'm not part of the global stable-maint-core but I have been stable branch liaison for Glance for year now. And I can say that our stable branches are not just tag and branch, they are actually maintained, by really small group of people (which has btw been growing over that whole time). Ihar started discussion to implement something similar to Neutron stable branches, which proves to me that there is will to work on this problem.

Based on the discussion around wishes to extend support of Juno, there is definitely urge to have our stable releases maintained and supported longer. I don't think Juno is reasonable expectation to see that happen, but perhaps we get there.

I think what you are proposing here is the right direction to go, not because it used to be part of "frankenteam" led by you, but because I think the group of people working on our stable branches deserves and needs the recognition for the work. I think that would be the first step to get the people involved. After moving the ownership to individual projects I'd like to see this team, not replacing that but being liberally inclusive cross-project (meta) team to unite the efforts between the projects and making the lives of those people easier and the efforts more justified. I'm in a lucky position as after coming back home I had the discussion with my management and got the commitment to spend significant amount of my time to work on stable across OpenStack projects.

I do realize that there is very small and dedicated group of people fixing the gates and doing all the magic around that issue. If we get more traction and interest of doing backports proactively, hopefully the health of those stable gates would interest more people as well and we could spread that load away from those so few and valuable folks.

Based on this I would like to put my name up for the task.

Will it be me or someone else leading this team if it gets formed, count me in. I will put my effort to make our stable branches better anyways.

Best,
Erno (jokke_) Kuvaja



OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-
request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 9, 2015 by kuvaja_at_hpe.com (1,320 points)   1
0 votes

Excerpts from Matthew Treinish's message of 2015-11-09 17:09:54 -0500:

On Mon, Nov 09, 2015 at 05:41:53PM +0100, Thierry Carrez wrote:

Hi everyone,

A few cycles ago we set up the Release Cycle Management team which was a
bit of a frankenteam of the things I happened to be leading: release
management, stable branch maintenance and vulnerability management.
While you could argue that there was some overlap between those
functions (as in, "all these things need to be released") logic was not
the primary reason they were put together.

When the Security Team was created, the VMT was spinned out of the
Release Cycle Management team and joined there. Now I think we should
spin out stable branch maintenance as well:

  • A good chunk of the stable team work used to be stable point release
    management, but as of stable/liberty this is now done by the release
    management team and triggered by the project-specific stable maintenance
    teams, so there is no more overlap in tooling used there

  • Following the kilo reform, the stable team is now focused on defining
    and enforcing a common stable branch policy[1], rather than approving
    every patch. Being more visible and having more dedicated members can
    only help in that very specific mission

  • The release team is now headed by Doug Hellmann, who is focused on
    release management and does not have the history I had with stable
    branch policy. So it might be the right moment to refocus release
    management solely on release management and get the stable team its own
    leadership

  • Empowering that team to make its own decisions, giving it more
    visibility and recognition will hopefully lead to more resources being
    dedicated to it

  • If the team expands, it could finally own stable branch health and
    gate fixing. If that ends up all falling under the same roof, that team
    could make decisions on support timeframes as well, since it will be the
    primary resource to make that work

So.. good idea ? bad idea ? What do current stable-maint-core[2] members
think of that ? Who thinks they could step up to lead that team ?

So I don't see the point, do we really think this needs to be a thing? Most of
the backports and reviews are done by project specific teams. What are you
actually proposing the team produce? With the point releases going away the only
actual thing the team is responsible before disappears. Right now most of [1] is
inactive when it comes to do day to day stable branch activities.

Point releases are not going away, though. We're not synchronizing them,
but we are still going to have stable releases.

It seems to me with besides a few of us looking at gate issues when we have to
backport something and find nothing working the only thing [1] does is respond
to requests to add people to project specific stable core teams. (which is
something I've argued against in the past) I don't think adding a separate team
to governance for this really makes sense.

That being said I can understand your point of view that Doug doesn't want to
worry about stable, something I can't really blame him for because apparently
neither do most people (including myself on most days).

I'm unlikely to have time to dive into fixing stable branch issues
myself this cycle, but I still think those branches are valuable
things. It's not that I don't want to worry about it at all so
much as I want the people who do worry about it more than I do
to have more input and flexibility.

Doug

-Matt Treinish


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 9, 2015 by Doug_Hellmann (87,520 points)   3 4 12
0 votes

On Mon, Nov 09, 2015 at 05:28:45PM -0500, Doug Hellmann wrote:
Excerpts from Matt Riedemann's message of 2015-11-09 16:05:29 -0600:

On 11/9/2015 10:41 AM, Thierry Carrez wrote:

Hi everyone,

A few cycles ago we set up the Release Cycle Management team which was a
bit of a frankenteam of the things I happened to be leading: release
management, stable branch maintenance and vulnerability management.
While you could argue that there was some overlap between those
functions (as in, "all these things need to be released") logic was not
the primary reason they were put together.

When the Security Team was created, the VMT was spinned out of the
Release Cycle Management team and joined there. Now I think we should
spin out stable branch maintenance as well:

  • A good chunk of the stable team work used to be stable point release
    management, but as of stable/liberty this is now done by the release
    management team and triggered by the project-specific stable maintenance
    teams, so there is no more overlap in tooling used there

  • Following the kilo reform, the stable team is now focused on defining
    and enforcing a common stable branch policy[1], rather than approving
    every patch. Being more visible and having more dedicated members can
    only help in that very specific mission

  • The release team is now headed by Doug Hellmann, who is focused on
    release management and does not have the history I had with stable
    branch policy. So it might be the right moment to refocus release
    management solely on release management and get the stable team its own
    leadership

  • Empowering that team to make its own decisions, giving it more
    visibility and recognition will hopefully lead to more resources being
    dedicated to it

  • If the team expands, it could finally own stable branch health and
    gate fixing. If that ends up all falling under the same roof, that team
    could make decisions on support timeframes as well, since it will be the
    primary resource to make that work

Isn't this kind of already what the stable maint team does? Well, that
and some QA people like mtreinish and sdague.

So.. good idea ? bad idea ? What do current stable-maint-core[2] members
think of that ? Who thinks they could step up to lead that team ?

[1] http://docs.openstack.org/project-team-guide/stable-branches.html
[2] https://review.openstack.org/#/admin/groups/530,members

With the decentralizing of the stable branch stuff in Liberty [1] it
seems like there would be less use for a PTL for stable branch
maintenance - the cats are now herding themselves, right? Or at least
that's the plan as far as I understood it. And the existing stable
branch wizards are more or less around for help and answering questions.

The same might be said about releasing from master and the release
management team. There's still some benefit to having people dedicated
to making sure projects all agree to sane policies and to keep up with
deliverables that need to be released.

Except the distinction is that relmgt is actually producing something. Relmgt
has the releases repo which does centralize library releases, reno to do the
release notes, etc. What does the global stable core do? Right now it's there
almost entirely to just add people to the project specific stable core teams.

-Matt Treinish


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Nov 9, 2015 by Matthew_Treinish (11,200 points)   2 5 5
0 votes

-----Original Message-----
From: Matthew Treinish [mailto:mtreinish@kortar.org]
Sent: 09 November 2015 22:40
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [stable] Making stable maintenance its own
OpenStack project team

On Mon, Nov 09, 2015 at 05:28:45PM -0500, Doug Hellmann wrote:

Excerpts from Matt Riedemann's message of 2015-11-09 16:05:29 -0600:

On 11/9/2015 10:41 AM, Thierry Carrez wrote:

Hi everyone,

A few cycles ago we set up the Release Cycle Management team which
was a bit of a frankenteam of the things I happened to be leading:
release management, stable branch maintenance and vulnerability
management.
While you could argue that there was some overlap between those
functions (as in, "all these things need to be released") logic
was not the primary reason they were put together.

When the Security Team was created, the VMT was spinned out of the
Release Cycle Management team and joined there. Now I think we
should spin out stable branch maintenance as well:

  • A good chunk of the stable team work used to be stable point
    release management, but as of stable/liberty this is now done by
    the release management team and triggered by the project-specific
    stable maintenance teams, so there is no more overlap in tooling
    used there

  • Following the kilo reform, the stable team is now focused on
    defining and enforcing a common stable branch policy[1], rather
    than approving every patch. Being more visible and having more
    dedicated members can only help in that very specific mission

  • The release team is now headed by Doug Hellmann, who is focused
    on release management and does not have the history I had with
    stable branch policy. So it might be the right moment to refocus
    release management solely on release management and get the stable
    team its own leadership

  • Empowering that team to make its own decisions, giving it more
    visibility and recognition will hopefully lead to more resources
    being dedicated to it

  • If the team expands, it could finally own stable branch health
    and gate fixing. If that ends up all falling under the same roof,
    that team could make decisions on support timeframes as well,
    since it will be the primary resource to make that work

Isn't this kind of already what the stable maint team does? Well,
that and some QA people like mtreinish and sdague.

So.. good idea ? bad idea ? What do current stable-maint-core[2]
members think of that ? Who thinks they could step up to lead that
team ?

[1]
http://docs.openstack.org/project-team-guide/stable-branches.html
[2] https://review.openstack.org/#/admin/groups/530,members

With the decentralizing of the stable branch stuff in Liberty [1] it
seems like there would be less use for a PTL for stable branch
maintenance - the cats are now herding themselves, right? Or at
least that's the plan as far as I understood it. And the existing
stable branch wizards are more or less around for help and answering
questions.

The same might be said about releasing from master and the release
management team. There's still some benefit to having people dedicated
to making sure projects all agree to sane policies and to keep up with
deliverables that need to be released.

Except the distinction is that relmgt is actually producing something. Relmgt
has the releases repo which does centralize library releases, reno to do the
release notes, etc. What does the global stable core do? Right now it's there
almost entirely to just add people to the project specific stable core teams.

-Matt Treinish

I'd like to move the discussion from what are the roles of the current stable-maint-core and more towards what the benefits would be having a stable-maint team rather than the -core group alone.

Personally I think the stable maintenance should be quite a lot more than unblocking gate and approving people allowed to merge to the stable branches.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 9, 2015 by kuvaja_at_hpe.com (1,320 points)   1
0 votes

+1

I think that as OpenStack's customer base grows, this is going to become more and more important, and will get the pain of users not getting updates will increase enough that there will be a group of engineers willing to do not only backports and releases, but bugfixes in trunk and gate maintenance on the branches. Providing a real "home" for these engineers will help empower them to act proactively to improve Stable branch releases and maybe even go beyond and develop a patch release process for stable releases that makes security and vulnerability fixes easier to install for the users.

As long as a critical mass can be reached for the team, it is likely that the team will exceed expectations.

--Rocky

-----Original Message-----
From: Thierry Carrez [mailto:thierry@openstack.org]
Sent: Monday, November 09, 2015 8:42 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [stable] Making stable maintenance its own
OpenStack project team

Hi everyone,

A few cycles ago we set up the Release Cycle Management team which was
a
bit of a frankenteam of the things I happened to be leading: release
management, stable branch maintenance and vulnerability management.
While you could argue that there was some overlap between those
functions (as in, "all these things need to be released") logic was not
the primary reason they were put together.

When the Security Team was created, the VMT was spinned out of the
Release Cycle Management team and joined there. Now I think we should
spin out stable branch maintenance as well:

  • A good chunk of the stable team work used to be stable point release
    management, but as of stable/liberty this is now done by the release
    management team and triggered by the project-specific stable
    maintenance
    teams, so there is no more overlap in tooling used there

  • Following the kilo reform, the stable team is now focused on defining
    and enforcing a common stable branch policy[1], rather than approving
    every patch. Being more visible and having more dedicated members can
    only help in that very specific mission

  • The release team is now headed by Doug Hellmann, who is focused on
    release management and does not have the history I had with stable
    branch policy. So it might be the right moment to refocus release
    management solely on release management and get the stable team its own
    leadership

  • Empowering that team to make its own decisions, giving it more
    visibility and recognition will hopefully lead to more resources being
    dedicated to it

  • If the team expands, it could finally own stable branch health and
    gate fixing. If that ends up all falling under the same roof, that team
    could make decisions on support timeframes as well, since it will be
    the
    primary resource to make that work

So.. good idea ? bad idea ? What do current stable-maint-core[2]
members
think of that ? Who thinks they could step up to lead that team ?

[1] http://docs.openstack.org/project-team-guide/stable-branches.html
[2] https://review.openstack.org/#/admin/groups/530,members

--
Thierry Carrez (ttx)



OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-
request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 10, 2015 by Rochelle_Grober (7,040 points)   1 3 3
0 votes

On Mon, Nov 09, 2015 at 10:54:43PM +0000, Kuvaja, Erno wrote:

On Mon, Nov 09, 2015 at 05:28:45PM -0500, Doug Hellmann wrote:

Excerpts from Matt Riedemann's message of 2015-11-09 16:05:29 -0600:

On 11/9/2015 10:41 AM, Thierry Carrez wrote:

Hi everyone,

A few cycles ago we set up the Release Cycle Management team which
was a bit of a frankenteam of the things I happened to be leading:
release management, stable branch maintenance and vulnerability
management.
While you could argue that there was some overlap between those
functions (as in, "all these things need to be released") logic
was not the primary reason they were put together.

When the Security Team was created, the VMT was spinned out of the
Release Cycle Management team and joined there. Now I think we
should spin out stable branch maintenance as well:

  • A good chunk of the stable team work used to be stable point
    release management, but as of stable/liberty this is now done by
    the release management team and triggered by the project-specific
    stable maintenance teams, so there is no more overlap in tooling
    used there

  • Following the kilo reform, the stable team is now focused on
    defining and enforcing a common stable branch policy[1], rather
    than approving every patch. Being more visible and having more
    dedicated members can only help in that very specific mission

  • The release team is now headed by Doug Hellmann, who is focused
    on release management and does not have the history I had with
    stable branch policy. So it might be the right moment to refocus
    release management solely on release management and get the stable
    team its own leadership

  • Empowering that team to make its own decisions, giving it more
    visibility and recognition will hopefully lead to more resources
    being dedicated to it

  • If the team expands, it could finally own stable branch health
    and gate fixing. If that ends up all falling under the same roof,
    that team could make decisions on support timeframes as well,
    since it will be the primary resource to make that work

Isn't this kind of already what the stable maint team does? Well,
that and some QA people like mtreinish and sdague.

So.. good idea ? bad idea ? What do current stable-maint-core[2]
members think of that ? Who thinks they could step up to lead that
team ?

[1]
http://docs.openstack.org/project-team-guide/stable-branches.html
[2] https://review.openstack.org/#/admin/groups/530,members

With the decentralizing of the stable branch stuff in Liberty [1] it
seems like there would be less use for a PTL for stable branch
maintenance - the cats are now herding themselves, right? Or at
least that's the plan as far as I understood it. And the existing
stable branch wizards are more or less around for help and answering
questions.

The same might be said about releasing from master and the release
management team. There's still some benefit to having people dedicated
to making sure projects all agree to sane policies and to keep up with
deliverables that need to be released.

Except the distinction is that relmgt is actually producing something. Relmgt
has the releases repo which does centralize library releases, reno to do the
release notes, etc. What does the global stable core do? Right now it's there
almost entirely to just add people to the project specific stable core teams.

-Matt Treinish

I'd like to move the discussion from what are the roles of the current stable-maint-core and more towards what the benefits would be having a stable-maint team rather than the -core group alone.

Personally I think the stable maintenance should be quite a lot more than unblocking gate and approving people allowed to merge to the stable branches.

Sure, but that's not we're talking about here are we? The other tasks, like
backporting changes for example, have been taken on by project teams. Even in
your other email you mentioned that you've been doing backports and other tasks
that you consider stable maint in a glance only context. That's something we
changed in kilo which ttx referenced in [1] to enable that to happen, and it was
the only way to scale things.

The discussion here is about the cross project effort around stable branches,
which by design is a more limited scope now. Right now the cross project effort
around stable branch policy is really 2 things (both of which ttx already
mentioned):

  1. Keeping the gates working on the stable branches
  2. Defining and enforcing stable branch policy.

The only lever on #2 is that the global stable-maint-core is the only group
which has add permissions to the per project stable core groups. (also the
stable branch policy wiki, but that rarely changes) We specifically shrunk it to
these 2 things in. [1] Well, really 3 things there, but since we're not doing
integrated stable point releases in the future its now only 2.

This is my whole argument that creating a new team doesn't do anything. Living
under rel-mgt, some other project, or creating a new one isn't going to change
the fact that cross-project stable maint is the same 2 tasks which basically
nobody cares about, which TBH your email is just an indication of. Even if we
wanted to grow to something beyond these 2 tasks they would still be the core of
whatever it becomes and a lack of people caring about them will just block any
potential scope growth.

Frankly, this is the problem with any ML or open discussion about stable branch
maint. Everyone has an opinion about everything but lacks actual context or
never steps up to work on the cross-project side of this. I don't think creating
a new team that has no repos or other artifacts and therefore no stackalytics
credit (and by extension corporate chest thumping) is magically going to create
people actually working on this.

The logical follow on idea to the above is to create a stable branch policy doc
repo and a project team to own that. But, I still don't think that solves the
problem, especially since the real priority issue in this space is #1 which
at most is a handful of us bothering to look at that, (well that and the stable
policy barely ever changes) which honestly really isn't the majority of the
stable-maint-core group. We also have a similar problem with gate issues on
master and it's mostly the same people looking at these things there too.

IMHO the only way for creating a separate project team to be useful is to
re-centralize more responsibilities of stable maint, which is something I don't
think we should do because we'll just hit the same scaling issues we had before
kilo which prompted that change in the first place. It's the same problem every
horizontal, cross project, or whatever you want to call it effort has with
OpenStack's growth and why most have moved to the distributed self service
models.

But, if the goal is just to not make Doug responsible for #2, which is something
ttx was primarily doing before, then I guess it's fine but we should be honest
about it and just make ttx the new team leader. :) I honestly don't think
anything else discussed will change by explicitly making it a separate team.

-Matt Treinish


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Nov 10, 2015 by Matthew_Treinish (11,200 points)   2 5 5
...