--- /dev/null
+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 <abartlet@samba.org>
+ Andrew Tridgell <tridge@samba.org>
+ 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.
git.samba.org / sfrench / samba-autobuild / .git / blobdiff