# HG changeset patch # User michael # Date 1172790598 0 # Node ID b42d79ee1af8052d6670829f54b522d54099ba93 # Parent 6c9a391ca7cb1aa3abfed024e10ee38e2ea3b1c2 rename to *_proposal.txt diff -r 6c9a391ca7cb -r b42d79ee1af8 DOCS/tech/new_policy.txt --- a/DOCS/tech/new_policy.txt Thu Mar 01 22:58:31 2007 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,307 +0,0 @@ -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 misunderstand, 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 - -Author: -------- -Michael Niedermayer -the authors of the old policy as i liberally copy and pasted from it - -TODO: -add more explanations, justifications and examples -how to become/loose maintainer status -review patches.txt -security/exploit rules ------------------------- - - -1. Definitions --------------- -* MPlayer developer, generally referred to simply as developer in this document - is any person who has a open (not cracked, not suspended) svn write account -* MPlayer leader, generally referred to simply as leader in this document, every - leader is also a developer -* CAN/MUST/SHOULD 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 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 - the size of diffs. - - To split a file, use 'svn copy' and remove the unneeded lines from each file. - - Don't do a lot of cut'n'paste from one file to another without a very good - reason and discuss it on the mplayer-dev-eng mailing list first. It will make - those changes hard to trace. - - 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: - svn merge - svn ci - This simply changes the file(s) back to their old version localy and then - the change is commited as if it is a new change - The svn copy method - svn rm - svn ci - svn cp -r svn://svn.mplayerhq.hu/mplayer/trunk/[/] - svn ci - This simply removes the file and then copies the last good version with - its history over it, this method can only be used to revert the n last - commits but not to revert a bad commit in the middle of its history - Neither method will change the history, checking out an old version will - always return exactly that revision with all its bugs and features. The - difference is that with the svn copy method the broken commit will not be - part of the directly visible history of the revisions after the reversal - So if the change was completely broken like reindenting a file against the - maintainers decision, or a change which mixed functional and cosmetic - changes then it is better if it is not part of the visible history as it - would make it hard to read, review and would also break svn annotate - For the example of a change which mixed functional and cosmetic parts they - should of course be committed again after the reversal but separately, so one - change with the functional stuff and one with the cosmetics - OTOH if the change which you want to reverse was simply buggy but not - totally broken then it should be reversed with svn merge as otherwise - the fact that the change was bad would be hidden - One method to decide which reversal method is best is to ask yourself - if there is any value in seeing the whole bad change and its removal - in SVN vs just seeing a comment that says what has been reversed while - the actual change does not clutter the immediately visible history and - svn annotate. - If you are even just slightly uncertain how to revert something then ask on - the mplayer-dev-eng mailing list. - -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. - -Splitting changes - Do not commit unrelated changes together, split them into self-contained - pieces. - if you have any doubt discuss it on the developer mailing list before - committing, also when in doubt more splitting is better then less, changes - which are larger then 10kbyte generally should be split into several - incremental changes 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 debugging 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 - the mplayer-dev-eng mailing list. - - -5. Do not commit changes to the build system (Makefiles, configure script) - which change behaviour, defaults etc, without asking first. The same - applies to compiler warning fixes, trivial looking fixes and to code - maintained by other developers. We usually have a reason for doing things - the way we do. Send your changes as patches to the mplayer-dev-eng mailing - list, and if the code maintainers say OK, you may commit. This does not - 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 - indentation changes (try to avoid this), separate them strictly from real - changes. - - NOTE: If you had to put if(){ .. } over a large (> 5 lines) chunk of code, - 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 - you applied the patch. If the patch contains a documentation change, commit - 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 - - changes to "special" output messages (like the "Core dumped ;)" message) - - 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 - - -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 leaders may fork the project, - the leaders 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 leaders, though of -course they can leave the project and thus cease to be a developer or leader -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 - -Vp. Proposing an option (point on the ballot, better term?) -Any single developer can propose an option up to 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 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 answered with true or false - -Vv. Voting -Any developer can cast a vote up to 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 leader can cast a veto against any option except the default up to 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 leaders who use gpg/pgp MUST sign their votes and vetoes - -Vc. Counting votes -The person starting the vote has to count the votes and vetoes 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 vetoes -if the majority of leaders that is yes >= no && yes>0 cast a veto against an -option then it has a required supermajority of 2:1 otherwise it has a -required supermajority of 0:1 and in either case no quorum requirement -Vcc. the votes shall be counted by using the Condorcet/Clone Proof SSD -Voting Method described in http://www.debian.org/devel/constitution A.6 - -Reasoning behind avoiding of a quorum and majority requirement except in -the case of vetoes -short awnser its stupid and has catastrophical failure modes -example of one such failure mode, lets assume a 1:1 majority requirement -as debian uses by default, there are 101 developers who vote, there are -3 options A,B and D the default (doing nothing / further discussions) -50 developers prefer A over B and B over discussions (A>B>D) -50 developers prefer discussions over A and A over B (D>A>B) -1 developer prefers B over discussions and discussions over A (B>D>A) -in this case A is approved by 50 of 101 developers and is droped due to -the lack of majority, B is approved by 51 of 101 developers and is not -furthermore B wins even though 100 of 101 developers prefer A over B - - -S. Changes to developer and Leader status ----------------------------------------- -The majority of leaders, that is yes>no can give and take away -developer and leader status to people -furthermore any developer or leader can step back and thus loose -his leader and or developer status -People disagreeing with the leaders 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 leader can after at least one leader has warned another developer -due to breaking policy, suspend his account if he repeats the violation -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 diff -r 6c9a391ca7cb -r b42d79ee1af8 DOCS/tech/new_policy_proposal.txt --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/DOCS/tech/new_policy_proposal.txt Thu Mar 01 23:09:58 2007 +0000 @@ -0,0 +1,307 @@ +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 misunderstand, 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 + +Author: +------- +Michael Niedermayer +the authors of the old policy as i liberally copy and pasted from it + +TODO: +add more explanations, justifications and examples +how to become/loose maintainer status +review patches.txt +security/exploit rules +------------------------ + + +1. Definitions +-------------- +* MPlayer developer, generally referred to simply as developer in this document + is any person who has a open (not cracked, not suspended) svn write account +* MPlayer leader, generally referred to simply as leader in this document, every + leader is also a developer +* CAN/MUST/SHOULD 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 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 + the size of diffs. + + To split a file, use 'svn copy' and remove the unneeded lines from each file. + + Don't do a lot of cut'n'paste from one file to another without a very good + reason and discuss it on the mplayer-dev-eng mailing list first. It will make + those changes hard to trace. + + 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: + svn merge + svn ci + This simply changes the file(s) back to their old version localy and then + the change is commited as if it is a new change + The svn copy method + svn rm + svn ci + svn cp -r svn://svn.mplayerhq.hu/mplayer/trunk/[/] + svn ci + This simply removes the file and then copies the last good version with + its history over it, this method can only be used to revert the n last + commits but not to revert a bad commit in the middle of its history + Neither method will change the history, checking out an old version will + always return exactly that revision with all its bugs and features. The + difference is that with the svn copy method the broken commit will not be + part of the directly visible history of the revisions after the reversal + So if the change was completely broken like reindenting a file against the + maintainers decision, or a change which mixed functional and cosmetic + changes then it is better if it is not part of the visible history as it + would make it hard to read, review and would also break svn annotate + For the example of a change which mixed functional and cosmetic parts they + should of course be committed again after the reversal but separately, so one + change with the functional stuff and one with the cosmetics + OTOH if the change which you want to reverse was simply buggy but not + totally broken then it should be reversed with svn merge as otherwise + the fact that the change was bad would be hidden + One method to decide which reversal method is best is to ask yourself + if there is any value in seeing the whole bad change and its removal + in SVN vs just seeing a comment that says what has been reversed while + the actual change does not clutter the immediately visible history and + svn annotate. + If you are even just slightly uncertain how to revert something then ask on + the mplayer-dev-eng mailing list. + +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. + +Splitting changes + Do not commit unrelated changes together, split them into self-contained + pieces. + if you have any doubt discuss it on the developer mailing list before + committing, also when in doubt more splitting is better then less, changes + which are larger then 10kbyte generally should be split into several + incremental changes 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 debugging 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 + the mplayer-dev-eng mailing list. + + +5. Do not commit changes to the build system (Makefiles, configure script) + which change behaviour, defaults etc, without asking first. The same + applies to compiler warning fixes, trivial looking fixes and to code + maintained by other developers. We usually have a reason for doing things + the way we do. Send your changes as patches to the mplayer-dev-eng mailing + list, and if the code maintainers say OK, you may commit. This does not + 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 + indentation changes (try to avoid this), separate them strictly from real + changes. + + NOTE: If you had to put if(){ .. } over a large (> 5 lines) chunk of code, + 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 + you applied the patch. If the patch contains a documentation change, commit + 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 + - changes to "special" output messages (like the "Core dumped ;)" message) + - 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 + + +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 leaders may fork the project, + the leaders 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 leaders, though of +course they can leave the project and thus cease to be a developer or leader +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 + +Vp. Proposing an option (point on the ballot, better term?) +Any single developer can propose an option up to 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 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 answered with true or false + +Vv. Voting +Any developer can cast a vote up to 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 leader can cast a veto against any option except the default up to 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 leaders who use gpg/pgp MUST sign their votes and vetoes + +Vc. Counting votes +The person starting the vote has to count the votes and vetoes 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 vetoes +if the majority of leaders that is yes >= no && yes>0 cast a veto against an +option then it has a required supermajority of 2:1 otherwise it has a +required supermajority of 0:1 and in either case no quorum requirement +Vcc. the votes shall be counted by using the Condorcet/Clone Proof SSD +Voting Method described in http://www.debian.org/devel/constitution A.6 + +Reasoning behind avoiding of a quorum and majority requirement except in +the case of vetoes +short awnser its stupid and has catastrophical failure modes +example of one such failure mode, lets assume a 1:1 majority requirement +as debian uses by default, there are 101 developers who vote, there are +3 options A,B and D the default (doing nothing / further discussions) +50 developers prefer A over B and B over discussions (A>B>D) +50 developers prefer discussions over A and A over B (D>A>B) +1 developer prefers B over discussions and discussions over A (B>D>A) +in this case A is approved by 50 of 101 developers and is droped due to +the lack of majority, B is approved by 51 of 101 developers and is not +furthermore B wins even though 100 of 101 developers prefer A over B + + +S. Changes to developer and Leader status +---------------------------------------- +The majority of leaders, that is yes>no can give and take away +developer and leader status to people +furthermore any developer or leader can step back and thus loose +his leader and or developer status +People disagreeing with the leaders 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 leader can after at least one leader has warned another developer +due to breaking policy, suspend his account if he repeats the violation +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