Merging branches

Bigger features usually developed on feature branches in Apache Ozone. Feature branches are merged after formal vote on the Ozone dev mailing list while contributors test the new feature to keep Ozone stable and safe.

This document collects a few points to check before the merge, to make it easier to find possible problems in advance. 

Checklist

This section collects generic questions which can be checked for each feature branch. Some of them are obvious for some branches (for example: decommissioning feature didn't change the number of the components or the s3 interface) but it's good to go through of them for each of the merges. Answering the questions may also help the community to test the branch, therefore it can be useful to include similar information in the merge mail. If you have any new idea about what should be checked, please add it to the list.

stable builds/intermittent test failures: To keep the master branch stable as much as possible, it's recommended to run full CI build multiple times on the latest commit, proposed to be merged. The best to run 3-5 times, and they should be passed (any failure should be analyzed and collect previous failures on master, if it's unrelated to the branch)

acceptance tests: For bigger features we create acceptance test suite to the compose/ smoketest/ folders. It can help to keep the stability of the new feature AND can help to use an example for configuring/using the new feature in addition to the documentation.

documentation: adding at least a basic level documentation before the merge may significant help the community to test the new feature. As writing initial documentation is just a few hours effort, it's best to write it earlier. 

design, attached the docs: Some internal design details are documented in the design docs. Ozone doc contains a section with the list of all the designs (for example: https://ci-hadoop.apache.org/view/Hadoop%20Ozone/job/ozone-doc-master/lastSuccessfulBuild/artifact/hadoop-hdds/docs/public/design.html). To make the original design doc easily accessible it's good to add a simple link (or full text) to the hadoop-hdds/docs/content/design. There we can also add additional notes (for example if some parts of the design doc is already out-dated it can be noted).

s3 compatibility: Today we try to provide 100% S3 compatibility by mimicking the original AWS S3 when ozone.om.enable.filesystem.paths=false (default). When it's enabled full s3 guarantees couldn't be provided as better Hadoop compatibility is favored.

support of containers / kubernetes: Today we have a full test suite / example deployments under the Kubernetes subdirectory. Most of the time it works out of the box, but in case of complex, new features it may be required to slightly update them

coverage/code quality: Coverage and code quality data is collected by Sonar. It's good to have the information of how these numbers are changing before the merge.

build time: Another critical part is the build time. As more and more Apache project uses github actions the available resource will be less and less. We should keep track of the used build hours, and we should avoid significant increase of the build time unless it's fully necessary.

possible incompatible changes/used feature flag: Since 1.1 Ozone supposed to be backward compatible. Any incompatible changes should be avoided. Experimental new features can be turned off by default with new feature flags. And new scheme changes should be compatible with the (WIP) upgrade framework. 

Merge

Please do NOT use github squash or rebase feature the merge feature branches. The records of multiple month of developments (Github PR and Jira discussions) are linked to the original commit ids. To keep them we should use simple git merge to merge branches.