From 86f914679f5a817bfb890995f2fc0beeeb765b88 Mon Sep 17 00:00:00 2001 From: Ira Cooper Date: Sun, 10 Aug 2014 11:11:26 -0400 Subject: [PATCH] MAINTAINERS: Remove MAINTAINERS.txt Due to the new code review rules, there is no more need for the MAINTAINERS.txt file. Signed-off-by: Ira Cooper Reviewed-by: Jeremy Allison --- MAINTAINERS.txt | 221 -------------------------------------------------------- 1 file changed, 221 deletions(-) delete mode 100644 MAINTAINERS.txt diff --git a/MAINTAINERS.txt b/MAINTAINERS.txt deleted file mode 100644 index 3b6a88a1a49..00000000000 --- a/MAINTAINERS.txt +++ /dev/null @@ -1,221 +0,0 @@ -Samba maintainers ------------------ - -This file lists the maintainers for subsystems in Samba. Please see -the end of the file for information on how the maintainers system -works. If you can't work out who the maintainer is for some code, -please ask on the samba-technical list or on the samba-technical IRC -channel. - - -======================================================================= - -directory: lib/tevent/ -maintainers: - Stefan Metzmacher -policy: - All commits require review by the maintainer. - - If no maintainer is available for longer than a week - discussion on the samba-technical list and review by 2 - Samba-Team members is needed (e.g. Andrew Tridgell - and Volker Lendecke ). - - Larger changes need also discussion on the samba-technical list - and review by all maintainers. - -directory: lib/tsocket/ -maintainers: - Stefan Metzmacher -policy: - All commits require review by the maintainer. - - If no maintainer is available for longer than a week - discussion on the samba-technical list and review by 2 - Samba-Team members is needed. - - Larger changes need also discussion on the samba-technical list - and review by all maintainers. - -files: buildtools/**, source4/**/wscript -maintainers: - Andrew Tridgell - Jelmer Vernooij -policy: - small commits to master allowed if all existing tests - pass. Larger commits require discussion on the samba-technical - list and review by the maintainer - -files: lib/tdb -maintainers: - Rusty Russell -policy: - Mail/CC changes to the maintainer, commit the changes - unless the maintainer objects. - -files: lib/talloc -maintainers: - Andrew Tridgell - Rusty Russell -policy: - small commits to master allowed if all existing tests - pass. Larger commits require discussion on samba-technical - list and review by the maintainer - -files: lib/tevent/py*, lib/talloc/py*, lib/ldb/py*, lib/tdb/py* -maintainers: - Jelmer Vernooij -policy: - Larger commits require pre-push review by the maintainer or - one of the maintainers of the containing subsystem. - - Other non-trivial (typo, etc) commits require pre- or post-push review by the - maintainer or one of the maintainers of the containing subsystem. - -files: lib/ccan -maintainers: - Rusty Russell -policy: - Please ping me when changes made, so I can sync with CCAN project. - -files: libcli/dns -maintainers: - Kai Blin -policy: - Mail/CC changes to the maintainer, commit the changes - unless the maintainer objects. - -======================================================================= - -Samba Maintainers System ------------------------- - -The Samba project has adopted a maintainers system, with the following -approach: - - - we have created a new 'MAINTAINERS.txt' file in the root of the git - tree - - - that file will contain a list of subsystems, and along with each - subsystem a list of maintainers - - - subsystems may be subdirectories, or logical groups of files (for - example "build system" or "selftest" could be subsystems that span - multiple directories) - - - if a subsystem is not listed in the MAINTAINERS.txt file, then this - maintainers proposal does not apply to that subsystem. The previous - Samba development methods apply to unlisted subsystems. - - - when we first create the MAINTAINERS.txt it will be empty, thus on - the first day of adoption there is no actual change to our - development practices - - - we will add subsystems to the MAINTAINERS.txt file via consensus - within the Samba Team. This means that someone would propose - themselves, or another team member, as a subsystem maintainer, and - if there are no objections then they can push a change to the - maintainers file after a couple of days waiting for replies. If - there is an existing maintainer for that subsystem then at minimum - the person proposing should wait for a positive ack from the - previous maintainer. - - - a typical subsystem declaration would be: - - directory: /libds - maintainers: - Andrew Bartlett - Andrew Tridgell - policy: - small commits to master allowed if all existing tests - pass. Larger commits require discussion on samba-technical - list and review by the maintainer - - - the maintainers for a subsystem may update the policy for that - subsystem at any time by pushing a commit to the MAINTAINERS.txt - file. Significant changes should also be sent to the - samba-technical list to ensure that all developers are aware of the - policy change - - - a subsystem may have multiple maintainers, and it is expected that - this will be the case for many of our subsystems. - - - a maintainer may delegate responsibility to someone else for a - period of time (such as during rapid development or when the - maintainer is away). A maintainer may also appoint a backup - maintainer. These changes should be noted in the maintainers file, - and removed when no longer relevent. - - - maintainer handover would happen by agreement between the old and - new maintainer, and is signified by a commit to the MAINTAINERS.txt - file. If agreement cannot be reached then we can resolve the - disagreement using discussions on the team list. If agreement still - can't be reached then the maintainer won't change. - -What does it mean to be a maintainer? -------------------------------------- - -If you are a maintainer for a subsystem then you have some additional -rights and responsibilies for that code. Specifically: - - - you should make time to review any proposed changes to any - subsystems that you maintain. You should then provide feedback on - proposed changes or sign off on the changes once you are happy with - them. - - - you may choose the policy for the subsystems you maintain. That - policy could be a permissive one, where you allow for small changes - without review, or it could be a strict one, where you only allow - reviewed changes to be pushed. - - - being a maintainer for a subsystem does not override the "right of - veto" of other team members for technical objections. See the - "right of veto" section below for more information. - - - the maintainers can set the developmental direction of the - subsystem, but should strive to achieve concensus where possible - with other team members for the benefit of the whole - project. - -Note that if you set a permissive policy on your subsystem, so that -small changes may be pushed without review, you are still responsible -for reviewing changes if someone specifically asks you to review a -patch. - -Try to reuse policy wording ---------------------------- - -It would be good if we end up with only a few sets of policy wording, -rather than a completely different policy for each subsystem. To try -to achieve that, maintainers should try to re-use an existing policy -wording if possible. - - -The right of veto ------------------ - -Over the last few years the Samba Team has started to use a +1/-1 -voting system, which was inspired by the Apache voting system for -technical issues (see http://www.apache.org/foundation/voting.html). - -For the maintainers proposal to work, I think we need to ensure that -everyone understands what a -1 "veto" vote means on a technical issue. - -For purely technical issues, the +1/-1 voting system should not be a -"most votes wins" system. Instead a single -1 vote is supposed to -override any number of +1 votes, so a -1 vote is a "veto", and all -team members have the right to give a -1 veto vote on any purely -technical issue. - -Along with the right to give a -1 veto vote comes the responsibility -to backup that veto with a technical argument, and the willingness to -then defend your argument in any subsequent discussions and to work -with the patch proposer to find a solution. If you do not backup your --1 veto vote, or you are unwilling on unable to participate in any -discussions that arise from that veto, then the veto vote may be -disregarded. - -Note that a veto is supposed to be used only for purely technical -reasons, so for example pointing out a security concern with a change, -or pointing out that the code may segfault or cause a regression of -functionality. -- 2.11.4.GIT