Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

As passed by the illumos Developers' Council on May 16, 2012

 

All integrations into illumos must be approved by an RTI advocate.  RTI advocates are trusted to uphold the ideals of illumos: quality, utility and innovation -- all from a whole-system perspective.  Of these, quality is the most essential constraint:  advocates must not accept an RTI until they are satisfied that every reasonable step has been taken to assure correctness.

To assure correctness, they may:

- Ask for additional or particular testing

- Ask for more code reviewers

- Ask for code reviewers with particularly mastery

- Ask for code review from those of different corporate affiliation

- Ask for particular code reviewers

- Ask for public code review

Beyond the correctness of a proposed change, RTI advocates must seek to answer the essential question:  is this desired change?  If an RTI advocate cannot answer in the unequivocal affirmative, they may:

- Ask for comments on appropriateness from those with particular mastery

- Ask for comments on appropriateness from those of different affiliation

- Ask for comments on appropriateness from particular people

- Ask for comments on appropriateness from the broader community

- Ask for comments on appropriateness from other advocates

- Demand additional approval of other advocates

- Seek out discussion with other advocates

- Require approval from the Developer Council

In general, RTI advocates that are uncertain should seek out their peers for guidance (or for a more appropriate advocate).  And of course, RTI advocates are empowered to reject RTIs that are clearly inappropriate for the system or that violate the ideals of illumos.  RTI advocates are further empowered to explicitly delay or deprioritize review on RTIs that are of dubious value, or to redirect RTIs to other advocates who would better understand the value of the proposed change.

In short, RTI advocates are trusted to make the right decision for the system and (perhaps more importantly) to have the humility to know when they are not the right person to make that decision.  As such, the selection and endorsement of advocates must done carefully and deliberately by the Developer Council.

What if RTI advocates fail in this regard?  That is, what if RTI advocates come into dispute, after a change has integrated, about the appropriateness of the change?  In this case (which, if experience is any guide, should be quite rare), the approving RTI advocate(s) should be approached by the disapproving advocate(s).  Experience indicates that consensus is highly likely at this point: both advocates are likely to agree that the change in question either is, in fact, appropriate, or should be backed out until it is modified or tested in an agreed-upon fashion.

If, however, consensus cannot be reached and a third advocate agrees that the change is ill-advised, the change should be pulled until all three advocates can reach consensus: in other words, two dissenting advocates lead to an automatic backout of the code in question until disagreement can be resolved. 

If, after this further deliberation, consensus still cannot be reached -- and if the original approving RTI advocate believes that the two disapproving RTI advocates are, in fact, mistaken -- appeal may be made to the Developer Council.  During any pending appeal for adjudication from the Developer Council, the change in question should remain out of the system.