# HG changeset patch
# User arpi
# Date 1002472487 0
# Node ID 95b8a1e7962d341fa7a3cb9bf98ea498d7a8d7da
# Parent  83df55c88850117719c6bb722d370a62763798f1
sending patches

diff -r 83df55c88850 -r 95b8a1e7962d DOCS/tech/patches.txt
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/DOCS/tech/patches.txt	Sun Oct 07 16:34:47 2001 +0000
@@ -0,0 +1,32 @@
+Sending patches:
+~~~~~~~~~~~~~~~~
+Note: We know these rules are hard, but it's hard to maintain such
+big and complex project, so you should accept our rules. We have no
+time for fixing buggy, broken or old patches!
+
+1. Always make patch for the CVS version.
+   We do not accept patches for old versions or releases.
+
+2. Make unified diffs ('diff -Naur' or 'cvs diff -u')
+
+3. Test functionality of your patch. We'll *refuse* it if it breaks
+   something, even if it extends other features!
+
+4. Read your patch. We'll *refuse* it if it changes indent of the
+   code or it does tab/space or other cosmetical changes!
+
+5. Comment parts what really needs it (has tricky side-effects etc).
+   Commenting trivial code not requires. Comments must be english!
+   
+6. Do not ask for CVS write access at first time. If you contributed
+   1 or more nice, acceptable patches and they need maintaining or
+   you want to be mplayer developer, you'll get CVS write access.
+   
+7. Subscribe to the mplayer-dev-eng list (don't worry, it's low traffic)
+   and send your patch there as base64-encoded attachment (use gzip or
+   bzip2 *only* if it's really big). Also describe in a few sentences
+   what (and why) are the changes.
+
+Thank you!
+
+A'rpi