+++ /dev/null
-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.
-
-files: libcli/dns
-maintainers:
- Kai Blin <kai@samba.org>
-policy:
- Mail/CC changes to the maintainer, commit the changes
- unless the maintainer objects.
-
-=======================================================================
-
-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.
git.samba.org / nivanova / samba-autobuild / .git / blobdiff