From dadc34655c3ab961b0b0b94a10eaaba710f0b5e8 Mon Sep 17 00:00:00 2001
From: tpearson <tpearson@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>
Date: Mon, 4 Jul 2011 22:38:03 +0000
Subject: Added kmymoney

git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/applications/kmymoney@1239792 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
---
 developer-doc/phb/submissions.docbook | 99 +++++++++++++++++++++++++++++++++++
 1 file changed, 99 insertions(+)
 create mode 100644 developer-doc/phb/submissions.docbook

(limited to 'developer-doc/phb/submissions.docbook')

diff --git a/developer-doc/phb/submissions.docbook b/developer-doc/phb/submissions.docbook
new file mode 100644
index 0000000..8a69e0c
--- /dev/null
+++ b/developer-doc/phb/submissions.docbook
@@ -0,0 +1,99 @@
+<chapter id="submissions">
+<chapterinfo>
+<authorgroup>
+<author>
+        <firstname>Alvaro</firstname>
+        <surname>Soliverez</surname>
+        <affiliation>
+                <address><email>asoliverez@gmail.com</email></address>
+        </affiliation>
+</author>
+</authorgroup>
+</chapterinfo>
+<title>Patch Submissions</title>
+<para>
+This section describes how to send patches and additions when you don't have direct CVS access. In that case, you should send the contributions to the developer mailing list. That way, more people can test your contribution than if you send it to a specific developer. It could also happen that this developer has a lot of pending stuff, and your contribution gets delayed.
+</para>
+
+<para>
+For the specifics on how to code, translate or write documentation, refer to the proper sections. Once you are done with the actual work, you have to create the patch file to send.
+</para>
+
+<sect1 id="patch">
+<title>Steps to create a patch</title>
+
+<sect2 id="prerequisites">
+<title>Prerequisites</title>
+<para>
+Have an updated cvs version of the release you are contributing to (HEAD, stable release, etc)
+</para>
+<itemizedlist>
+<listitem>
+<para>
+Make sure to run 'cvs upd' before you create the patch
+</para>
+</listitem>
+<listitem>
+<para>
+If the update changes your sandbox, make sure that the changes still work
+</para>
+</listitem>
+</itemizedlist>
+</sect2>
+
+<sect2 id="existingfiles">
+<title>If you modified existing Files</title>
+
+<itemizedlist>
+<listitem>
+<para>
+Run 'cvs diff -u'  in the root directory. That should the create the patch to be applied to existing files
+</para>
+</listitem>
+<listitem>
+<para>
+Inspect the patch that it does only contain your wanted changes
+</para>
+</listitem>
+</itemizedlist>
+</sect2>
+
+<sect2 id="newfiles">
+<title>If you have added new Files</title>
+
+<itemizedlist>
+<listitem>
+<para>
+Make sure you write down on the email the location of each new file (The developer handling the patch will probably know how to find the correct location, but this will save her/him some precious time)
+</para>
+</listitem>
+</itemizedlist>
+</sect2>
+
+<sect2 id="finalsteps">
+<title>Final Steps</title>
+
+<itemizedlist>
+<listitem>
+<para>
+Compress the patch and any new files into a single .tar.gz file
+</para>
+</listitem>
+<listitem>
+<para>
+Send to the developer mailing list, explaining the nature of the submission
+</para>
+</listitem>
+<listitem>
+<para>
+The developer handling the patch should acknowledge that to the list as well, to avoid duplicate work
+</para>
+</listitem>
+</itemizedlist>
+</sect2>
+
+<para>
+Keep in mind that there are times when all developers have plenty of work, or a patch should be best handled by a specific developer that may not be readily available, so be patient. Also, if you don't receive an acknowledgement after a few days, write to the list asking for the status of your patch. Subscribing to the developer mailing list would be a good idea if you are sending contributions.
+</para>
+</sect1>
+</chapter>
\ No newline at end of file
-- 
cgit v1.2.1