s4:torture:smb2: fix the durable-open.delete_on_close1 test
[Samba/gebeck_regimport.git] / MAINTAINERS.txt
blob3b6a88a1a49fdc23cd956c6583e9ec56e541eeae
1 Samba maintainers
2 -----------------
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.
11 =======================================================================
13 directory: lib/tevent/
14 maintainers:
15          Stefan Metzmacher <metze@samba.org>
16 policy:
17          All commits require review by the maintainer.
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>).
24          Larger changes need also discussion on the samba-technical list
25          and review by all maintainers.
27 directory: lib/tsocket/
28 maintainers:
29          Stefan Metzmacher <metze@samba.org>
30 policy:
31          All commits require review by the maintainer.
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.
37          Larger changes need also discussion on the samba-technical list
38          and review by all maintainers.
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
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.
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
65 files: lib/tevent/py*, lib/talloc/py*, 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.
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.
75 files: lib/ccan
76 maintainers:
77          Rusty Russell <rusty@samba.org>
78 policy:
79          Please ping me when changes made, so I can sync with CCAN project.
81 files: libcli/dns
82 maintainers:
83          Kai Blin <kai@samba.org>
84 policy:
85          Mail/CC changes to the maintainer, commit the changes
86          unless the maintainer objects.
88 =======================================================================
90 Samba Maintainers System
91 ------------------------
93 The Samba project has adopted a maintainers system, with the following
94 approach:
96  - we have created a new 'MAINTAINERS.txt' file in the root of the git
97    tree
99  - that file will contain a list of subsystems, and along with each
100    subsystem a list of maintainers
102  - subsystems may be subdirectories, or logical groups of files (for
103    example "build system" or "selftest" could be subsystems that span
104    multiple directories)
106  - if a subsystem is not listed in the MAINTAINERS.txt file, then this
107    maintainers proposal does not apply to that subsystem. The previous
108    Samba development methods apply to unlisted subsystems.
110  - when we first create the MAINTAINERS.txt it will be empty, thus on
111    the first day of adoption there is no actual change to our
112    development practices
114  - we will add subsystems to the MAINTAINERS.txt file via consensus
115    within the Samba Team. This means that someone would propose
116    themselves, or another team member, as a subsystem maintainer, and
117    if there are no objections then they can push a change to the
118    maintainers file after a couple of days waiting for replies. If
119    there is an existing maintainer for that subsystem then at minimum
120    the person proposing should wait for a positive ack from the
121    previous maintainer.
123  - a typical subsystem declaration would be:
125       directory: /libds
126       maintainers:
127                    Andrew Bartlett <abartlet@samba.org>
128                    Andrew Tridgell <tridge@samba.org>
129       policy:
130          small commits to master allowed if all existing tests
131          pass. Larger commits require discussion on samba-technical
132          list and review by the maintainer
134  - the maintainers for a subsystem may update the policy for that
135    subsystem at any time by pushing a commit to the MAINTAINERS.txt
136    file. Significant changes should also be sent to the
137    samba-technical list to ensure that all developers are aware of the
138    policy change
140  - a subsystem may have multiple maintainers, and it is expected that
141    this will be the case for many of our subsystems.
143  - a maintainer may delegate responsibility to someone else for a
144    period of time (such as during rapid development or when the
145    maintainer is away). A maintainer may also appoint a backup
146    maintainer. These changes should be noted in the maintainers file,
147    and removed when no longer relevent.
149  - maintainer handover would happen by agreement between the old and
150    new maintainer, and is signified by a commit to the MAINTAINERS.txt
151    file. If agreement cannot be reached then we can resolve the
152    disagreement using discussions on the team list. If agreement still
153    can't be reached then the maintainer won't change.
155 What does it mean to be a maintainer?
156 -------------------------------------
158 If you are a maintainer for a subsystem then you have some additional
159 rights and responsibilies for that code. Specifically:
161  - you should make time to review any proposed changes to any
162    subsystems that you maintain. You should then provide feedback on
163    proposed changes or sign off on the changes once you are happy with
164    them.
166  - you may choose the policy for the subsystems you maintain. That
167    policy could be a permissive one, where you allow for small changes
168    without review, or it could be a strict one, where you only allow
169    reviewed changes to be pushed.
171  - being a maintainer for a subsystem does not override the "right of
172    veto" of other team members for technical objections. See the
173    "right of veto" section below for more information.
175  - the maintainers can set the developmental direction of the
176    subsystem, but should strive to achieve concensus where possible
177    with other team members for the benefit of the whole
178    project.
180 Note that if you set a permissive policy on your subsystem, so that
181 small changes may be pushed without review, you are still responsible
182 for reviewing changes if someone specifically asks you to review a
183 patch.
185 Try to reuse policy wording
186 ---------------------------
188 It would be good if we end up with only a few sets of policy wording,
189 rather than a completely different policy for each subsystem. To try
190 to achieve that, maintainers should try to re-use an existing policy
191 wording if possible.
194 The right of veto
195 -----------------
197 Over the last few years the Samba Team has started to use a +1/-1
198 voting system, which was inspired by the Apache voting system for
199 technical issues (see http://www.apache.org/foundation/voting.html).
201 For the maintainers proposal to work, I think we need to ensure that
202 everyone understands what a -1 "veto" vote means on a technical issue.
204 For purely technical issues, the +1/-1 voting system should not be a
205 "most votes wins" system. Instead a single -1 vote is supposed to
206 override any number of +1 votes, so a -1 vote is a "veto", and all
207 team members have the right to give a -1 veto vote on any purely
208 technical issue.
210 Along with the right to give a -1 veto vote comes the responsibility
211 to backup that veto with a technical argument, and the willingness to
212 then defend your argument in any subsequent discussions and to work
213 with the patch proposer to find a solution. If you do not backup your
214 -1 veto vote, or you are unwilling on unable to participate in any
215 discussions that arise from that veto, then the veto vote may be
216 disregarded.
218 Note that a veto is supposed to be used only for purely technical
219 reasons, so for example pointing out a security concern with a change,
220 or pointing out that the code may segfault or cause a regression of
221 functionality.