[nova] feasibility to keep the two-company rule

Artom Lifshitz alifshit at redhat.com
Mon Mar 23 12:41:28 UTC 2020


On Thu, Mar 19, 2020 at 4:51 PM melanie witt <melwittt at 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.html#l-90
> >
> >
> >
> >
> >
>
>




More information about the openstack-discuss mailing list