Mercurial > mplayer.hg
annotate DOCS/tech/new_policy.txt @ 22386:6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
maybe we should just copy and paste the description from debian and add these into it?
author | michael |
---|---|
date | Thu, 01 Mar 2007 22:58:31 +0000 |
parents | 867f18d80b31 |
children |
rev | line source |
---|---|
22368 | 1 New Policy Draft |
2 Version 20070301 | |
18840 | 3 |
22368 | 4 Intro: |
5 ------ | |
6 This document is an attempt to write a new policy as the old is fairly | |
22373 | 7 confusing and easy to misunderstand, its intention is not really to |
22368 | 8 change the rules but rather to write them down clearer ... |
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 | |
11 significant disagreement with me on some part | |
18841 | 12 |
22368 | 13 Author: |
14 ------- | |
15 Michael Niedermayer | |
16 the authors of the old policy as i liberally copy and pasted from it | |
18706 | 17 |
22368 | 18 TODO: |
22373 | 19 add more explanations, justifications and examples |
22368 | 20 how to become/loose maintainer status |
21 review patches.txt | |
22 security/exploit rules | |
23 ------------------------ | |
18840 | 24 |
18841 | 25 |
22368 | 26 1. Definitions |
27 -------------- | |
22373 | 28 * MPlayer developer, generally referred to simply as developer in this document |
22368 | 29 is any person who has a open (not cracked, not suspended) svn write account |
22382 | 30 * MPlayer leader, generally referred to simply as leader in this document, every |
31 leader is also a developer | |
22373 | 32 * CAN/MUST/SHOULD descriptions ... |
22368 | 33 * public developer mailing list (mplayer-dev-eng at mplayerhq in hungary) |
18840 | 34 |
18841 | 35 |
22368 | 36 C. Code and SVN Rules |
37 ----------------------------- | |
38 Renaming/moving/copying files or contents of files | |
19376 | 39 Do not move, rename or copy files of which you are not the maintainer without |
22368 | 40 discussing it on the public developer mailinglist first! |
19357
59af53f4f436
update the moving & copying rules as disscussed on mplayer-dev + some (but not all as iam lazy) fixes by the wanderer
michael
parents:
19248
diff
changeset
|
41 |
19376 | 42 Never copy or move a file by using 'svn delete' and 'svn add'. Always use |
43 'svn move' or 'svn copy' instead in order to preserve history and minimize | |
44 the size of diffs. | |
19357
59af53f4f436
update the moving & copying rules as disscussed on mplayer-dev + some (but not all as iam lazy) fixes by the wanderer
michael
parents:
19248
diff
changeset
|
45 |
19376 | 46 To split a file, use 'svn copy' and remove the unneeded lines from each file. |
2200 | 47 |
7904
98168d30f67d
Spellchecked, reworded, reformatted, small additions and corrections.
diego
parents:
5415
diff
changeset
|
48 Don't do a lot of cut'n'paste from one file to another without a very good |
98168d30f67d
Spellchecked, reworded, reformatted, small additions and corrections.
diego
parents:
5415
diff
changeset
|
49 reason and discuss it on the mplayer-dev-eng mailing list first. It will make |
18840 | 50 those changes hard to trace. |
5415 | 51 |
7904
98168d30f67d
Spellchecked, reworded, reformatted, small additions and corrections.
diego
parents:
5415
diff
changeset
|
52 Such actions are useless and treated as cosmetics in 99% of cases, |
98168d30f67d
Spellchecked, reworded, reformatted, small additions and corrections.
diego
parents:
5415
diff
changeset
|
53 so try to avoid them. |
11395
5484bc13e90a
Some notes about general CVS documentation added, new 'cvs admin' section
diego
parents:
9537
diff
changeset
|
54 |
22368 | 55 Reverting broken commits |
19382 | 56 There are 2 ways to reverse a change, they differ significantly in what they |
57 do to the svn repository | |
58 The recommit old method: | |
59 svn merge | |
60 svn ci <file> | |
61 This simply changes the file(s) back to their old version localy and then | |
62 the change is commited as if it is a new change | |
63 The svn copy method | |
64 svn rm <file> | |
65 svn ci <file> | |
66 svn cp -r<good revision> svn://svn.mplayerhq.hu/mplayer/trunk/[<path>/]<file> <file> | |
67 svn ci <file> | |
68 This simply removes the file and then copies the last good version with | |
69 its history over it, this method can only be used to revert the n last | |
70 commits but not to revert a bad commit in the middle of its history | |
71 Neither method will change the history, checking out an old version will | |
72 always return exactly that revision with all its bugs and features. The | |
73 difference is that with the svn copy method the broken commit will not be | |
22238 | 74 part of the directly visible history of the revisions after the reversal |
75 So if the change was completely broken like reindenting a file against the | |
76 maintainers decision, or a change which mixed functional and cosmetic | |
22345 | 77 changes then it is better if it is not part of the visible history as it |
19382 | 78 would make it hard to read, review and would also break svn annotate |
79 For the example of a change which mixed functional and cosmetic parts they | |
22238 | 80 should of course be committed again after the reversal but separately, so one |
19382 | 81 change with the functional stuff and one with the cosmetics |
82 OTOH if the change which you want to reverse was simply buggy but not | |
83 totally broken then it should be reversed with svn merge as otherwise | |
84 the fact that the change was bad would be hidden | |
85 One method to decide which reversal method is best is to ask yourself | |
22345 | 86 if there is any value in seeing the whole bad change and its removal |
87 in SVN vs just seeing a comment that says what has been reversed while | |
22238 | 88 the actual change does not clutter the immediately visible history and |
19382 | 89 svn annotate. |
90 If you are even just slightly uncertain how to revert something then ask on | |
22345 | 91 the mplayer-dev-eng mailing list. |
15227
167085fd11af
'cvs admin -o' is dangerous and should be handled with extra care.
diego
parents:
14856
diff
changeset
|
92 |
22368 | 93 Broken code |
94 You must not commit code which breaks MPlayer! (Meaning unfinished but | |
7904
98168d30f67d
Spellchecked, reworded, reformatted, small additions and corrections.
diego
parents:
5415
diff
changeset
|
95 enabled code which breaks compilation or compiles but does not work.) |
13288 | 96 You can commit unfinished stuff (for testing etc), but it must be disabled |
97 (#ifdef etc) by default so it does not interfere with other developers' | |
98 work. | |
2200 | 99 |
22368 | 100 Testing code |
101 You don't have to over-test things. If it works for you, and you think it | |
7904
98168d30f67d
Spellchecked, reworded, reformatted, small additions and corrections.
diego
parents:
5415
diff
changeset
|
102 should work for others, too, then commit. If your code has problems |
98168d30f67d
Spellchecked, reworded, reformatted, small additions and corrections.
diego
parents:
5415
diff
changeset
|
103 (portability, exploits compiler bugs, unusual environment etc) they will be |
98168d30f67d
Spellchecked, reworded, reformatted, small additions and corrections.
diego
parents:
5415
diff
changeset
|
104 reported and eventually fixed. |
2200 | 105 |
22373 | 106 Splitting changes |
22368 | 107 Do not commit unrelated changes together, split them into self-contained |
108 pieces. | |
22373 | 109 if you have any doubt discuss it on the developer mailing list before |
110 committing, also when in doubt more splitting is better then less, changes | |
22368 | 111 which are larger then 10kbyte generally should be split into several |
22373 | 112 incremental changes if possible even if you think they are all related |
22368 | 113 keeping changes well split makes reviewing and understanding them on |
22373 | 114 svn log at the time of commit and later when debugging a bug much easier |
18841 | 115 |
22368 | 116 Compiler Warning fixes |
117 Do not change code to hide warnings without ensuring that the underlaying | |
118 logic is correct and thus the warning was inappropriate | |
18841 | 119 |
17578 | 120 4. Do not change behavior of the program (renaming options etc) or |
17579
f1ce086b5eed
Clarify feature removal policy: it must be approved on the mailing list.
rathann
parents:
17578
diff
changeset
|
121 remove functionality from the code without approval in a discussion on |
f1ce086b5eed
Clarify feature removal policy: it must be approved on the mailing list.
rathann
parents:
17578
diff
changeset
|
122 the mplayer-dev-eng mailing list. |
12024 | 123 |
18841 | 124 |
13288 | 125 5. Do not commit changes to the build system (Makefiles, configure script) |
126 which change behaviour, defaults etc, without asking first. The same | |
127 applies to compiler warning fixes, trivial looking fixes and to code | |
128 maintained by other developers. We usually have a reason for doing things | |
129 the way we do. Send your changes as patches to the mplayer-dev-eng mailing | |
130 list, and if the code maintainers say OK, you may commit. This does not | |
131 apply to files you wrote and/or maintain. | |
132 | |
18841 | 133 |
22368 | 134 Cosmetics |
135 We refuse source indentation and other cosmetic changes if they are mixed | |
136 with functional changes, such commits will be reverted. Every | |
13288 | 137 developer has his own indentation style, you should not change it. Of course |
138 if you (re)write something, you can use your own style... (Many projects | |
139 force a given indentation style - we don't.) If you really need to make | |
140 indentation changes (try to avoid this), separate them strictly from real | |
141 changes. | |
12024 | 142 |
143 NOTE: If you had to put if(){ .. } over a large (> 5 lines) chunk of code, | |
13288 | 144 do NOT change the indentation of the inner part (don't move it to the right)! |
2200 | 145 |
18841 | 146 |
22368 | 147 Commit log message |
148 Always fill out the commit log message. Describe in a few lines what you | |
13288 | 149 changed and why. You can refer to mailing list postings if you fix a |
150 particular bug. Comments such as "fixed!" or "Changed it." are unacceptable. | |
2200 | 151 |
18841 | 152 |
22368 | 153 Applying patches |
154 If you apply a patch by someone else, include the name and email address in | |
18660 | 155 the log message. Since the mplayer-cvslog mailing list is publicly |
13288 | 156 archived you should add some spam protection to the email address. Send an |
157 answer to mplayer-dev-eng (or wherever you got the patch from) saying that | |
17054 | 158 you applied the patch. If the patch contains a documentation change, commit |
159 that as well; do not leave it to the documentation maintainers. | |
2200 | 160 |
18841 | 161 |
22368 | 162 messing with other developers code |
163 Do NOT commit to code actively maintained by others without permission. Send | |
13288 | 164 a patch to mplayer-dev-eng instead. |
12107
bc89ddda34b8
Developers should subscribe to mplayer-cvslog, mention mplayer-docs.
diego
parents:
12099
diff
changeset
|
165 |
18841 | 166 |
22368 | 167 Subscribe to svnlog |
168 Subscribe to the mplayer-cvslog mailing list. The diffs of all commits | |
12107
bc89ddda34b8
Developers should subscribe to mplayer-cvslog, mention mplayer-docs.
diego
parents:
12099
diff
changeset
|
169 are sent there and reviewed by all the other developers. Bugs and possible |
bc89ddda34b8
Developers should subscribe to mplayer-cvslog, mention mplayer-docs.
diego
parents:
12099
diff
changeset
|
170 improvements or general questions regarding commits are discussed there. We |
bc89ddda34b8
Developers should subscribe to mplayer-cvslog, mention mplayer-docs.
diego
parents:
12099
diff
changeset
|
171 expect you to react if problems with your code are uncovered. |
12024 | 172 |
18841 | 173 |
22368 | 174 Documentation |
175 Update the documentation if you change behavior or add features. If you are | |
13288 | 176 unsure how best to do this, send a patch to mplayer-docs, the documentation |
177 maintainers will review and commit your stuff. | |
178 | |
18841 | 179 |
22368 | 180 Controversial changes |
181 Always send a patch to the mplayer-dev-eng mailing list before committing | |
20783
dc1a1ff6c7d9
Updated for controversial changes and irc-only decisions
rtogni
parents:
19662
diff
changeset
|
182 if you suspect that the change is going to be controversial. Based on past |
dc1a1ff6c7d9
Updated for controversial changes and irc-only decisions
rtogni
parents:
19662
diff
changeset
|
183 experience, these changes are likely to be controversial: |
dc1a1ff6c7d9
Updated for controversial changes and irc-only decisions
rtogni
parents:
19662
diff
changeset
|
184 - feature removal, even if obsolete |
dc1a1ff6c7d9
Updated for controversial changes and irc-only decisions
rtogni
parents:
19662
diff
changeset
|
185 - changes to "special" output messages (like the "Core dumped ;)" message) |
dc1a1ff6c7d9
Updated for controversial changes and irc-only decisions
rtogni
parents:
19662
diff
changeset
|
186 - verbosity changes from default (info) level |
dc1a1ff6c7d9
Updated for controversial changes and irc-only decisions
rtogni
parents:
19662
diff
changeset
|
187 - changes to "historical" parts of docs and webpages |
dc1a1ff6c7d9
Updated for controversial changes and irc-only decisions
rtogni
parents:
19662
diff
changeset
|
188 - use of internal or external libraries |
22368 | 189 - changes to the internal architecture |
190 - non trivial changes to very fundamental parts of mplayer | |
20783
dc1a1ff6c7d9
Updated for controversial changes and irc-only decisions
rtogni
parents:
19662
diff
changeset
|
191 |
dc1a1ff6c7d9
Updated for controversial changes and irc-only decisions
rtogni
parents:
19662
diff
changeset
|
192 |
22368 | 193 Public discussions |
194 Try to keep important discussions and requests (also) on the | |
20783
dc1a1ff6c7d9
Updated for controversial changes and irc-only decisions
rtogni
parents:
19662
diff
changeset
|
195 mplayer-dev-eng mailing list, so that all developers can benefit from them. |
dc1a1ff6c7d9
Updated for controversial changes and irc-only decisions
rtogni
parents:
19662
diff
changeset
|
196 IRC is good for quick discussions, but nobody is there 24/7. |
22368 | 197 also subscribe to the public developer mailing list |
20783
dc1a1ff6c7d9
Updated for controversial changes and irc-only decisions
rtogni
parents:
19662
diff
changeset
|
198 |
dc1a1ff6c7d9
Updated for controversial changes and irc-only decisions
rtogni
parents:
19662
diff
changeset
|
199 |
22368 | 200 Patches |
201 read and follow patches.txt when sending patches for mplayer | |
7904
98168d30f67d
Spellchecked, reworded, reformatted, small additions and corrections.
diego
parents:
5415
diff
changeset
|
202 |
3258 | 203 |
22368 | 204 Insults |
205 Do not insult other people in relation to mplayer on any public mailing | |
206 list, that is calling code from someone else a pile of broken shit is | |
207 perfectly fine but calling the developer herself a retarded f*cking moron | |
208 is not acceptable | |
18828 | 209 |
18841 | 210 |
22368 | 211 Forking |
22382 | 212 People disagreeing with the developers or leaders may fork the project, |
213 the leaders MUST in that case provide a svn dump with all history if | |
22368 | 214 the person forking wants one |
18828 | 215 |
18841 | 216 |
22368 | 217 Communicating passwords |
218 Developers who have provided a public gpg key shall only receive | |
219 passwords or other sensitive information related to mplayer encrypted | |
220 with their gpg key | |
18828 | 221 |
18841 | 222 |
22368 | 223 V. Votes |
224 -------- | |
225 Its inevitable that some things will be decided by voting, votes in the past | |
226 have due to total lack of rules been problematic for example as many people | |
227 rather wrote long texts and voted based on some condition instead of saying | |
228 a clear yes or no, still its important that people can vote based on a | |
229 condition | |
22382 | 230 The result of a vote is binding for all developers and leaders, though of |
231 course they can leave the project and thus cease to be a developer or leader | |
22368 | 232 any time |
18828 | 233 |
22368 | 234 Vs. Starting a vote |
235 Any single developer can start a vote, to do so she has to send a mail to the | |
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 | |
238 of the mail | |
239 | |
240 Vp. Proposing an option (point on the ballot, better term?) | |
22373 | 241 Any single developer can propose an option up to 7 days after a vote has |
22368 | 242 been started, to do so she has to reply to the original vote mail on the |
22373 | 243 public developer mailing list and clearly, concise and unmistakably describe |
22368 | 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 | |
246 of doing nothing | |
247 options can be conditional on anything which at the end of the vote can | |
22373 | 248 be clearly and unmistakably be answered with true or false |
18828 | 249 |
22368 | 250 Vv. Voting |
22373 | 251 Any developer can cast a vote up to 10 days days after a vote has been |
22368 | 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 | |
254 unrated options shall be counted equal to the default option | |
22382 | 255 Any leader can cast a veto against any option except the default up to 10 days |
22368 | 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 | |
258 [VOTE] by [VOTE-VETO] | |
22382 | 259 Developers and leaders who use gpg/pgp MUST sign their votes and vetoes |
18828 | 260 |
22368 | 261 Vc. Counting votes |
22373 | 262 The person starting the vote has to count the votes and vetoes and publish |
22368 | 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 | |
22386
6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
michael
parents:
22385
diff
changeset
|
265 Vcv. Counting vetoes |
6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
michael
parents:
22385
diff
changeset
|
266 if the majority of leaders that is yes >= no && yes>0 cast a veto against an |
6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
michael
parents:
22385
diff
changeset
|
267 option then it has a required supermajority of 2:1 otherwise it has a |
6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
michael
parents:
22385
diff
changeset
|
268 required supermajority of 0:1 and in either case no quorum requirement |
22368 | 269 Vcc. the votes shall be counted by using the Condorcet/Clone Proof SSD |
22385
867f18d80b31
url with a good description of how to determine the winner from the votes
michael
parents:
22382
diff
changeset
|
270 Voting Method described in http://www.debian.org/devel/constitution A.6 |
22368 | 271 |
22386
6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
michael
parents:
22385
diff
changeset
|
272 Reasoning behind avoiding of a quorum and majority requirement except in |
6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
michael
parents:
22385
diff
changeset
|
273 the case of vetoes |
6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
michael
parents:
22385
diff
changeset
|
274 short awnser its stupid and has catastrophical failure modes |
6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
michael
parents:
22385
diff
changeset
|
275 example of one such failure mode, lets assume a 1:1 majority requirement |
6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
michael
parents:
22385
diff
changeset
|
276 as debian uses by default, there are 101 developers who vote, there are |
6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
michael
parents:
22385
diff
changeset
|
277 3 options A,B and D the default (doing nothing / further discussions) |
6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
michael
parents:
22385
diff
changeset
|
278 50 developers prefer A over B and B over discussions (A>B>D) |
6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
michael
parents:
22385
diff
changeset
|
279 50 developers prefer discussions over A and A over B (D>A>B) |
6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
michael
parents:
22385
diff
changeset
|
280 1 developer prefers B over discussions and discussions over A (B>D>A) |
6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
michael
parents:
22385
diff
changeset
|
281 in this case A is approved by 50 of 101 developers and is droped due to |
6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
michael
parents:
22385
diff
changeset
|
282 the lack of majority, B is approved by 51 of 101 developers and is not |
6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
michael
parents:
22385
diff
changeset
|
283 furthermore B wins even though 100 of 101 developers prefer A over B |
6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
michael
parents:
22385
diff
changeset
|
284 |
6c9a391ca7cb
clarify quorum and majority requirements in respect to debians voting system
michael
parents:
22385
diff
changeset
|
285 |
22382 | 286 S. Changes to developer and Leader status |
22368 | 287 ---------------------------------------- |
22382 | 288 The majority of leaders, that is yes>no can give and take away |
289 developer and leader status to people | |
290 furthermore any developer or leader can step back and thus loose | |
291 his leader and or developer status | |
292 People disagreeing with the leaders are free to fork the project | |
22368 | 293 new developers should be asked for real name, public gpg key, phone |
294 number and email addresses, none of this is mandatory though, it is asked | |
295 so as to be able to contact the developer if the need arises and one | |
296 contact method fails | |
18828 | 297 |
18841 | 298 |
22368 | 299 O. Violations |
300 ------------- | |
22382 | 301 Any leader can after at least one leader has warned another developer |
22373 | 302 due to breaking policy, suspend his account if he repeats the violation |
22368 | 303 Ow. A policy violation warning MUST be CCed to the developer who violated |
304 the policy | |
18828 | 305 |
18841 | 306 |
22368 | 307 We think our rules are not too hard. If you have comments, contact us. |