Open Stack

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 at 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