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@gmail.com> wrote:
On Sat, May 4, 2019 at 6:48 PM Eric Fried <openstack@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