[Mplayer-cvslog] CVS: main/DOCS/tech patches.txt,1.23,1.24

[Diego Biurrun CVS]

CVS change done by Diego Biurrun CVS

Update of /cvsroot/mplayer/main/DOCS/tech
In directory mail:/var2/tmp/cvs-serv26125/DOCS/tech

Modified Files:
	patches.txt 
Log Message:
some new patch policy: compression, mail threading, printf vs mp_msg


Index: patches.txt
===================================================================
RCS file: /cvsroot/mplayer/main/DOCS/tech/patches.txt,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- patches.txt	26 Aug 2004 19:46:12 -0000	1.23
+++ patches.txt	6 Sep 2004 09:05:38 -0000	1.24
@@ -60,7 +60,7 @@
     Do not compress your patch unless it is larger than 80k or if you know
     that your mailer messes up (reformats) text attachments. It only makes
     handling the patch more difficult. If you have to compress your patch,
-    use bzip2 or gzip to compress it, not another non-standard format.
+    use either bzip2, gzip or zip to compress it, not a different format.
     You have to subscribe to mplayer-dev-eng since we blocked postings from
     non-subscribers after spam problems and because patches get reviewed by
     the developers on the list. We want you to be available for discussing
@@ -68,17 +68,22 @@
     Don't worry, mplayer-dev-eng is not high traffic and you can subscribe
     but unset the "Mail delivery" option so that you can post without getting
     any mails.
-    Try to avoid uploading the patch to a web or FTP site, send it directly
-    to the mailing list. The fewer steps it takes us to get at the patch the
-    higher the likelihood for it to get reviewed and applied. If your patch
-    is so big you cannot send it by mail, try splitting it into pieces.
+    Do not upload the patch to a web or FTP site, send it directly to the
+    mailing list. The fewer steps it takes us to get at the patch the higher
+    the likelihood for it to get reviewed and applied. If your patch is so
+    big you cannot send it by mail, try splitting it into smaller pieces.
 
  9. Give us a few days to react. We try to review patches as fast as possible,
     but unfortunately we are constantly overloaded with work, be it MPlayer-
     related or from our day to day lives. If your patch seems to be ignored,
-    please resend it and mention that you got ignored. We are interested in
-    your work and will eventually either accept it or reject it with an
-    explanation of what we disliked about your patch.
+    send a reminder asking for opinions as a reply to the original patch and
+    mention that you got ignored. We are interested in your work and will
+    eventually either accept it or reject it with an explanation of what we
+    disliked about your patch. We will often ask you to make changes to your
+    patch to make it acceptable. Implement them if you want to see your patch
+    applied and send the update to the mailing list. Remember that updates and
+    reminders must be sent as replies to the original patch to preserve proper
+    mail threading.
 
 10. Do not immediately ask for CVS write access. If you have contributed one or
     more nice, acceptable patches and they need maintaining or you want to
@@ -89,4 +94,12 @@
 12. If you make a nontrivial contribution and wish to be mentioned in the
     AUTHORS file, include that in your patch.
 
+13. Do not use printf for console output, use our own mp_msg functions instead.
+    For the output to be translated (which includes all messages of level
+    MSGL_HINT and below), put the strings in help/help_mp-en.h. If you change
+    strings, remove the occurrences of these strings from the translations.
+    There may be (compilation) trouble if outdated translations remain in place
+    and translators will pick up changes more easily if they see a new message
+    that has to be translated.
+
 Thank you!