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