maintainers: added initial MAINTAINERS.txt

initially with no subsystems maintained. Some initial maintainers will
be added soon after discussion.

Autobuild-User: Andrew Tridgell <tridge@samba.org>
Autobuild-Date: Wed Oct  6 22:07:01 UTC 2010 on sn-devel-104

1 files changed, 152 insertions, 0 deletions

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 <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.