From: Andrew Tridgell Date: Wed, 6 Oct 2010 21:23:22 +0000 (+1100) Subject: maintainers: added initial MAINTAINERS.txt X-Git-Url: http://git.samba.org/?p=mat%2Fsamba.git;a=commitdiff_plain;h=081818a7a8464c19c7dead604e680e898a98a6c2 maintainers: added initial MAINTAINERS.txt initially with no subsystems maintained. Some initial maintainers will be added soon after discussion. Autobuild-User: Andrew Tridgell Autobuild-Date: Wed Oct 6 22:07:01 UTC 2010 on sn-devel-104 --- diff --git a/MAINTAINERS.txt b/MAINTAINERS.txt new file mode 100644 index 0000000000..efa42d4194 --- /dev/null +++ b/MAINTAINERS.txt @@ -0,0 +1,152 @@ +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. + + +======================================================================= + + + + + + + +======================================================================= + +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.