mirror of
https://github.com/samba-team/samba.git
synced 2024-12-23 17:34:34 +03:00
cdce32470a
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Autobuild-User: Rusty Russell <rusty@rustcorp.com.au> Autobuild-Date: Wed Aug 31 07:58:34 CEST 2011 on sn-devel-104
215 lines
8.2 KiB
Plaintext
215 lines
8.2 KiB
Plaintext
Samba maintainers
|
|
-----------------
|
|
|
|
This file lists the maintainers for subsystems in Samba. Please see
|
|
the end of the file for information on how the maintainers system
|
|
works. If you can't work out who the maintainer is for some code,
|
|
please ask on the samba-technical list or on the samba-technical IRC
|
|
channel.
|
|
|
|
|
|
=======================================================================
|
|
|
|
directory: lib/tevent/
|
|
maintainers:
|
|
Stefan Metzmacher <metze@samba.org>
|
|
policy:
|
|
All commits require review by the maintainer.
|
|
|
|
If no maintainer is available for longer than a week
|
|
discussion on the samba-technical list and review by 2
|
|
Samba-Team members is needed (e.g. Andrew Tridgell <tridge@samba.org>
|
|
and Volker Lendecke <vl@samba.org>).
|
|
|
|
Larger changes need also discussion on the samba-technical list
|
|
and review by all maintainers.
|
|
|
|
directory: lib/tsocket/
|
|
maintainers:
|
|
Stefan Metzmacher <metze@samba.org>
|
|
policy:
|
|
All commits require review by the maintainer.
|
|
|
|
If no maintainer is available for longer than a week
|
|
discussion on the samba-technical list and review by 2
|
|
Samba-Team members is needed.
|
|
|
|
Larger changes need also discussion on the samba-technical list
|
|
and review by all maintainers.
|
|
|
|
files: buildtools/**, source4/**/wscript
|
|
maintainers:
|
|
Andrew Tridgell <tridge@samba.org>
|
|
Jelmer Vernooij <jelmer@samba.org>
|
|
policy:
|
|
small commits to master allowed if all existing tests
|
|
pass. Larger commits require discussion on the samba-technical
|
|
list and review by the maintainer
|
|
|
|
files: lib/tdb
|
|
maintainers:
|
|
Rusty Russell <rusty@samba.org>
|
|
policy:
|
|
Mail/CC changes to the maintainer, commit the changes
|
|
unless the maintainer objects.
|
|
|
|
files: lib/talloc
|
|
maintainers:
|
|
Andrew Tridgell <tridge@samba.org>
|
|
Rusty Russell <rusty@samba.org>
|
|
policy:
|
|
small commits to master allowed if all existing tests
|
|
pass. Larger commits require discussion on samba-technical
|
|
list and review by the maintainer
|
|
|
|
files: lib/tevent/py*, lib/talloc/py*, lib/ldb/py*, lib/tdb/py*
|
|
maintainers:
|
|
Jelmer Vernooij <jelmer@samba.org>
|
|
policy:
|
|
Larger commits require pre-push review by the maintainer or
|
|
one of the maintainers of the containing subsystem.
|
|
|
|
Other non-trivial (typo, etc) commits require pre- or post-push review by the
|
|
maintainer or one of the maintainers of the containing subsystem.
|
|
|
|
files: lib/ccan
|
|
maintainers:
|
|
Rusty Russell <rusty@samba.org>
|
|
policy:
|
|
Please ping me when changes made, so I can sync with CCAN project.
|
|
|
|
=======================================================================
|
|
|
|
Samba Maintainers System
|
|
------------------------
|
|
|
|
The Samba project has adopted a maintainers system, with the following
|
|
approach:
|
|
|
|
- we have created a new 'MAINTAINERS.txt' file in the root of the git
|
|
tree
|
|
|
|
- that file will contain a list of subsystems, and along with each
|
|
subsystem a list of maintainers
|
|
|
|
- subsystems may be subdirectories, or logical groups of files (for
|
|
example "build system" or "selftest" could be subsystems that span
|
|
multiple directories)
|
|
|
|
- if a subsystem is not listed in the MAINTAINERS.txt file, then this
|
|
maintainers proposal does not apply to that subsystem. The previous
|
|
Samba development methods apply to unlisted subsystems.
|
|
|
|
- when we first create the MAINTAINERS.txt it will be empty, thus on
|
|
the first day of adoption there is no actual change to our
|
|
development practices
|
|
|
|
- we will add subsystems to the MAINTAINERS.txt file via consensus
|
|
within the Samba Team. This means that someone would propose
|
|
themselves, or another team member, as a subsystem maintainer, and
|
|
if there are no objections then they can push a change to the
|
|
maintainers file after a couple of days waiting for replies. If
|
|
there is an existing maintainer for that subsystem then at minimum
|
|
the person proposing should wait for a positive ack from the
|
|
previous maintainer.
|
|
|
|
- a typical subsystem declaration would be:
|
|
|
|
directory: /libds
|
|
maintainers:
|
|
Andrew Bartlett <abartlet@samba.org>
|
|
Andrew Tridgell <tridge@samba.org>
|
|
policy:
|
|
small commits to master allowed if all existing tests
|
|
pass. Larger commits require discussion on samba-technical
|
|
list and review by the maintainer
|
|
|
|
- the maintainers for a subsystem may update the policy for that
|
|
subsystem at any time by pushing a commit to the MAINTAINERS.txt
|
|
file. Significant changes should also be sent to the
|
|
samba-technical list to ensure that all developers are aware of the
|
|
policy change
|
|
|
|
- a subsystem may have multiple maintainers, and it is expected that
|
|
this will be the case for many of our subsystems.
|
|
|
|
- a maintainer may delegate responsibility to someone else for a
|
|
period of time (such as during rapid development or when the
|
|
maintainer is away). A maintainer may also appoint a backup
|
|
maintainer. These changes should be noted in the maintainers file,
|
|
and removed when no longer relevent.
|
|
|
|
- maintainer handover would happen by agreement between the old and
|
|
new maintainer, and is signified by a commit to the MAINTAINERS.txt
|
|
file. If agreement cannot be reached then we can resolve the
|
|
disagreement using discussions on the team list. If agreement still
|
|
can't be reached then the maintainer won't change.
|
|
|
|
What does it mean to be a maintainer?
|
|
-------------------------------------
|
|
|
|
If you are a maintainer for a subsystem then you have some additional
|
|
rights and responsibilies for that code. Specifically:
|
|
|
|
- you should make time to review any proposed changes to any
|
|
subsystems that you maintain. You should then provide feedback on
|
|
proposed changes or sign off on the changes once you are happy with
|
|
them.
|
|
|
|
- you may choose the policy for the subsystems you maintain. That
|
|
policy could be a permissive one, where you allow for small changes
|
|
without review, or it could be a strict one, where you only allow
|
|
reviewed changes to be pushed.
|
|
|
|
- being a maintainer for a subsystem does not override the "right of
|
|
veto" of other team members for technical objections. See the
|
|
"right of veto" section below for more information.
|
|
|
|
- the maintainers can set the developmental direction of the
|
|
subsystem, but should strive to achieve concensus where possible
|
|
with other team members for the benefit of the whole
|
|
project.
|
|
|
|
Note that if you set a permissive policy on your subsystem, so that
|
|
small changes may be pushed without review, you are still responsible
|
|
for reviewing changes if someone specifically asks you to review a
|
|
patch.
|
|
|
|
Try to reuse policy wording
|
|
---------------------------
|
|
|
|
It would be good if we end up with only a few sets of policy wording,
|
|
rather than a completely different policy for each subsystem. To try
|
|
to achieve that, maintainers should try to re-use an existing policy
|
|
wording if possible.
|
|
|
|
|
|
The right of veto
|
|
-----------------
|
|
|
|
Over the last few years the Samba Team has started to use a +1/-1
|
|
voting system, which was inspired by the Apache voting system for
|
|
technical issues (see http://www.apache.org/foundation/voting.html).
|
|
|
|
For the maintainers proposal to work, I think we need to ensure that
|
|
everyone understands what a -1 "veto" vote means on a technical issue.
|
|
|
|
For purely technical issues, the +1/-1 voting system should not be a
|
|
"most votes wins" system. Instead a single -1 vote is supposed to
|
|
override any number of +1 votes, so a -1 vote is a "veto", and all
|
|
team members have the right to give a -1 veto vote on any purely
|
|
technical issue.
|
|
|
|
Along with the right to give a -1 veto vote comes the responsibility
|
|
to backup that veto with a technical argument, and the willingness to
|
|
then defend your argument in any subsequent discussions and to work
|
|
with the patch proposer to find a solution. If you do not backup your
|
|
-1 veto vote, or you are unwilling on unable to participate in any
|
|
discussions that arise from that veto, then the veto vote may be
|
|
disregarded.
|
|
|
|
Note that a veto is supposed to be used only for purely technical
|
|
reasons, so for example pointing out a security concern with a change,
|
|
or pointing out that the code may segfault or cause a regression of
|
|
functionality.
|