mirror of
https://github.com/samba-team/samba.git
synced 2024-12-23 17:34:34 +03:00
cc7ae1098a
This guide is not obsolete but needs an update. Signed-off-by: Karolin Seeger <kseeger@samba.org> Reviewed-by: Andreas Schneider <asn@samba.org> Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org> Autobuild-Date(master): Wed May 10 19:57:36 CEST 2017 on sn-devel-144
113 lines
3.9 KiB
XML
113 lines
3.9 KiB
XML
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
|
|
|
|
<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>
|
|
<itemizedlist>
|
|
<listitem><para>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.</para></listitem>
|
|
<listitem><para>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.</para></listitem>
|
|
<listitem><para>Don't put separate 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. </para></listitem>
|
|
<listitem><para>Make sure your patch complies to the samba coding style as
|
|
suggested in the coding-suggestions chapter. </para></listitem>
|
|
</itemizedlist>
|
|
</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@lists.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>
|