[MPlayer-cvslog] r22386 - trunk/DOCS/tech/new_policy.txt
michael
subversion at mplayerhq.hu
Thu Mar 1 04:43:38 CET 2007
Author: michael
Date: Thu Mar 1 04:43:38 2007
New Revision: 22386
Added:
trunk/DOCS/tech/new_policy.txt
- copied, changed from r22385, /trunk/DOCS/tech/svn-howto.txt
Log:
new policy draft
Copied: trunk/DOCS/tech/new_policy.txt (from r22385, /trunk/DOCS/tech/svn-howto.txt)
==============================================================================
--- /trunk/DOCS/tech/svn-howto.txt (original)
+++ trunk/DOCS/tech/new_policy.txt Thu Mar 1 04:43:38 2007
@@ -1,146 +1,43 @@
+New Policy Draft
+Version 20070301
-About Subversion write access:
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Before everything else, you should know how to use Subversion properly.
-Luckily Subversion comes with excellent documentation.
-
- svn help
-
-shows you the available subcommands,
-
- svn help <command>
-
-shows information about the subcommand <command>.
-
-The most comprehensive manual is the book "Version Control with Subversion"
-by Ben Collins-Sussman, Brian W. Fitzpatrick and C. Michael Pilato. It can
-be viewed online at
-
-http://svnbook.org/
-
-For more information about the Subversion project, visit
-
-http://subversion.tigris.org/
-
-Consult these resources whenever you have problems, they are quite exhaustive.
-
-What follows now is a basic introduction to Subversion and some MPlayer-specific
-guidelines. Read it at least once, if you are granted commit privileges to the
-MPlayer project you are expected to be familiar with these rules.
-
-
-
-I. BASICS:
-==========
-
-0. Get Subversion:
-
- The MPlayer project server runs Subversion 1.2.3. For optimal compatibility
- you should use version 1.2.3 or later.
-
-
-1. Checking out the source tree:
-
- svn checkout svn://svn.mplayerhq.hu/mplayer/trunk/ <target>
-
- This will put the MPlayer sources into the directory <target>.
-
-
-2. Updating the source tree to the latest revision:
-
- svn update
-
- pulls in the latest changes from the repository to your working directory.
-
-
-3. Adding/removing files/directories:
-
- svn add <filename/dirname>
- svn delete <filename/dirname>
-
- Subversion needs to get notified of all changes you make to your working
- directory.
-
-
-4. Showing modifications:
-
- svn diff <filename(s)>
-
- will show all local modifications in your working directory as unified diff.
-
-
-5. Inspecting the changelog:
-
- svn log <filename(s)>
-
- You may also find viewvc, a web frontend for Subversion, helpful. It's often
- more comfortable than using 'svn log' and 'svn diff'. Find it here:
- http://svn.mplayerhq.hu/mplayer/trunk/
-
-
-6. Checking source tree status:
-
- svn status
-
- detects all the changes you made and lists what actions will be taken in case
- of a commit (additions, modifications, deletions, etc.).
-
-
-7. Committing:
-
- svn update
-
- Run 'svn update' before committing to make sure there were no changes to the
- files you worked on in the meantime. Afterwards look at the output of
-
- svn diff <filename(s)>
-
- to doublecheck your changes before committing to avoid trouble later on. All
- experienced developers do this on each and every commit, no matter how small.
- Every one of them has been saved from looking like a fool by this many times.
- It's very easy for stray debug output or cosmetic modifications to slip in,
- please avoid problems through this extra level of scrutiny.
-
- Also check the output of
-
- svn status
-
- to make sure you did not forget to 'svn add' some files (they will be marked
- with '?').
-
- Once you have made sure everything is fine
-
- svn commit <filename(s)>
-
- propagates your stuff to the repository. If you have made several independent
- changes, commit them separately, not at the same time.
-
- When prompted for a password, type the password you got assigned by the
- project admins. By default, Subversion caches all authentication tokens.
- This behaviour can be disabled by setting both 'store-passwords' and
- 'store-auth-creds' to "no" in ~/.subversion/config. You might need to remove
- previous cache files, which are located in ~/.subversion/auth, by hand.
+Intro:
+------
+This document is an attempt to write a new policy as the old is fairly
+confusing and easy to missunderstand, its intention is not really to
+change the rules but rather to write them down clearer ...
+also for simplicity and to prevent flamewars, i would suggest that you
+fork this document and propose that fork as alternative if you have a
+significant disagreement with me on some part
- You will be prompted for a log message in an editor, which is either specified
- by --editor-cmd on the command line, set in your personal configuration file
- (~/.subversion/config) or set by one of the following environment variables:
- SVN_EDITOR, VISUAL or EDITOR.
+Author:
+-------
+Michael Niedermayer
+the authors of the old policy as i liberally copy and pasted from it
- Log messages should be concise but descriptive. Explain why you made a change,
- what you did will be obvious from the changes themselves most of the time.
- Saying just "bug fix" or "10l" is bad. Remember that people of varying skill
- levels look at and educate themselves while reading through your code. Don't
- include filenames in log messages, Subversion provides that information.
+TODO:
+add more explanations, justificaions and examples
+how to become/loose maintainer status
+review patches.txt
+security/exploit rules
+------------------------
-8. Renaming/moving/copying files or contents of files:
+1. Definitions
+--------------
+* MPlayer developer, generally refered to simply as developer in this document
+ is any person who has a open (not cracked, not suspended) svn write account
+* MPlayer admin, generally refered to simply as admin in this document, every
+ admin is also a developer
+* CAN/MUST/SHOULD desriptions ...
+* public developer mailing list (mplayer-dev-eng at mplayerhq in hungary)
- svn move/copy <source> <destination>
- svn commit <source> <destination>
+C. Code and SVN Rules
+-----------------------------
+Renaming/moving/copying files or contents of files
Do not move, rename or copy files of which you are not the maintainer without
- discussing it on the mplayer-dev-eng mailing list first!
+ discussing it on the public developer mailinglist first!
Never copy or move a file by using 'svn delete' and 'svn add'. Always use
'svn move' or 'svn copy' instead in order to preserve history and minimize
@@ -155,9 +52,7 @@ I. BASICS:
Such actions are useless and treated as cosmetics in 99% of cases,
so try to avoid them.
-
-9. Reverting broken commits
-
+Reverting broken commits
There are 2 ways to reverse a change, they differ significantly in what they
do to the svn repository
The recommit old method:
@@ -195,50 +90,32 @@ I. BASICS:
If you are even just slightly uncertain how to revert something then ask on
the mplayer-dev-eng mailing list.
-
-10. Reverting local changes
-
- svn revert <filename(s)>
-
- In case you made a lot of local changes to a file and want to start over
- with a fresh checkout of that file, you can use 'svn revert <filename(s)>'.
- NOTE: This has nothing to do with reverting changes on the Subversion
- server! It only reverts changes that were not committed yet. If you need
- to revert a broken commit, see 9.
-
-
-11. Changing commit messages
-
- svn propedit svn:log --revprop -r <revision>
-
- If your commit message is too short or not explanatory enough, you can edit
- it afterwards with 'svn propedit'.
-
-
-Contact the project admins <root at mplayerhq dot hu> if you have technical
-problems with the Subversion server.
-
-
-
-II. POLICY / RULES:
-===================
-
-1. You must not commit code which breaks MPlayer! (Meaning unfinished but
+Broken code
+ You must not commit code which breaks MPlayer! (Meaning unfinished but
enabled code which breaks compilation or compiles but does not work.)
You can commit unfinished stuff (for testing etc), but it must be disabled
(#ifdef etc) by default so it does not interfere with other developers'
work.
-
-2. You don't have to over-test things. If it works for you, and you think it
+Testing code
+ You don't have to over-test things. If it works for you, and you think it
should work for others, too, then commit. If your code has problems
(portability, exploits compiler bugs, unusual environment etc) they will be
reported and eventually fixed.
-
-3. Do not commit unrelated changes together, split them into self-contained
+Spliting changes
+ Do not commit unrelated changes together, split them into self-contained
pieces.
+ if you have any doubt disscuss it on the developer mailing list before
+ commiting, also when in doubt more spliting is better then less, changes
+ which are larger then 10kbyte generally should be split into several
+ incremental chanegs if possible even if you think they are all related
+ keeping changes well split makes reviewing and understanding them on
+ svn log at the time of commit and later when debuging a bug much easier
+Compiler Warning fixes
+ Do not change code to hide warnings without ensuring that the underlaying
+ logic is correct and thus the warning was inappropriate
4. Do not change behavior of the program (renaming options etc) or
remove functionality from the code without approval in a discussion on
@@ -254,8 +131,9 @@ II. POLICY / RULES:
apply to files you wrote and/or maintain.
-6. We refuse source indentation and other cosmetic changes if they are mixed
- with functional changes, such commits will be rejected and removed. Every
+Cosmetics
+ We refuse source indentation and other cosmetic changes if they are mixed
+ with functional changes, such commits will be reverted. Every
developer has his own indentation style, you should not change it. Of course
if you (re)write something, you can use your own style... (Many projects
force a given indentation style - we don't.) If you really need to make
@@ -266,12 +144,14 @@ II. POLICY / RULES:
do NOT change the indentation of the inner part (don't move it to the right)!
-7. Always fill out the commit log message. Describe in a few lines what you
+Commit log message
+ Always fill out the commit log message. Describe in a few lines what you
changed and why. You can refer to mailing list postings if you fix a
particular bug. Comments such as "fixed!" or "Changed it." are unacceptable.
-8. If you apply a patch by someone else, include the name and email address in
+Applying patches
+ If you apply a patch by someone else, include the name and email address in
the log message. Since the mplayer-cvslog mailing list is publicly
archived you should add some spam protection to the email address. Send an
answer to mplayer-dev-eng (or wherever you got the patch from) saying that
@@ -279,22 +159,26 @@ II. POLICY / RULES:
that as well; do not leave it to the documentation maintainers.
-9. Do NOT commit to code actively maintained by others without permission. Send
+messing with other developers code
+ Do NOT commit to code actively maintained by others without permission. Send
a patch to mplayer-dev-eng instead.
-10. Subscribe to the mplayer-cvslog mailing list. The diffs of all commits
+Subscribe to svnlog
+ Subscribe to the mplayer-cvslog mailing list. The diffs of all commits
are sent there and reviewed by all the other developers. Bugs and possible
improvements or general questions regarding commits are discussed there. We
expect you to react if problems with your code are uncovered.
-11. Update the documentation if you change behavior or add features. If you are
+Documentation
+ Update the documentation if you change behavior or add features. If you are
unsure how best to do this, send a patch to mplayer-docs, the documentation
maintainers will review and commit your stuff.
-12. Always send a patch to the mplayer-dev-eng mailing list before committing
+Controversial changes
+ Always send a patch to the mplayer-dev-eng mailing list before committing
if you suspect that the change is going to be controversial. Based on past
experience, these changes are likely to be controversial:
- feature removal, even if obsolete
@@ -302,87 +186,106 @@ II. POLICY / RULES:
- verbosity changes from default (info) level
- changes to "historical" parts of docs and webpages
- use of internal or external libraries
+ - changes to the internal architecture
+ - non trivial changes to very fundamental parts of mplayer
-13. Try to keep important discussions and requests (also) on the
+Public discussions
+ Try to keep important discussions and requests (also) on the
mplayer-dev-eng mailing list, so that all developers can benefit from them.
IRC is good for quick discussions, but nobody is there 24/7.
+ also subscribe to the public developer mailing list
-Also read DOCS/tech/patches.txt !!!!
-
-We think our rules are not too hard. If you have comments, contact us.
-
-
-
-III. Beginners Guide
-====================
-
-The typical flow of development would be:
-
-1. Check out the source:
-
- svn checkout svn://svn.mplayerhq.hu/mplayer/trunk/ devel
-
-
-2. Make your changes.
-
-
-3. Create a patch:
-
- Run 'svn diff' from the root of the source tree, like this:
-
- cd devel
- svn diff > ../my_changes.patch
-
- If you have made several changes, but only want to submit one for review
- by other developers, you can specify the filename(s), for example:
-
- svn diff mplayer.c > ../major_cleanup.patch
-
-
-4. Check the patch:
+Patches
+ read and follow patches.txt when sending patches for mplayer
- Check out another, clean source tree and verify your patch:
- svn checkout svn://svn.mplayerhq.hu/mplayer/trunk/ clean
- cd clean
- patch -p0 --dry-run < ../my_changes.patch
+Insults
+ Do not insult other people in relation to mplayer on any public mailing
+ list, that is calling code from someone else a pile of broken shit is
+ perfectly fine but calling the developer herself a retarded f*cking moron
+ is not acceptable
- If there are no errors, you can apply your patch:
- patch -p0 < ../my_changes.patch
+Forking
+ People disagreeing with the developers or admins may fork the project,
+ the admins MUST in that case provide a svn dump with all history if
+ the person forking wants one
- After that, verify that MPlayer still builds correctly with your patch
- applied. Also, be sure that your patch meets our policy as described in
- section II, specifically rules 1 to 6, before you continue submitting
- the patch.
+Communicating passwords
+ Developers who have provided a public gpg key shall only receive
+ passwords or other sensitive information related to mplayer encrypted
+ with their gpg key
-5. Submit the patch:
- Send an e-mail to the mplayer-dev-eng mailing list. Describe what your
- patch does and why, and attach the patch file for review by others.
+V. Votes
+--------
+Its inevitable that some things will be decided by voting, votes in the past
+have due to total lack of rules been problematic for example as many people
+rather wrote long texts and voted based on some condition instead of saying
+a clear yes or no, still its important that people can vote based on a
+condition
+The result of a vote is binding for all developers and admins, though of
+course they can leave the project and thus cease to be a developer or admin
+any time
+Vs. Starting a vote
+Any single developer can start a vote, to do so she has to send a mail to the
+public developer mailing list of the project with a subject containing [VOTE]
+and a clear and concise description, a longer descrition can be in the body
+of the mail
-6. During the review process, incorporate all suggested fixes. Go to step 2
- repeatedly until there is nothing more to do for step 6. Of course, if
- you don't agree with certain suggestions, things can be discussed on
- the mailing list in a polite manner.
+Vp. Proposing an option (point on the ballot, better term?)
+Any single developer can propose an option upto 7 days after a vote has
+been started, to do so she has to reply to the original vote mail on the
+public developer mailing list and clearly, concise and unmistakably desribe
+the option and place [VOTE-OPTION] instead of [VOTE] in the subject
+in addition to proposed options, there always exists the default option
+of doing nothing
+options can be conditional on anything which at the end of the vote can
+be clearly and unmistakably be awnsered with true or false
+Vv. Voting
+Any developer can cast a vote upto 10 days days after a vote has been
+started, to do so she has to reply to the original vote mail on the
+public developer mailing list and rate options each with an integer
+unrated options shall be counted equal to the default option
+Any admin can cast a veto against any option except the default upto 10 days
+days after a vote has been started, to do so she has to reply to the original
+vote mail on the public developer mailing list and replace
+[VOTE] by [VOTE-VETO]
+Developers and admins who use gpg/pgp MUST sign their votes and vetos
-7. Commit the patch:
+Vc. Counting votes
+The person starting the vote has to count the votes and vetos and publish
+the result on the public developer mailing list as reply to the original vote
+with [VOTE-RESULTS] instead of [VOTE] in the subject
+Vcv. Counting vetos, an option shall be removed if the majority of admins
+that is yes >= no && yes>0 cast a veto against it
+Vcc. the votes shall be counted by using the Condorcet/Clone Proof SSD
+Voting Method
- If your patch is accepted, double check if your source tree contains the
- most recent version of your patch with 'svn diff'! After verifying that
- you met these conditions, commit with:
+S. Changes to developer and Admin status
+----------------------------------------
+The majority of admins, that is yes>no can give and take away
+developer and admin status to people
+furthermore any developer or admin can step back and thus loose
+his admin and or developer status
+People disagreeing with the admins are free to fork the project
+new developers should be asked for real name, public gpg key, phone
+number and email addresses, none of this is mandatory though, it is asked
+so as to be able to contact the developer if the need arises and one
+contact method fails
- svn commit <filename(s)>
- Go to step 2 ad infinitum until MPlayer is the perfect media player ;)
+O. Violations
+-------------
+Any admin can after at least one admin has warned another developer
+due to breaking policy, suspend his acount if he repeats the violation
+Ow. A policy violation warning MUST be CCed to the developer who violated
+the policy
-Note: If you are listed as the maintainer for a particular piece of code,
-you can skip step 5 and 6 if your patch _only_ applies to the code you
-maintain. If it touches other code or is otherwise very intrusive, please
-post it to mplayer-dev-eng first.
+We think our rules are not too hard. If you have comments, contact us.
\ No newline at end of file
More information about the MPlayer-cvslog
mailing list