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