Open Stack

Top posting to change the topic slightly: same-company approvals for
the stable branch.

I brought this up at today's Nova meeting, and my takeaway was as
follows. Please correct me if I got something wrong.

1. Judgment! Yes, this is hard to define.
2. If you feel uneasy about merging a thing, don't do it.
3. A backport by a stable-maint core counts as a proxy +2 if the
backport is an obvious bugfix and is clean.
4. We still need 2 +2's on a patch, proxy +2's count towards that.
5. As on master, we should strive to avoid 100% same-company patches.
6. The original patch author counts. A patch from company A can be
approved by 2 cores from company B. One of those cores can be the
backporter, with the caveats in point 3.
7. All of this can be superseded by point 1 if necessary.


On Fri, May 10, 2019 at 1:55 PM Ruby Loo <opensrloo at gmail.com> wrote:
>
>
>
> 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



-- 
Artom Lifshitz
Software Engineer, OpenStack Compute DFG