[nova] feasibility to keep the two-company rule
Hi, Nova has an unwritten rule that requires to have at least two companies involved in any new feature development (or even bugfix?). In the current Nova core diversity situation this rule puts extra burden to the remaining non Red Hat cores and I guess it also makes any Red Hat driven feature development harder. In parallel to working on increasing the size of the core team I suggest to reconsider dropping this rule. Some discussion happened already on the today's meeting[1]. Cheers, gibi [1] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-03-19-16.00.log....
On Mar 19, 2020, at 12:23 PM, Balázs Gibizer <balazs.gibizer@est.tech> wrote:
Hi,
Nova has an unwritten rule that requires to have at least two companies involved in any new feature development (or even bugfix?). In the current Nova core diversity situation this rule puts extra burden to the remaining non Red Hat cores and I guess it also makes any Red Hat driven feature development harder. In parallel to working on increasing the size of the core team I suggest to reconsider dropping this rule.
Some discussion happened already on the today's meeting[1]
I think that’s a great idea. FWIW I’ve never liked that rule, because it assume that developers from a company are putting employer requirements over project requirements when acting in their capacity as a core reviewer - which is contrary to our general expectation of how a core reviewer behaves. I think it’s a great idea to get rid of this policy - and then if anyone is behaving in a manner that abuses the trust of the rest of the core reviewers, such as slamming through a new feature that other people obviously have misgivings about … that can be dealt with the same way any other breach of trust would happen.
Cheers, gibi
[1] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-03-19-16.00.log....
Hi, On Thu, Mar 19, 2020 at 02:06:51PM -0500, Monty Taylor wrote:
On Mar 19, 2020, at 12:23 PM, Balázs Gibizer <balazs.gibizer@est.tech> wrote:
Hi,
Nova has an unwritten rule that requires to have at least two companies involved in any new feature development (or even bugfix?). In the current Nova core diversity situation this rule puts extra burden to the remaining non Red Hat cores and I guess it also makes any Red Hat driven feature development harder. In parallel to working on increasing the size of the core team I suggest to reconsider dropping this rule.
Some discussion happened already on the today's meeting[1]
I think that’s a great idea. FWIW I’ve never liked that rule, because it assume that developers from a company are putting employer requirements over project requirements when acting in their capacity as a core reviewer - which is contrary to our general expectation of how a core reviewer behaves.
We are doing it exactly like that in Neutron and IMHO it works pretty good so far :)
I think it’s a great idea to get rid of this policy - and then if anyone is behaving in a manner that abuses the trust of the rest of the core reviewers, such as slamming through a new feature that other people obviously have misgivings about … that can be dealt with the same way any other breach of trust would happen.
Cheers, gibi
[1] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-03-19-16.00.log....
-- Slawek Kaplonski Senior software engineer Red Hat
---- On Thu, 19 Mar 2020 14:06:51 -0500 Monty Taylor <mordred@inaugust.com> wrote ----
On Mar 19, 2020, at 12:23 PM, Balázs Gibizer <balazs.gibizer@est.tech> wrote:
Hi,
Nova has an unwritten rule that requires to have at least two companies involved in any new feature development (or even bugfix?). In the current Nova core diversity situation this rule puts extra burden to the remaining non Red Hat cores and I guess it also makes any Red Hat driven feature development harder. In parallel to working on increasing the size of the core team I suggest to reconsider dropping this rule.
Some discussion happened already on the today's meeting[1]
I think that’s a great idea. FWIW I’ve never liked that rule, because it assume that developers from a company are putting employer requirements over project requirements when acting in their capacity as a core reviewer - which is contrary to our general expectation of how a core reviewer behaves.
I think it’s a great idea to get rid of this policy - and then if anyone is behaving in a manner that abuses the trust of the rest of the core reviewers, such as slamming through a new feature that other people obviously have misgivings about … that can be dealt with the same way any other breach of trust would happen.
+1, Well explained by Monty. -gmann
Cheers, gibi
[1] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-03-19-16.00.log....
On Thu, Mar 19, 2020 at 02:06:51PM -0500, Monty Taylor wrote:
On Mar 19, 2020, at 12:23 PM, Balázs Gibizer <balazs.gibizer@est.tech> wrote:
Hi,
Nova has an unwritten rule that requires to have at least two companies involved in any new feature development (or even bugfix?). In the current Nova core diversity situation this rule puts extra burden to the remaining non Red Hat cores and I guess it also makes any Red Hat driven feature development harder. In parallel to working on increasing the size of the core team I suggest to reconsider dropping this rule.
Some discussion happened already on the today's meeting[1]
I think that’s a great idea. FWIW I’ve never liked that rule, because it assume that developers from a company are putting employer requirements over project requirements when acting in their capacity as a core reviewer - which is contrary to our general expectation of how a core reviewer behaves.
Yes, I'm with Monty here — on both it not being a stellar idea from the start, and removing the rule now, being forced by the current reality. We've talked about this ad nauseum before; so I'll just to link to my reasoning in this thread, after Denver-II PTG): http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006080.html – [nova][all][ptg] Summary: Same-Company Approvals
I think it’s a great idea to get rid of this policy - and then if anyone is behaving in a manner that abuses the trust of the rest of the core reviewers, such as slamming through a new feature that other people obviously have misgivings about … that can be dealt with the same way any other breach of trust would happen.
Yep, exactly. To quote myself from the above e-mail thread: [...] I'm of course all for diverse set of opinions and reviews from different companies as much as posisble, which I consider super healthy. So long as there are no overly iron-clad "rules" that are "unbendable". What _should_ raise a red flag is a _pattern_. E.g. Developer-A from the company Pied Piper uploads a complex change, within a couple of days (or worse, even shorter), two more upstream "core" reivewers from Pied Piper, who are in the know about the change, pile on it and approve without giving sufficient time for other community reviewers to catch-up. (Because: "hey, we need to get Pied Piper's 'priority feature' into the current release, to get that one-up against the competitor!") *That* kind of behaviour should be called out and rebuked. [...] -- /kashyap
Hi, Top posting to summarize public and private discussions. As far as I see overall we agree that the "rule" needs to be less strict. But as far as I understand we have no consensus in the core team to drop the rule entirely. We still would like to keep some of level of control over heavy changes. Where heavy means anything that involves a microversion, service version, rpc version, or database migration. I imagine that these changes need an spec anyhow so the existence of a spec could be a shorthand for when the rule still applies. In the other hand this means that the implementation of specless features, bugfixes, doc enhancements, test enhancements, and refactors can be developed and approved by a single company (but still require two core reviewers). Personally I'm OK with this compromise along with the ongoing effort to add new people to the core team. As this is an unwritten rule I'm not proposing any doc changes to nova to describe this. This mail serves as the official proposal and if there is no major concerns raised against it then this will goes into effect next Tuesday (03.31.) (having an unwritten rule feels so backward to me) Cheers, gibi
On 3/19/20 10:23, Balázs Gibizer wrote:
Hi,
Nova has an unwritten rule that requires to have at least two companies involved in any new feature development (or even bugfix?). In the current Nova core diversity situation this rule puts extra burden to the remaining non Red Hat cores and I guess it also makes any Red Hat driven feature development harder. In parallel to working on increasing the size of the core team I suggest to reconsider dropping this rule.
I have historically always appreciated the two-company approval rule because it ensures each patch has been reviewed with at least two different and diverse company perspectives. However I recognize that the situation has changed over time and we may not have the luxury any longer to ensure diverse company approvals. I do not wish to overburden the remaining non Red Hat cores with review requests for approvals. So, given the evolved landscape, I am understanding and open to adapt our process to drop the two-company rule if there is such consensus in the rest of the team. Cheers, -melanie
Some discussion happened already on the today's meeting[1].
Cheers, gibi
[1] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-03-19-16.00.log....
Melanie, Good topic here: On 3/19/2020 3:48 PM, melanie witt wrote:
On 3/19/20 10:23, Balázs Gibizer wrote:
Hi,
Nova has an unwritten rule that requires to have at least two companies involved in any new feature development (or even bugfix?). In the current Nova core diversity situation this rule puts extra burden to the remaining non Red Hat cores and I guess it also makes any Red Hat driven feature development harder. In parallel to working on increasing the size of the core team I suggest to reconsider dropping this rule.
Cinder has also followed this rule in the past but I think that the enforcement has slipped as our pool of cores has gotten smaller. I have not seen it cause any issues.
I have historically always appreciated the two-company approval rule because it ensures each patch has been reviewed with at least two different and diverse company perspectives.
I think, historically this was also intended to prevent one company from unfairly imposing its will upon the community. Now that development has slowed and wills are not so strong I think this is less of a concern.
However I recognize that the situation has changed over time and we may not have the luxury any longer to ensure diverse company approvals. I do not wish to overburden the remaining non Red Hat cores with review requests for approvals.
So, given the evolved landscape, I am understanding and open to adapt our process to drop the two-company rule if there is such consensus in the rest of the team.
Support this if there is consensus from the team.
Cheers, -melanie
Some discussion happened already on the today's meeting[1].
Cheers, gibi
[1] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-03-19-16.00.log....
On Thu, Mar 19, 2020 at 4:51 PM melanie witt <melwittt@gmail.com> wrote:
On 3/19/20 10:23, Balázs Gibizer wrote:
Hi,
Nova has an unwritten rule that requires to have at least two companies involved in any new feature development (or even bugfix?). In the current Nova core diversity situation this rule puts extra burden to the remaining non Red Hat cores and I guess it also makes any Red Hat driven feature development harder. In parallel to working on increasing the size of the core team I suggest to reconsider dropping this rule.
I have historically always appreciated the two-company approval rule because it ensures each patch has been reviewed with at least two different and diverse company perspectives.
Same here. It was never really a matter of preventing abuse by a single company - I trust the RH cores to not have ill intentions - it was more to guarantee a diverse set of perspectives on any given patch. Sometimes we wear blinders without even knowing, and it's good to get a reality check.
However I recognize that the situation has changed over time and we may not have the luxury any longer to ensure diverse company approvals. I do not wish to overburden the remaining non Red Hat cores with review requests for approvals.
Speaking of reality, we have to recognize it as it is, not as we'd like it to be. And it's just not realistic to have every single RH patch go through gibi or Alex.
So, given the evolved landscape, I am understanding and open to adapt our process to drop the two-company rule if there is such consensus in the rest of the team.
FWIW I agree the two company rule no longer makes sense.
Cheers, -melanie
Some discussion happened already on the today's meeting[1].
Cheers, gibi
[1] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-03-19-16.00.log....
On 19-03-20 18:23:50, Balázs Gibizer wrote:
Hi,
Nova has an unwritten rule that requires to have at least two companies involved in any new feature development (or even bugfix?). In the current Nova core diversity situation this rule puts extra burden to the remaining non Red Hat cores and I guess it also makes any Red Hat driven feature development harder. In parallel to working on increasing the size of the core team I suggest to reconsider dropping this rule.
Some discussion happened already on the today's meeting[1].
Cheers, gibi
[1] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-03-19-16.00.log....
Thanks again for raising this gibi! +1 from me, while this topic has been discussed at length many times now I agree that given the current core diversity situation we need to look at this again. I would personally be happy to see the rule dropped for the time being while in parallel we also try to increase the pool of cores from outside of RH. Cheers, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
Absolutely. Very good rule to follow. -----Original Message----- From: Lee Yarwood <lyarwood@redhat.com> Sent: Friday, March 20, 2020 5:34 AM To: Balázs Gibizer Cc: OpenStack Discuss Subject: Re: [nova] feasibility to keep the two-company rule On 19-03-20 18:23:50, Balázs Gibizer wrote:
Hi,
Nova has an unwritten rule that requires to have at least two companies involved in any new feature development (or even bugfix?). In the current Nova core diversity situation this rule puts extra burden to the remaining non Red Hat cores and I guess it also makes any Red Hat driven feature development harder. In parallel to working on increasing the size of the core team I suggest to reconsider dropping this rule.
Some discussion happened already on the today's meeting[1].
Cheers, gibi
[1] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-03-19-16.0 0.log.html#l-90
Thanks again for raising this gibi! +1 from me, while this topic has been discussed at length many times now I agree that given the current core diversity situation we need to look at this again. I would personally be happy to see the rule dropped for the time being while in parallel we also try to increase the pool of cores from outside of RH. Cheers, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
participants (10)
-
Arkady.Kanevsky＠dell.com
-
Artom Lifshitz
-
Balázs Gibizer
-
Ghanshyam Mann
-
Jay S. Bryant
-
Kashyap Chamarthy
-
Lee Yarwood
-
melanie witt
-
Monty Taylor
-
Slawek Kaplonski