Mercurial > mplayer.hg
view DOCS/tech/new_policy_proposal.txt @ 27710:b04b6b6d68ca
cosmetics: Move some config.h entries to more sensible places.
| author | diego |
|---|---|
| date | Fri, 10 Oct 2008 21:56:03 +0000 |
| parents | 9a299c7e30b0 |
| children | 0f1b5b68af32 |
line wrap: on
line source
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 <file> 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 <file> svn ci <file> svn cp -r<good revision> svn://svn.mplayerhq.hu/mplayer/trunk/[<path>/]<file> <file> svn ci <file> 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. Also dont forget that if part B depends on part A but A doesnt depend on B, then A can and should be commited first and seperately from B. Keeping changes well split into self contained parts makes reviewing and understanding them on svn log at the time of commit and later when debugging a bug much easier. Also if you have doubt about spliting or not spliting, dont hesitate to ask/disscuss it on the developer mailing list. 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, then either do NOT change the indentation of the inner part within (don't move it to the right)! or do so in a separate commit 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 Compiler Warning fixes Do not change code to hide warnings without ensuring that the underlaying logic is correct and thus the warning was inappropriate 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 or in another secure way 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.