[nova] stable-maint is especially unhealthily RH-centric
During the trifecta discussions at PTG I was only considering nova-core. I didn't appreciate at the time how bad the situation is for nova-stable-maint. nova-stable-maint currently consists of:
https://review.opendev.org/#/admin/groups/540,members https://review.opendev.org/#/admin/groups/530,members
Not Red Hat: Claudiu Belu -> Inactive? Matt Riedemann John Garbutt Matthew Treinish
Red Hat: Dan Smith Lee Yarwood Sylvain Bauza Tony Breeds Melanie Witt Alan Pevec Chuck Short Flavio Percoco Tony Breeds
This leaves Nova entirely dependent on Matt Riedemann, John Garbutt, and Matthew Treinish to land patches in stable, which isn't a great situation. With Matt R temporarily out of action that's especially bad.
Looking for constructive suggestions. I'm obviously in favour of relaxing the trifecta rules, but adding some non-RH stable cores also seems like it would be a generally healthy thing for the project to do.
Matt
On 5/21/2019 11:16 AM, Matthew Booth wrote:
Not Red Hat: Claudiu Belu -> Inactive? Matt Riedemann John Garbutt Matthew Treinish
Sean McGinnis is on the release management team which is a (grand)parent group to nova-stable-maint and Sean reviews nova stable changes from time to time or as requested, but he's currently in the same boat as me.
Red Hat: Dan Smith Lee Yarwood Sylvain Bauza Tony Breeds Melanie Witt Alan Pevec > Chuck Short Flavio Percoco
Alan, Chuck and Flavio are all in the parent stable-maint-core group but also inactive as far as I know. FWIW the most active nova stable cores are myself, Lee and Melanie. I ping Dan and Sylvain from time to time as needed on specific changes or if I'm trying to flush a branch for a release.
Tony Breeds
This leaves Nova entirely dependent on Matt Riedemann, John Garbutt, and Matthew Treinish to land patches in stable, which isn't a great situation. With Matt R temporarily out of action that's especially bad.
This is a bit of an exaggeration. What you mean is that it leaves backports from Red Hat stuck(ish) because we want to avoid two RH cores from approving the backport. However, it doesn't mean 2 RH cores can't approve a backport from someone else, like something I backport for example.
Looking for constructive suggestions. I'm obviously in favour of relaxing the trifecta rules, but adding some non-RH stable cores also seems like it would be a generally healthy thing for the project to do.
I've started a conversation about this within the nova-stable-maint team but until there are changes I think it's fair to say if you really need something that is backported from RH (like Lee backports something) then we can ping non-RH people to approve (like mtreinish or johnthetubaguy) or wait for me to get out of /dev/jail.
On Tue, May 21, 2019, 16:32 Matt Riedemann, mriedemos@gmail.com wrote:
On 5/21/2019 11:16 AM, Matthew Booth wrote:
Not Red Hat: Claudiu Belu -> Inactive? Matt Riedemann John Garbutt Matthew Treinish
Sean McGinnis is on the release management team which is a (grand)parent group to nova-stable-maint and Sean reviews nova stable changes from time to time or as requested, but he's currently in the same boat as me.
Wait, did I miss something? We at RH were told it was business as usual with respect to upstream community collaboration with Huawei.
Red Hat: Dan Smith Lee Yarwood Sylvain Bauza Tony Breeds Melanie Witt Alan Pevec > Chuck Short Flavio Percoco
Alan, Chuck and Flavio are all in the parent stable-maint-core group but also inactive as far as I know. FWIW the most active nova stable cores are myself, Lee and Melanie. I ping Dan and Sylvain from time to time as needed on specific changes or if I'm trying to flush a branch for a release.
Tony Breeds
This leaves Nova entirely dependent on Matt Riedemann, John Garbutt, and Matthew Treinish to land patches in stable, which isn't a great situation. With Matt R temporarily out of action that's especially bad.
This is a bit of an exaggeration. What you mean is that it leaves backports from Red Hat stuck(ish) because we want to avoid two RH cores from approving the backport. However, it doesn't mean 2 RH cores can't approve a backport from someone else, like something I backport for example.
Looking for constructive suggestions. I'm obviously in favour of relaxing the trifecta rules, but adding some non-RH stable cores also seems like it would be a generally healthy thing for the project to do.
I've started a conversation about this within the nova-stable-maint team but until there are changes I think it's fair to say if you really need something that is backported from RH (like Lee backports something) then we can ping non-RH people to approve (like mtreinish or johnthetubaguy) or wait for me to get out of /dev/jail.
--
Thanks,
Matt
On Wed, May 22, 2019 at 12:34:22PM -0400, Artom Lifshitz wrote:
On Tue, May 21, 2019, 16:32 Matt Riedemann, mriedemos@gmail.com wrote:
On 5/21/2019 11:16 AM, Matthew Booth wrote:
Not Red Hat: Claudiu Belu -> Inactive? Matt Riedemann John Garbutt Matthew Treinish
Sean McGinnis is on the release management team which is a (grand)parent group to nova-stable-maint and Sean reviews nova stable changes from time to time or as requested, but he's currently in the same boat as me.
Wait, did I miss something? We at RH were told it was business as usual with respect to upstream community collaboration with Huawei.
We had been told internally to hold off for awhile, but I believe the OSF and our internal teams have done all the due diligence they've needed to make sure we are in the clear as far as participating upstream. Our team should be more active again.
Great to hear that is what RH has communicated as well. If anyone else has any concerns I can try to track down answers.
Sean
Hi,
I was thinking to answer here... What I see is that more projects struggle sometimes with having enough and quick stable reviews as cores are busy with the development track. I know that to become a stable core for a project needs to be a core of that project already and to know stable rules. My question is: wouldn't it be possible to someone who proves that he/she knows and follows the stable rules could be a stable core without being a core before? Maybe it could be enough or just make the projects life easier if for example one +2 could come from a person who is 'just' a stable core and one is necessary to come from a core both in stable and in 'master' on that project.
I'm writing this because I mostly deal with stable patches (reviewing + bugfix backporting + fixing periodic job problems in various projects, also in nova) and for example I would volunteer to help with stable reviews as I am aware of stable rules (at least I believe so :)). I'm working like this because my employer, Ericsson, wants to strengthen stable and extended maintenance of OpenStack, too.
What do you think about this kind of stable cores?
Thanks,
Előd
On 2019. 05. 21. 18:16, Matthew Booth wrote:
During the trifecta discussions at PTG I was only considering nova-core. I didn't appreciate at the time how bad the situation is for nova-stable-maint. nova-stable-maint currently consists of:
https://protect2.fireeye.com/url?k=cef2d936-9226d444-cef299ad-86859b2931b3-f... https://protect2.fireeye.com/url?k=2f4a8d4b-739e8039-2f4acdd0-86859b2931b3-6...
Not Red Hat: Claudiu Belu -> Inactive? Matt Riedemann John Garbutt Matthew Treinish
Red Hat: Dan Smith Lee Yarwood Sylvain Bauza Tony Breeds Melanie Witt Alan Pevec Chuck Short Flavio Percoco Tony Breeds
This leaves Nova entirely dependent on Matt Riedemann, John Garbutt, and Matthew Treinish to land patches in stable, which isn't a great situation. With Matt R temporarily out of action that's especially bad.
Looking for constructive suggestions. I'm obviously in favour of relaxing the trifecta rules, but adding some non-RH stable cores also seems like it would be a generally healthy thing for the project to do.
Matt
On Thu, 2019-05-23 at 17:01 +0000, Elõd Illés wrote:
Hi,
I was thinking to answer here... What I see is that more projects struggle sometimes with having enough and quick stable reviews as cores are busy with the development track. I know that to become a stable core for a project needs to be a core of that project already and to know stable rules. My question is: wouldn't it be possible to someone who proves that he/she knows and follows the stable rules could be a stable core without being a core before?
we have stable cores in nova that are not cores on nova.
the cirtria for stable cores are similar to normal cores
show up, do good reviews, and always keep in mind if the backport followst the stable policy.
if you do that then you can become a stable core without ever needing to review a patch on master. that said reviews on master never hurt.
Maybe it could be enough or just make the projects life easier if for example one +2 could come from a person who is 'just' a stable core and one is necessary to come from a core both in stable and in 'master' on that project.
I'm writing this because I mostly deal with stable patches (reviewing + bugfix backporting + fixing periodic job problems in various projects, also in nova) and for example I would volunteer to help with stable reviews as I am aware of stable rules (at least I believe so :)). I'm working like this because my employer, Ericsson, wants to strengthen stable and extended maintenance of OpenStack, too.
What do you think about this kind of stable cores?
Thanks,
Előd
On 2019. 05. 21. 18:16, Matthew Booth wrote:
During the trifecta discussions at PTG I was only considering nova-core. I didn't appreciate at the time how bad the situation is for nova-stable-maint. nova-stable-maint currently consists of:
https://protect2.fireeye.com/url?k=cef2d936-9226d444-cef299ad-86859b2931b3-f...
https://protect2.fireeye.com/url?k=2f4a8d4b-739e8039-2f4acdd0-86859b2931b3-6...
Not Red Hat: Claudiu Belu -> Inactive? Matt Riedemann John Garbutt Matthew Treinish
Red Hat: Dan Smith Lee Yarwood Sylvain Bauza Tony Breeds Melanie Witt Alan Pevec Chuck Short Flavio Percoco Tony Breeds
This leaves Nova entirely dependent on Matt Riedemann, John Garbutt, and Matthew Treinish to land patches in stable, which isn't a great situation. With Matt R temporarily out of action that's especially bad.
Looking for constructive suggestions. I'm obviously in favour of relaxing the trifecta rules, but adding some non-RH stable cores also seems like it would be a generally healthy thing for the project to do.
Matt
On 5/23/2019 12:01 PM, Elõd Illés wrote:
I know that to become a stable core for a project needs to be a core of that project already and to know stable rules. My question is: wouldn't it be possible to someone who proves that he/she knows and follows the stable rules could be a stable core without being a core before?
This isn't true. tonyb and lyarwood are not nova core but are stable core for nova.
On Thu, May 23, 2019 at 05:01:01PM +0000, Elõd Illés wrote:
Hi,
I was thinking to answer here... What I see is that more projects struggle sometimes with having enough and quick stable reviews as cores are busy with the development track. I know that to become a stable core for a project needs to be a core of that project already and to know stable rules. My question is: wouldn't it be possible to someone who proves that he/she knows and follows the stable rules could be a stable core without being a core before? Maybe it could be enough or just make the projects life easier if for example one +2 could come from a person who is 'just' a stable core and one is necessary to come from a core both in stable and in 'master' on that project.
Sean and Matt have both answered this. I'd just like to add that the Extended Maintenance policy was designed to encourage this so by all means go forth and do good stable reviews :)
Yours Tony.
Thanks for the responses and sorry for the misleading info. Thanks Tony, will do. :)
Thanks,
Előd
On 2019. 05. 24. 1:55, Tony Breeds wrote:
On Thu, May 23, 2019 at 05:01:01PM +0000, Elõd Illés wrote:
Hi,
I was thinking to answer here... What I see is that more projects struggle sometimes with having enough and quick stable reviews as cores are busy with the development track. I know that to become a stable core for a project needs to be a core of that project already and to know stable rules. My question is: wouldn't it be possible to someone who proves that he/she knows and follows the stable rules could be a stable core without being a core before? Maybe it could be enough or just make the projects life easier if for example one +2 could come from a person who is 'just' a stable core and one is necessary to come from a core both in stable and in 'master' on that project.
Sean and Matt have both answered this. I'd just like to add that the Extended Maintenance policy was designed to encourage this so by all means go forth and do good stable reviews :)
Yours Tony.
participants (7)
-
Artom Lifshitz
-
Elõd Illés
-
Matt Riedemann
-
Matthew Booth
-
Sean McGinnis
-
Sean Mooney
-
Tony Breeds