[nova][all][ptg] Summary: Same-Company Approvals

Kashyap Chamarthy kchamart at redhat.com
Thu May 9 11:55:46 UTC 2019


On Sat, May 04, 2019 at 07:19:48PM -0600, Morgan Fainberg wrote:
> On Sat, May 4, 2019, 16:48 Eric Fried <openstack at fried.cc> wrote:
> 
> > (NB: I tagged [all] because it would be interesting to know where other
> > teams stand on this issue.)
> >
> > Etherpad: https://etherpad.openstack.org/p/nova-ptg-train-governance

[Thanks for the summary, Eric; I couldn't be at that session due to a
conflict.]

> > Summary:
> > - There is a (currently unwritten? at least for Nova) rule that a patch
> > should not be approved exclusively by cores from the same company. This
> > is rife with nuance, including but not limited to:
> >   - Usually (but not always) relevant when the patch was proposed by
> > member of same company
> >   - N/A for trivial things like typo fixes
> > - The issue is:
> >   - Should the rule be abolished? and/or
> >   - Should the rule be written down?
> >

[...]

> we opted to really lean on "Overall, we should be able to trust cores
> to act in good faith". 

Indeed.  IME, this is what other mature open source projects do (e.g.
Linux and QEMU, which are in the "critical path" to Nova and OpenStack).

FWIW, over the past six years, I've seen plenty of cases on 'qemu-devel'
(the upstream development list fo the QEMU project) and on KVM list,
where a (non-trivial) patch contribution from company-X is merged by
maintainers from company-X.  Of course, there is the implicit trust in
that the contributor is acting in upstream's best interests first.  (If
not, course-correct and educate.)

    - - -

This Nova "rule" (which, as Eric succintly put it, is "rife with
nuance") doesn't affect me much, if at all.  But allow me share my
stance:

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.

_However_.

If:

  - a particular (non-trivial) change is publicly advertized well-enough
    (2 weeks or more), for the community developers to catch up;

  - all necessary details, context and use cases are described clearly
    in the open, without any assumptions;

  - if you've checked with other non-Pied Piper "cores" if they have any
    strong opinions, and gave them the time to chime in;

  - if the patch receives negative comments, address it without
    hand-waving, explaining in _every_ detail that isn't clear to
    non-Pied Piper reviewers, so that in the end they can come to a
    clear conclusion whether it's right or not;

  - you are working in the best interests of upstream, _even if_ it goes
    against your downstream's interests; i.e. you're sincere and
    sensible when operating with your "upstream hat".

Then, "core" reviewers from Pied Piper _should_ be able to merge a
contribution from Pied Piper (or someone else), without a nauseating
feeling of "you're just one 'wrong sneeze' away from being implicated of
'trust erosion'!" or any artificial "procedural blockers".

Of course, this requires a "heightend sense of awareness", and doing
that delicate tango of balancing "upstream" vs. "downstream" hats.  And
I'd like to imagine contributors and maintainers are constantly striving
towards it.

[...]

-- 
/kashyap



More information about the openstack-discuss mailing list