From 8f8a9f01909ba29e2b781310baeeaaddc3f15f0d Mon Sep 17 00:00:00 2001 From: "Gerald W. Carter" Date: Tue, 22 Apr 2008 10:09:40 -0500 Subject: Moving docs tree to docs-xml to make room for generated docs in the release tarball. (This used to be commit 9f672c26d63955f613088489c6efbdc08b5b2d14) --- docs-xml/Samba3-Developers-Guide/contributing.xml | 112 ++++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 docs-xml/Samba3-Developers-Guide/contributing.xml (limited to 'docs-xml/Samba3-Developers-Guide/contributing.xml') diff --git a/docs-xml/Samba3-Developers-Guide/contributing.xml b/docs-xml/Samba3-Developers-Guide/contributing.xml new file mode 100644 index 0000000000..01e6fb2863 --- /dev/null +++ b/docs-xml/Samba3-Developers-Guide/contributing.xml @@ -0,0 +1,112 @@ + + + + + + &author.jelmer; + + +Contributing code + +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. + + + + Retrieving the source + + + 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. + + + + + + Discuss large modifications with team members + + 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. + + + 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. + + + + + + Patch format + + Patches to the samba tree should be in unified diff format, + e.g. files generated by diff -u. + + + If you are modifying a copy of samba you retrieved from CVS, + you can easily generate a diff file of these changes by running + cvs diff -u. + + + + + Points of attention when modifying samba source code + + + 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. + 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. + 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. + Make sure your patch complies to the samba coding style as + suggested in the coding-suggestions chapter. + + + + + + + Sending in bugfixes + + Bugfixes to bugs in samba should be submitted to samba's + bugzilla system, + along with a description of the bug. + + + + + + Sending in feature patches + + Send feature patches along with a description of what the + patch is supposed to do to the + Samba-technical mailinglist 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. + + + + + Feedback on your patch + + 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. + + + + + -- cgit