summaryrefslogtreecommitdiff
path: root/docs/docbook/devdoc/contributing.xml
diff options
context:
space:
mode:
Diffstat (limited to 'docs/docbook/devdoc/contributing.xml')
-rw-r--r--docs/docbook/devdoc/contributing.xml109
1 files changed, 0 insertions, 109 deletions
diff --git a/docs/docbook/devdoc/contributing.xml b/docs/docbook/devdoc/contributing.xml
deleted file mode 100644
index 2583c8727a..0000000000
--- a/docs/docbook/devdoc/contributing.xml
+++ /dev/null
@@ -1,109 +0,0 @@
-<chapter id="contributing">
-<chapterinfo>
- &author.jelmer;
-</chapterinfo>
-
-<title>Contributing code</title>
-
-<para>Here are a few tips and notes that might be useful if you are
- interested in modifying samba source code and getting it into
- samba's main branch.</para>
-
-<variablelist>
- <varlistentry>
- <term>Retrieving the source</term>
-
- <listitem>
- <para>In order to contribute code to samba, make sure you have the
- latest source. Retrieving the samba source code from CVS is
- documented in the appendix of the Samba HOWTO Collection.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Discuss large modifications with team members</term>
- <listitem>
- <para>Please discuss large modifications you are going to make
- with members of the samba team. Some parts of the samba code
- have one or more 'owners' - samba developers who wrote most
- of the code and maintain it.
- </para>
-
- <para>This way you can avoid spending your time and effort on
- something that is not going to make it into the main samba branch
- because someone else was working on the same thing or because your
- implementation is not the correct one.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Patch format</term>
- <listitem>
- <para>Patches to the samba tree should be in unified diff format,
- e.g. files generated by <userinput>diff -u</userinput>.
- </para>
-
- <para>If you are modifying a copy of samba you retrieved from CVS,
- you can easily generate a diff file of these changes by running
- <userinput>cvs diff -u</userinput>.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Points of attention when modifying samba source code</term>
- <listitem><para>
- <simplelist>
- <member>Don't simply copy code from other places and modify it until it
- works. Code needs to be clean and logical. Duplicate
- code is to be avoided.</member>
- <member>Test your patch. It might take a while before one of us looks
- at your patch so it will take longer before your patch when your patch
- needs to go thru the review cycle again.</member>
- <member>Don't put seperate patches in one large diff file. This makes
- it harder to read, understand and test the patch. You might
- also risk not getting a good patch committed because you mixed it
- with one that had issues. </member>
- <member>Make sure your patch complies to the samba coding style as
- suggested in the coding-suggestions chapter. </member>
- </simplelist>
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Sending in bugfixes</term>
- <listitem>
- <para>Bugfixes to bugs in samba should be submitted to samba's
- <ulink url="https://bugzilla.samba.org/">bugzilla system</ulink>,
- along with a description of the bug.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Sending in feature patches</term>
- <listitem>
- <para>Send feature patches along with a description of what the
- patch is supposed to do to the
- <ulink url="mailto:samba-technical@samba.org">Samba-technical mailinglist</ulink> and possibly to a samba team member who is (one of the) 'owners'
- of the code you made modifications to. We are all busy people
- so everybody tends to 'let one of the others handle it'. If nobody
- responded to your patch for a week, try to send it again until you
- get a response from one of us.
- </para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Feedback on your patch</term>
- <listitem>
- <para>One of the team members will look at your patch and either
- commit your patch or give comments why he won't apply it. In the
- latter case you can fix your patch and re-send it until
- your patch is approved.</para>
- </listitem>
- </varlistentry>
-</variablelist>
-
-</chapter>