Patches are submitted via email to the Wine patches mailing list, wine-patches@winehq.org. Your patch should include: A meaningful subject (very short description of patch) A long (paragraph) description of what was wrong and what is now better. (recommended) A change log entry (short description of what was changed). The patch in diff -u format cvs diff -u works great for the common case where a file is edited. However, if you add or remove a file cvs diff will not report that correctly so make sure you explicitly take care of this rare case. For additions simply include them by appending the diff -u /dev/null /my/new/file output of them to any cvs diff -u output you may have. Alternatively, use diff -Nu olddir/ newdir/ in case of multiple new files to add. For removals, clearly list the files in the description of the patch. Since wine is constantly changing due to development it is strongly recommended that you use cvs for patches, if you cannot use cvs for some reason, you can submit patches against the latest tarball. To do this make a copy of the files that you will be modifying and diff -u against the old file. I.E. diff -u file.old file.c > file.txt There are a few conventions that about coding style that have been adopted over the years of development. The rational for these rules is explained for each one. No HTML mail, since patches should be in-lined and HTML turns the patch into garbage. Also it is considered bad etiquette as it uglifies the message, and is not viewable by many of the subscribers. Only one change set per patch. Patches should address only one bug/problem at a time. If a lot of changes need to be made then it is preferred to break it into a series of patches. This makes it easier to find regressions. Tabs are not forbidden but discouraged. A tab is defined as 8 characters and the usual amount of indentation is 4 characters. C++ style comments are discouraged since some compilers choke on them. Commenting out a block of code is usually done by enclosing it in #if 0 ... #endif Statements. For example. /* note about reason for commenting block */ #if 0 code code /* comments */ code #endif The reason for using this method is that it does not require that you edit comments that may be inside the block of code. Patches should be in-lined (if you can configure your email client to not wrap lines), or attached as plain text attachments so they can be read inline. This may mean some more work for you. However it allows others to review your patch easily and decreases the chances of it being overlooked or forgotten. Code is usually limited to 80 columns. This helps prevent mailers mangling patches by line wrap. Also it generally makes code easier to read. Outlook Express is notorious for mangling attachments. Giving the patch a .txt extension and attaching will solve the problem for most mailers including Outlook. Also, there is a way to enable Outlook Express send .diff attachments. You need following two things to make it work. Make sure that .diff files have \r\n line ends, because if OE detects that there is no \r\n line endings it switches to quoted-printable format attachments. Using regedit add key "Content Type" with value "text/plain" to the .diff extension under HKEY_CLASSES_ROOT (same as for .txt extension). This tells OE to use Content-Type: text/plain instead of application/octet-stream. Item #1 is important. After you hit "Send" button, go to "Outbox" and using "Properties" verify the message source to make sure that the mail has correct format. You might want to send several test emails to yourself too. The basic rules are: no attachments, no mime crap, no line wrapping, a single patch per mail. Basically if I can't do "cat raw_mail | patch -p0" it's in the wrong format. (Or, "How do I get Alexandre to apply my patch quickly so I can build on it and it will not go stale?") Make sure your patch applies to the current CVS head revisions. If a bunch of patches are committed to CVS that may affect whether your patch will apply cleanly then verify that your patch does apply! cvs update is your friend! Save yourself some embarrassment and run your patched code against more than just your current test example. Experience will tell you how much effort to apply here.