diff options
Diffstat (limited to 'doc/developer-guide/Guidelines-For-Maintainers.md')
-rw-r--r-- | doc/developer-guide/Guidelines-For-Maintainers.md | 70 |
1 files changed, 0 insertions, 70 deletions
diff --git a/doc/developer-guide/Guidelines-For-Maintainers.md b/doc/developer-guide/Guidelines-For-Maintainers.md deleted file mode 100644 index 71612cfe8c7..00000000000 --- a/doc/developer-guide/Guidelines-For-Maintainers.md +++ /dev/null @@ -1,70 +0,0 @@ -### Guidelines For Maintainers - -GlusterFS has maintainers, sub-maintainers and release maintainers to -manage the project's codebase. Sub-maintainers are the owners for -specific areas/components of the source tree. Maintainers operate across -all components in the source tree.Release maintainers are the owners for -various release branches (release-x.y) present in the GlusterFS -repository. - -In the guidelines below, release maintainers and sub-maintainers are -also implied when there is a reference to maintainers unless it is -explicitly called out. - -### Guidelines that Maintainers are expected to adhere to - -1. Ensure qualitative and timely management of patches sent for review. - -2. For merging patches into the repository, it is expected of -maintainers to: - - a> Merge patches of owned components only. - b> Seek approvals from all maintainers before merging a patchset spanning multiple components. - c> Ensure that regression tests pass for all patches before merging. - d> Ensure that regression tests accompany all patch submissions. - e> Ensure that documentation is updated for a noticeable change in user perceivable behavior or design. - f> Encourage code unit tests from patch submitters to improve the overall quality of the codebase. - g> Not merge patches written by themselves until there is a +2 Code Review vote by other reviewers. - -3. The responsibility of merging a patch into a release branch in -normal circumstances will be that of the release maintainer's. Only in -exceptional situations, maintainers & sub-maintainers will merge patches -into a release branch. - -4. Release maintainers will ensure approval from appropriate -maintainers before merging a patch into a release branch. - -5. Maintainers have a responsibility to the community, it is expected -of maintainers to: - - a> Facilitate the community in all aspects. - b> Be very active and visible in the community. - c> Be objective and consider the larger interests of the community ahead of individual interests. - d> Be receptive to user feedback. - e> Address concerns & issues affecting users. - f> Lead by example. - -### Queries on Guidelines - -Any questions or comments regarding these guidelines can be routed to -gluster-devel at gluster dot org. - -### Patches in Gerrit - -Gerrit can be used to list patches that need reviews and/or can get -merged. Some queries have been prepared for this, edit the search box in -Gerrit to make your own variation: - -- [3.5 open reviewed/verified (non - rfc)](http://review.gluster.org/#/q/project:glusterfs+branch:release-3.5+status:open+%28label:Code-Review%253D%252B1+OR+label:Code-Review%253D%252B2+OR+label:Verified%253D%252B1%29+NOT+topic:rfc+NOT+label:Code-Review%253D-2,n,z) -- [All open 3.5 patches (non - rfc)](http://review.gluster.org/#/q/project:glusterfs+branch:release-3.5+status:open+NOT+topic:rfc,n,z) -- [Open NFS (master - branch)](http://review.gluster.org/#/q/project:glusterfs+branch:master+status:open+message:nfs,n,z) - -An other option can be used in combination with the Gerrit queries, and -has support for filename/directory matching (the queries above do not). -Go to the [settings](http://review.gluster.org/#/settings/projects) in -your Gerrit profile, and enter filters like these: - -![gerrit-watched-projects](https://cloud.githubusercontent.com/assets/10970993/7411584/1a26614a-ef57-11e4-99ed-ee96af22a9a1.png) |