Open Stack

Morgan Fainberg <morgan.fainberg at gmail.com> 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

I didn't pipe up during the PTG discussion because a) I missed the
first 5-10 minutes and hence probably some important context, and
b) I've not been a nova contributor long enough to be well-informed on
this topic.  Apologies if that was the wrong decision.

But I do have a few thoughts on this, which I'll share below.  Given
b), take them with a pinch of salt ;-)

Firstly, I was impressed with the way this topic was raised and discussed,
and I think that is a very encouraging indicator for the current health
of nova contributor culture.  We're in a good place :-)

>> 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):

[snipped]

>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 "Overall,
>we should be able to trust cores to act 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.
>
>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.

+1 - I'm not wildly enthusiastic about the "keep it undocumented"
approach either.

Here's my stab at handling some of the objections to a written policy.

>> - The rule should not be documented (this email notwithstanding). This
>> would either encourage loopholing

I don't see why the presence of a written rule would encourage people
to deliberately subvert upstream trust any more than they might
otherwise do.

And a rule with loopholes is still a better deterrent than no rule at
all.  This is somewhat true for deliberate subversions of trust (which
I expect are non-existent or at least extremely rare), but especially
true for accidental subversions of trust which could otherwise happen
quite easily due to not fully understanding how upstream works.

>> or turn into a huge detailed legal tome that nobody will read.

I don't think it has to.  It's not a legal document, so there's no
need to attempt to make it like one.  If there are loopholes which
can't easily be covered by a simple rewording, then so be it.  If the
policy only catches 50% of cases, it's still helping.  So IMHO the
existence of loopholes doesn't justify throwing the baby out with the
bathwater.

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

I agree that enforcement would be difficult and awkward, and that we
should be able to trust cores.  But in the unlikely and unfortunate
situation that a problem arose in this space, the lack of a written
policy wouldn't magically solve that problem.  in fact it would make
it even *harder* to deal with, because there'd be nothing to point to
in order to help explain to the offender what they were doing wrong.
That would automatically make any judgement appear more subjective
than objective, and therefore more prone to being taken personally.