2 <title>Submitting Patches
</title>
5 Written by &name-albert-den-haan;
<email>&email-albert-den-haan;
</email>
7 <sect1 id=
"patch-format">
8 <title>Patch Format
</title>
11 Your patch should include:
17 a description of what was wrong and what is now better
23 your contact information ( Name/Handle and e-mail )
28 the patch in
<command>diff -u
</command> format (it happens...)
34 <command>cvs diff -u
</command> works great for the common case
35 where a file is edited. However, if you add or remove a file
36 <command>cvs diff
</command> will not report that correctly so
37 make sure you explicitly take care of this rare case.
40 For additions: mention that you have some new files and
41 include them as either separate attachments or by appending
42 the
<command>diff -u /dev/null /my/new/file
</command> output of them
43 to any
<command>cvs diff -u
</command> output you may have.
44 Alernatively, use
<command>diff -Nu olddir/ newdir/
</command>
45 in case of multiple new files to add.
48 For removals, list the files.
52 <sect1 id=
"patch-quality">
53 <title>Quality Assurance
</title>
56 (Or,
"How do I get Alexandre to apply my patch quickly so I
57 can build on it and it will not go stale?")
60 Make sure your patch applies to the current CVS head
61 revisions. If a bunch of patches are commited to CVS that may
62 affect whether your patch will apply cleanly then verify that
63 your patch does apply!
<command>cvs update
</command> is your
67 Save yourself some embarasment and run your patched code
68 against more than just your current test example. Experience
69 will tell you how much effort to apply here.
75 <!-- Keep this comment at the end of the file
78 sgml-parent-document:("wine-doc.sgml" "set" "book" "part" "chapter" "")