Page History

...

• Make sure that your patch satisfies Review Checklist rules.
• Each comment should be started with [~username] to guarantee proper notification.
• Commiter should add comment like "Changes accepted and ready to be merged." once review successfully finished.
• If the commiter/contributor has proposals, it is recommended to add a comment in the ticket in addition to PR / CR comments referring proposals added. This helps other committers to identify that fix has something to improve.

Peer Review and LGTM

After a pull request goes through rounds of reviews and revisions, it will become ready for merge. A reviewer signals their approval either by a JIRA/Dev. List comment such as “Looks good to me!” (LGTM).

• If the author of the pull request is not a committer, a committer must be the one to approve the change.
• If the author of the pull request is a committer, approval from their chosen reviewer is enough. A committer is trusted to choose an appropriate reviewer, even if the reviewer is not a committer.
• Code modifications can be approved by silence: by lazy consensus (72h) after Dev.List announcement.

Once a pull request is approved, any committer can merge it.

Special cases:

• Approval from non-committers is encouraged and this review is contribution to the project/community, but such approval has advisory nature.
• Ticket can have unlimited number of approvals.
• Committers are encouraged to ask other committers for additional review for complex changes.

Exceptions to this rule are rare and made on a case-by-case basis. For example trivial change may be merged by comitter without review.

Closing a Ticket

• Once ticket has passed all the reviews and has no additional comments, a committer should apply the latest patch to the master branch.
• A comment should be added to the ticket stating that the patch has been applied to master.
• Move ticket to RESOLVED state. 

...