Versions Compared

Key

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

...

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. 
  • 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 must have 100% test coverage.

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

 

3.  JIRA

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

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

...