[MPlayer-cvslog] r22386 - trunk/DOCS/tech/new_policy.txt
Ivan Kalvachev
ikalvachev at gmail.com
Thu Mar 1 11:40:47 CET 2007
2007/3/1, michael <subversion at mplayerhq.hu>:
> 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
>
[...]
> +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
misunderstand (according to my spell checker it have single S ;)
> +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
>
[...]
> +Author:
> +-------
> +Michael Niedermayer
> +the authors of the old policy as i liberally copy and pasted from it
>
[...]
> +TODO:
> +add more explanations, justificaions and examples
justificaTions
> +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
2*refeRRed
> + admin is also a developer
> +* CAN/MUST/SHOULD desriptions ...
desCriptions
> +* public developer mailing list (mplayer-dev-eng at mplayerhq in hungary)
>
>
> +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.
>
> -
> +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.
>
[...]
> -II. POLICY / RULES:
> -===================
> -
> +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.
>
> -
> +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
Splitting
> + 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
discuss
> + commiting, also when in doubt more spliting is better then less, changes
committing, splitting
> + which are larger then 10kbyte generally should be split into several
> + incremental chanegs if possible even if you think they are all related
changes
> + 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
debugging
>
> +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.
>
>
> +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)!
>
>
> +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.
>
>
> +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.
>
>
> +messing with other developers code
> + Do NOT commit to code actively maintained by others without permission. Send
> a patch to mplayer-dev-eng instead.
>
>
> +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.
>
>
> +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.
>
>
> +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
>
>
> +Patches
> + read and follow patches.txt when sending patches for mplayer
>
>
> +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
>
>
> +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
>
>
> +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
>
>
> +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
she? Only women can start a vote?
> +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
>
> +Vp. Proposing an option (point on the ballot, better term?)
> +Any single developer can propose an option upto 7 days after a vote has
up to
> +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
describe
> +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
answered
>
> +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
2 more "up to"
> +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
>
> +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
3*vetoes
> +that is yes >= no && yes>0 cast a veto against it
> +Vcc. the votes shall be counted by using the Condorcet/Clone Proof SSD
Is it this one http://en.wikipedia.org/wiki/Schulze_method ?
> +Voting Method
>
> +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
>
>
> +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
account
> +Ow. A policy violation warning MUST be CCed to the developer who violated
> +the policy
>
>
> +We think our rules are not too hard. If you have comments, contact us.
> \ No newline at end of file
I don't think that your voting system takes meritocracy into account.
There is also a lot of unclear things - the definition of admin (e.g.
case where (s)he is root of mphq but not developer)
Also it is not clear what happens when winning option is selected.
About suspending account. What happens if I commit trojan in code I
maintain. I'm not breaking any existing rule.
After the new rule is added would my account be suspended on first or
on the second offense?
More information about the MPlayer-cvslog
mailing list