samba-mirror/MAINTAINERS.txt

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 <metze@samba.org>
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 <tridge@samba.org>
         and Volker Lendecke <vl@samba.org>).

         Larger changes need also discussion on the samba-technical list
         and review by all maintainers.

directory: lib/tsocket/
maintainers:
         Stefan Metzmacher <metze@samba.org>
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 <tridge@samba.org>
         Jelmer Vernooij <jelmer@samba.org>
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 <rusty@samba.org>
policy:
         Mail/CC changes to the maintainer, commit the changes
         unless the maintainer objects.

files: lib/talloc
maintainers:
         Andrew Tridgell <tridge@samba.org>
         Rusty Russell <rusty@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

files: lib/tevent/py*, lib/talloc/py*, source4/lib/ldb/py*, lib/tdb/py*
maintainers:
         Jelmer Vernooij <jelmer@samba.org>
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.


=======================================================================

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.