MAINTAINERS.txt

   1 Samba maintainers
   2 -----------------
   3
   4 This file lists the maintainers for subsystems in Samba. Please see
   5 the end of the file for information on how the maintainers system
   6 works. If you can't work out who the maintainer is for some code,
   7 please ask on the samba-technical list or on the samba-technical IRC
   8 channel.
   9
  10
  11 =======================================================================
  12
  13 directory: lib/tevent/
  14 maintainers:
  15          Stefan Metzmacher <metze@samba.org>
  16 policy:
  17          All commits require review by the maintainer.
  18
  19          If no maintainer is available for longer than a week
  20          discussion on the samba-technical list and review by 2
  21          Samba-Team members is needed (e.g. Andrew Tridgell <tridge@samba.org
  22          and Volker Lendecke <vl@samba.org>).
  23
  24          Larger changes need also discussion on the samba-technical list
  25          and review by all maintainers.
  26
  27 directory: lib/tsocket/
  28 maintainers:
  29          Stefan Metzmacher <metze@samba.org>
  30 policy:
  31          All commits require review by the maintainer.
  32
  33          If no maintainer is available for longer than a week
  34          discussion on the samba-technical list and review by 2
  35          Samba-Team members is needed.
  36
  37          Larger changes need also discussion on the samba-technical list
  38          and review by all maintainers.
  39
  40
  41 files: lib/tevent/py*, lib/talloc/py*, source4/lib/ldb/py*, lib/tdb/py*
  42 maintainers:
  43          Jelmer Vernooij <jelmer@samba.org>
  44 policy:
  45          Larger commits require pre-push review by the maintainer or
  46          one of the maintainers of the containing subsystem.
  47
  48          Other non-trivial (typo, etc) commits require pre- or post-push review by the
  49          maintainer or one of the maintainers of the containing subsystem.
  50
  51
  52 =======================================================================
  53
  54 Samba Maintainers System
  55 ------------------------
  56
  57 The Samba project has adopted a maintainers system, with the following
  58 approach:
  59
  60  - we have created a new 'MAINTAINERS.txt' file in the root of the git
  61    tree
  62
  63  - that file will contain a list of subsystems, and along with each
  64    subsystem a list of maintainers
  65
  66  - subsystems may be subdirectories, or logical groups of files (for
  67    example "build system" or "selftest" could be subsystems that span
  68    multiple directories)
  69
  70  - if a subsystem is not listed in the MAINTAINERS.txt file, then this
  71    maintainers proposal does not apply to that subsystem. The previous
  72    Samba development methods apply to unlisted subsystems.
  73
  74  - when we first create the MAINTAINERS.txt it will be empty, thus on
  75    the first day of adoption there is no actual change to our
  76    development practices
  77
  78  - we will add subsystems to the MAINTAINERS.txt file via consensus
  79    within the Samba Team. This means that someone would propose
  80    themselves, or another team member, as a subsystem maintainer, and
  81    if there are no objections then they can push a change to the
  82    maintainers file after a couple of days waiting for replies. If
  83    there is an existing maintainer for that subsystem then at minimum
  84    the person proposing should wait for a positive ack from the
  85    previous maintainer.
  86
  87  - a typical subsystem declaration would be:
  88
  89       directory: /libds
  90       maintainers:
  91                    Andrew Bartlett <abartlet@samba.org>
  92                    Andrew Tridgell <tridge@samba.org>
  93       policy:
  94          small commits to master allowed if all existing tests
  95          pass. Larger commits require discussion on samba-technical
  96          list and review by the maintainer
  97
  98  - the maintainers for a subsystem may update the policy for that
  99    subsystem at any time by pushing a commit to the MAINTAINERS.txt
 100    file. Significant changes should also be sent to the
 101    samba-technical list to ensure that all developers are aware of the
 102    policy change
 103
 104  - a subsystem may have multiple maintainers, and it is expected that
 105    this will be the case for many of our subsystems.
 106
 107  - a maintainer may delegate responsibility to someone else for a
 108    period of time (such as during rapid development or when the
 109    maintainer is away). A maintainer may also appoint a backup
 110    maintainer. These changes should be noted in the maintainers file,
 111    and removed when no longer relevent.
 112
 113  - maintainer handover would happen by agreement between the old and
 114    new maintainer, and is signified by a commit to the MAINTAINERS.txt
 115    file. If agreement cannot be reached then we can resolve the
 116    disagreement using discussions on the team list. If agreement still
 117    can't be reached then the maintainer won't change.
 118
 119 What does it mean to be a maintainer?
 120 -------------------------------------
 121
 122 If you are a maintainer for a subsystem then you have some additional
 123 rights and responsibilies for that code. Specifically:
 124
 125  - you should make time to review any proposed changes to any
 126    subsystems that you maintain. You should then provide feedback on
 127    proposed changes or sign off on the changes once you are happy with
 128    them.
 129
 130  - you may choose the policy for the subsystems you maintain. That
 131    policy could be a permissive one, where you allow for small changes
 132    without review, or it could be a strict one, where you only allow
 133    reviewed changes to be pushed.
 134
 135  - being a maintainer for a subsystem does not override the "right of
 136    veto" of other team members for technical objections. See the
 137    "right of veto" section below for more information.
 138
 139  - the maintainers can set the developmental direction of the
 140    subsystem, but should strive to achieve concensus where possible
 141    with other team members for the benefit of the whole
 142    project.
 143
 144 Note that if you set a permissive policy on your subsystem, so that
 145 small changes may be pushed without review, you are still responsible
 146 for reviewing changes if someone specifically asks you to review a
 147 patch.
 148
 149 Try to reuse policy wording
 150 ---------------------------
 151
 152 It would be good if we end up with only a few sets of policy wording,
 153 rather than a completely different policy for each subsystem. To try
 154 to achieve that, maintainers should try to re-use an existing policy
 155 wording if possible.
 156
 157
 158 The right of veto
 159 -----------------
 160
 161 Over the last few years the Samba Team has started to use a +1/-1
 162 voting system, which was inspired by the Apache voting system for
 163 technical issues (see http://www.apache.org/foundation/voting.html).
 164
 165 For the maintainers proposal to work, I think we need to ensure that
 166 everyone understands what a -1 "veto" vote means on a technical issue.
 167
 168 For purely technical issues, the +1/-1 voting system should not be a
 169 "most votes wins" system. Instead a single -1 vote is supposed to
 170 override any number of +1 votes, so a -1 vote is a "veto", and all
 171 team members have the right to give a -1 veto vote on any purely
 172 technical issue.
 173
 174 Along with the right to give a -1 veto vote comes the responsibility
 175 to backup that veto with a technical argument, and the willingness to
 176 then defend your argument in any subsequent discussions and to work
 177 with the patch proposer to find a solution. If you do not backup your
 178 -1 veto vote, or you are unwilling on unable to participate in any
 179 discussions that arise from that veto, then the veto vote may be
 180 disregarded.
 181
 182 Note that a veto is supposed to be used only for purely technical
 183 reasons, so for example pointing out a security concern with a change,
 184 or pointing out that the code may segfault or cause a regression of
 185 functionality.