<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>All,</p>
<p>Cinder has been working with the same unwritten rules for quite
some time as well with minimal issues.</p>
<p>I think the concerns about not having it documented are
warranted. We have had question about it in the past with no
documentation to point to. It is more or less lore that has been
passed down over the releases. :-)</p>
<p>At a minimum, having this e-mail thread is helpful. If, however,
we decide to document it I think we should have it consistent
across the teams that use the rule. I would be happy to help
draft/review any such documentation.</p>
<p>Jay<br>
</p>
<div class="moz-cite-prefix">On 5/4/2019 8:19 PM, Morgan Fainberg
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGnj6avKa_rsAY0VxBt79UzquvsoggJZiMf-UU+SKNPYfgChaQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">
<div><br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, May 4, 2019, 16:48
Eric Fried <a class="moz-txt-link-rfc2396E" href="mailto:openstack@fried.cc"><openstack@fried.cc></a> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">(NB: I
tagged [all] because it would be interesting to know where
other<br>
teams stand on this issue.)<br>
<br>
Etherpad: <a
href="https://etherpad.openstack.org/p/nova-ptg-train-governance"
rel="noreferrer noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://etherpad.openstack.org/p/nova-ptg-train-governance</a><br>
<br>
Summary:<br>
- There is a (currently unwritten? at least for Nova) rule
that a patch<br>
should not be approved exclusively by cores from the same
company. This<br>
is rife with nuance, including but not limited to:<br>
- Usually (but not always) relevant when the patch was
proposed by<br>
member of same company<br>
- N/A for trivial things like typo fixes<br>
- The issue is:<br>
- Should the rule be abolished? and/or<br>
- Should the rule be written down?<br>
<br>
Consensus (not unanimous):<br>
- The rule should not be abolished. There are cases where
both the<br>
impetus and the subject matter expertise for a patch all
reside within<br>
one company. In such cases, at least one core from another
company<br>
should still be engaged and provide a "procedural +2" -
much like cores<br>
proxy SME +1s when there's no core with deep expertise.<br>
- If there is reasonable justification for bending the
rules (e.g. typo<br>
fixes as noted above, some piece of work clearly not
related to the<br>
company's interest, unwedging the gate, etc.) said
justification should<br>
be clearly documented in review commentary.<br>
- The rule should not be documented (this email
notwithstanding). This<br>
would either encourage loopholing or turn into a huge
detailed legal<br>
tome that nobody will read. It would also *require*
enforcement, which<br>
is difficult and awkward. Overall, we should be able to
trust cores to<br>
act in good faith and in the appropriate spirit.<br>
<br>
efried<br>
.<br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Keystone used to have the same policy outlined
in this email (with much of the same nuance and exceptions).
Without going into crazy details (as the contributor and core
numbers went down), we opted to really lean on "<span
style="font-family:sans-serif">Overall, we should be able to
trust cores to act</span><span
style="font-family:sans-serif"> in good faith". We abolished
the rule and the cores always ask for outside input when the
familiarity lies outside of the team. We often also pull in
cores more familiar with the code sometimes ending up with
3x+2s before we workflow the patch.</span></div>
<div dir="auto"><span style="font-family:sans-serif"><br>
</span></div>
<div dir="auto"><span style="font-family:sans-serif">Personally
<non-core/non-leadership hat> I don't like the "this
is an unwritten rule and it shouldn't be documented"; if
documenting and enforcement of the rule elicits worry of
gaming the system or being a dense some not read, in my mind
(and experience) the rule may not be worth having. I voice
my opinion with the caveat that every team is different. If
the rule works, and helps the team (Nova in this case) feel
more confident in the management of code, the rule has a
place to live on. What works for one team doesn't always
work for another.</span></div>
</div>
</blockquote>
</body>
</html>