Open Stack

On Sat, May 4, 2019 at 6:48 PM 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
>
> 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?
>
> Consensus (not unanimous):
> - The rule should not be abolished. There are cases where both the
> impetus and the subject matter expertise for a patch all reside within
> one company. In such cases, at least one core from another company
> should still be engaged and provide a "procedural +2" - much like cores
> proxy SME +1s when there's no core with deep expertise.
> - If there is reasonable justification for bending the rules (e.g. typo
> fixes as noted above, some piece of work clearly not related to the
> company's interest, unwedging the gate, etc.) said justification should
> be clearly documented in review commentary.
> - The rule should not be documented (this email notwithstanding). This
> would either encourage loopholing or turn into a huge detailed legal
> tome that nobody will read. It would also *require* enforcement, which
> is difficult and awkward. Overall, we should be able to trust cores to
> act in good faith and in the appropriate spirit.
>
> efried
> .
>

In ironic-land, we documented this [1] many moons ago. Whether that is
considered a rule or a guideline, I don't know, but we haven't been sued
yet and I don't recall any heated arguments/incidents about it. :)

--ruby

[1] https://wiki.openstack.org/wiki/Ironic/CoreTeam#Other_notes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190510/832cf256/attachment.html>