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