Versions Compared

Old Version 24

changes.mady.by.user Matthew Foley

Saved on

compared with

New Version 25

changes.mady.by.user Nick Allen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added section 2.6.1 on inactive pull requests.

...

2.6  Merge requirements

Because Metron is so complex, and the implications of getting it wrong so devastating, Metron has a strict merge policy for committers:

  • Patches must never be pushed directly to master, all changes (even the most trivial typo fixes!) must be submitted as a pull request.
  • A committer may merge their own pull request, but only after a second reviewer has given it a +1. A qualified reviewer is a Metron committer or PPMC member.
  • A non-committer may ask the reviewer to merge their pull request or alternatively post to the Metron dev board to get another committer to merge the PR if the reviewer is not available. 
  • There should be at least one independent party besides the committer that have reviewed the patch before merge.
  • A patch that breaks tests, or introduces regressions by changing or removing existing tests should not be merged. Tests must always be passing on master. This implies that the tests have been run.
  • All pull request submitters must link to travis-ci 
  • If somehow the tests get into a failing state on master (such as by a backwards incompatible release of a dependency) no pull requests may be merged until this is rectified.
  • All merged patches will be reviewed with the expectation that thorough automated tests shall be provided and are consistent with project testing methodology and practices, and cover the appropriate cases ( see reviewers guide )

The purpose of these policies is to minimize the chances we merge a change that has unintended consequences.

2.6.1 Inactive Pull Requests

Contributions can often take a significant amount of time to complete the code review process. This process requires active participation from the contributor. If the contributor is unable to actively participate, the pull request is unlikely to successfully complete this process.

Pull Requests that have failed to receive active participation from the contributor for an extended period of time risk being abandoned. Any committer can submit a request for Apache Infra to close a pull request that has been abandoned according to the following guidelines.

  • A pull request is 'inactive' if no comments or updates have been made by the contributor in the previous 4 weeks.
  • For any 'inactive' pull request, a committer can request from the contributor justification for keeping the pull request open.
  • The committer's request should be made as a public comment on the pull request. The committer should refer the contributor to these development guidelines for inactive pull requests.
  • If the contributor publically responds to the request, the pull request is no longer consider 'inactive'.
  • If the contributor does not respond to the request within 2 weeks, the pull request is considered 'abandoned'.
  • A committer can cast a -1 vote on any 'abandoned' pull request using these development guidelines as justification.
  • A committer can submit a request to Apache Infra to close the 'abandoned' pull request based on this -1 vote.

 

3.  JIRA

  • The Incompatible change flag on the issue's JIRA is set appropriately for this patch  

  • For incompatible changes, major features/improvements, and other release notable issues, the Release Note field has a sufficient comment 

...