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. |