Mercurial > mplayer.hg
comparison DOCS/tech/new_policy.txt @ 22373:525091b9b972
spelling fixes by ivan
| author | michael |
|---|---|
| date | Thu, 01 Mar 2007 12:16:34 +0000 |
| parents | 8e9f3809b4be |
| children | 592e6aa9585b |
comparison
equal
deleted
inserted
replaced
| 22372:915194317cb7 | 22373:525091b9b972 |
|---|---|
| 2 Version 20070301 | 2 Version 20070301 |
| 3 | 3 |
| 4 Intro: | 4 Intro: |
| 5 ------ | 5 ------ |
| 6 This document is an attempt to write a new policy as the old is fairly | 6 This document is an attempt to write a new policy as the old is fairly |
| 7 confusing and easy to missunderstand, its intention is not really to | 7 confusing and easy to misunderstand, its intention is not really to |
| 8 change the rules but rather to write them down clearer ... | 8 change the rules but rather to write them down clearer ... |
| 9 also for simplicity and to prevent flamewars, i would suggest that you | 9 also for simplicity and to prevent flamewars, i would suggest that you |
| 10 fork this document and propose that fork as alternative if you have a | 10 fork this document and propose that fork as alternative if you have a |
| 11 significant disagreement with me on some part | 11 significant disagreement with me on some part |
| 12 | 12 |
| 14 ------- | 14 ------- |
| 15 Michael Niedermayer | 15 Michael Niedermayer |
| 16 the authors of the old policy as i liberally copy and pasted from it | 16 the authors of the old policy as i liberally copy and pasted from it |
| 17 | 17 |
| 18 TODO: | 18 TODO: |
| 19 add more explanations, justificaions and examples | 19 add more explanations, justifications and examples |
| 20 how to become/loose maintainer status | 20 how to become/loose maintainer status |
| 21 review patches.txt | 21 review patches.txt |
| 22 security/exploit rules | 22 security/exploit rules |
| 23 ------------------------ | 23 ------------------------ |
| 24 | 24 |
| 25 | 25 |
| 26 1. Definitions | 26 1. Definitions |
| 27 -------------- | 27 -------------- |
| 28 * MPlayer developer, generally refered to simply as developer in this document | 28 * MPlayer developer, generally referred to simply as developer in this document |
| 29 is any person who has a open (not cracked, not suspended) svn write account | 29 is any person who has a open (not cracked, not suspended) svn write account |
| 30 * MPlayer admin, generally refered to simply as admin in this document, every | 30 * MPlayer admin, generally referred to simply as admin in this document, every |
| 31 admin is also a developer | 31 admin is also a developer |
| 32 * CAN/MUST/SHOULD desriptions ... | 32 * CAN/MUST/SHOULD descriptions ... |
| 33 * public developer mailing list (mplayer-dev-eng at mplayerhq in hungary) | 33 * public developer mailing list (mplayer-dev-eng at mplayerhq in hungary) |
| 34 | 34 |
| 35 | 35 |
| 36 C. Code and SVN Rules | 36 C. Code and SVN Rules |
| 37 ----------------------------- | 37 ----------------------------- |
| 101 You don't have to over-test things. If it works for you, and you think it | 101 You don't have to over-test things. If it works for you, and you think it |
| 102 should work for others, too, then commit. If your code has problems | 102 should work for others, too, then commit. If your code has problems |
| 103 (portability, exploits compiler bugs, unusual environment etc) they will be | 103 (portability, exploits compiler bugs, unusual environment etc) they will be |
| 104 reported and eventually fixed. | 104 reported and eventually fixed. |
| 105 | 105 |
| 106 Spliting changes | 106 Splitting changes |
| 107 Do not commit unrelated changes together, split them into self-contained | 107 Do not commit unrelated changes together, split them into self-contained |
| 108 pieces. | 108 pieces. |
| 109 if you have any doubt disscuss it on the developer mailing list before | 109 if you have any doubt discuss it on the developer mailing list before |
| 110 commiting, also when in doubt more spliting is better then less, changes | 110 committing, also when in doubt more splitting is better then less, changes |
| 111 which are larger then 10kbyte generally should be split into several | 111 which are larger then 10kbyte generally should be split into several |
| 112 incremental chanegs if possible even if you think they are all related | 112 incremental changes if possible even if you think they are all related |
| 113 keeping changes well split makes reviewing and understanding them on | 113 keeping changes well split makes reviewing and understanding them on |
| 114 svn log at the time of commit and later when debuging a bug much easier | 114 svn log at the time of commit and later when debugging a bug much easier |
| 115 | 115 |
| 116 Compiler Warning fixes | 116 Compiler Warning fixes |
| 117 Do not change code to hide warnings without ensuring that the underlaying | 117 Do not change code to hide warnings without ensuring that the underlaying |
| 118 logic is correct and thus the warning was inappropriate | 118 logic is correct and thus the warning was inappropriate |
| 119 | 119 |
| 236 public developer mailing list of the project with a subject containing [VOTE] | 236 public developer mailing list of the project with a subject containing [VOTE] |
| 237 and a clear and concise description, a longer descrition can be in the body | 237 and a clear and concise description, a longer descrition can be in the body |
| 238 of the mail | 238 of the mail |
| 239 | 239 |
| 240 Vp. Proposing an option (point on the ballot, better term?) | 240 Vp. Proposing an option (point on the ballot, better term?) |
| 241 Any single developer can propose an option upto 7 days after a vote has | 241 Any single developer can propose an option up to 7 days after a vote has |
| 242 been started, to do so she has to reply to the original vote mail on the | 242 been started, to do so she has to reply to the original vote mail on the |
| 243 public developer mailing list and clearly, concise and unmistakably desribe | 243 public developer mailing list and clearly, concise and unmistakably describe |
| 244 the option and place [VOTE-OPTION] instead of [VOTE] in the subject | 244 the option and place [VOTE-OPTION] instead of [VOTE] in the subject |
| 245 in addition to proposed options, there always exists the default option | 245 in addition to proposed options, there always exists the default option |
| 246 of doing nothing | 246 of doing nothing |
| 247 options can be conditional on anything which at the end of the vote can | 247 options can be conditional on anything which at the end of the vote can |
| 248 be clearly and unmistakably be awnsered with true or false | 248 be clearly and unmistakably be answered with true or false |
| 249 | 249 |
| 250 Vv. Voting | 250 Vv. Voting |
| 251 Any developer can cast a vote upto 10 days days after a vote has been | 251 Any developer can cast a vote up to 10 days days after a vote has been |
| 252 started, to do so she has to reply to the original vote mail on the | 252 started, to do so she has to reply to the original vote mail on the |
| 253 public developer mailing list and rate options each with an integer | 253 public developer mailing list and rate options each with an integer |
| 254 unrated options shall be counted equal to the default option | 254 unrated options shall be counted equal to the default option |
| 255 Any admin can cast a veto against any option except the default upto 10 days | 255 Any admin can cast a veto against any option except the default up to 10 days |
| 256 days after a vote has been started, to do so she has to reply to the original | 256 days after a vote has been started, to do so she has to reply to the original |
| 257 vote mail on the public developer mailing list and replace | 257 vote mail on the public developer mailing list and replace |
| 258 [VOTE] by [VOTE-VETO] | 258 [VOTE] by [VOTE-VETO] |
| 259 Developers and admins who use gpg/pgp MUST sign their votes and vetos | 259 Developers and admins who use gpg/pgp MUST sign their votes and vetoes |
| 260 | 260 |
| 261 Vc. Counting votes | 261 Vc. Counting votes |
| 262 The person starting the vote has to count the votes and vetos and publish | 262 The person starting the vote has to count the votes and vetoes and publish |
| 263 the result on the public developer mailing list as reply to the original vote | 263 the result on the public developer mailing list as reply to the original vote |
| 264 with [VOTE-RESULTS] instead of [VOTE] in the subject | 264 with [VOTE-RESULTS] instead of [VOTE] in the subject |
| 265 Vcv. Counting vetos, an option shall be removed if the majority of admins | 265 Vcv. Counting vetoes, an option shall be removed if the majority of admins |
| 266 that is yes >= no && yes>0 cast a veto against it | 266 that is yes >= no && yes>0 cast a veto against it |
| 267 Vcc. the votes shall be counted by using the Condorcet/Clone Proof SSD | 267 Vcc. the votes shall be counted by using the Condorcet/Clone Proof SSD |
| 268 Voting Method | 268 Voting Method |
| 269 | 269 |
| 270 S. Changes to developer and Admin status | 270 S. Changes to developer and Admin status |
| 281 | 281 |
| 282 | 282 |
| 283 O. Violations | 283 O. Violations |
| 284 ------------- | 284 ------------- |
| 285 Any admin can after at least one admin has warned another developer | 285 Any admin can after at least one admin has warned another developer |
| 286 due to breaking policy, suspend his acount if he repeats the violation | 286 due to breaking policy, suspend his account if he repeats the violation |
| 287 Ow. A policy violation warning MUST be CCed to the developer who violated | 287 Ow. A policy violation warning MUST be CCed to the developer who violated |
| 288 the policy | 288 the policy |
| 289 | 289 |
| 290 | 290 |
| 291 We think our rules are not too hard. If you have comments, contact us. | 291 We think our rules are not too hard. If you have comments, contact us. |