Versions Compared

Old Version 28

changes.mady.by.user Remi Bergsma

Saved on

compared with

New Version 29

changes.mady.by.user Remi Bergsma

Saved on

Key

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

...

  1. Master needs to be stable at all times
  2. Pull requests will be merged after 2x LGTM and no -1 (we already agreed on thissee below)
  3. When a release is being prepared, master will be “frozen” for new features (we aim to keep this window as short as possible)
  4. Release branch will be branched off of master as soon as a release candidate (RC) vote passes (no more QA on release branches before release)
  5. Bug fixes should be fixed on a release branch first, then merged forward to the next release and finally master. No more cherry-picking!
  6. Only bug fixes will be fixed in release branches, no back porting of new features
  7. We should all use the same scripts to merge pull requests and do forward merges. The tools are located in the CloudStack repository.

...

Note
titleAbout LGTM

LGTM, "Looks Good To Me" is given once a reviewer of a Pull Requests gives an OK to proceed.

At least one of the reviews needs to run the Marvin integration tests and post output of a successful run. This is to prevent regression. Another review can then focus on the code itself, for example.
Should running the Marvin tests make no sense (for example when the Pull Request only changes the UI), the reviewer should post other "proof" that it worked for him, like a screenshot.

Before merging, any open questions and comments should be addressed.

Pull Requests that fail these the above requirements and are merged anyway, will be reverted. 

...