Versions Compared

Old Version 8

changes.mady.by.user Joss Armstrong

Saved on

compared with

New Version 9

changes.mady.by.user Kenny Paul

Saved on

Key

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

...

To start the promotion process, please use the Committer Request Templatecreate a new page by clicking the 3 dots next to the create button and select the  Committer Request Template as shown below. After that follow these instructions Committer Management Automation via INFO.yaml:   

Image Added


Best Practices

  • Committers should not are prohibited from a "self merge" of their own changes
    refer to

    https://lists.onap.org/pipermail/onap-discuss/2018-February/008068.html

    https://lists.onap.org/pipermail/onap-discuss/2018-February/008181.html

    https://lists.onap.org/pipermail/onap-tsc/2017-May/002341.html

    TSC 2018-03-08


    • Committers should add other committers as reviewers and have at least 2 Committers show approval (with a +1). The first reviewing committer will +1, the second reviewing committer will +2.
    • One exception to the rule is self merging critical changes required to unblock broken builds - maybe.
  • Committers should only merge proposed changes from contributors after at least 2 (+1) reviews.
  • Committers should remove themselves from a review under the following circumstances: 
    • Committer has been added as a reviewer to a change they do not feel comfortable reviewing
    • Committer anticipates a lack of time to review within 1 week 
  • Committers who remove themselves should leave a short comment in the change explaining to the owner the reason for removal
    • This allows owners opportunity to find others willing to review (or to make changes to significantly simplify or further document change)
  • Committers should aim to review all pending changes which have passed verify, have no merge conflicts or (-1) or (-2) reviews in a timely manner. 
  • Committers are welcome to ignore pending changes which do not pass verify, have merge conflicts or have been reviewed (-1) or (-2).
  • Committers should occasionally review the list of all old changes (To be defined). Owners of old changes should be contacted to ascertain if the change can be abandoned. If change owners do not respond or respond that the change has been abandoned, it should be abandoned.

...