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