Mercurial > mplayer.hg
comparison DOCS/tech/new_policy_proposal.txt @ 22387:b42d79ee1af8
rename to *_proposal.txt
author | michael |
---|---|
date | Thu, 01 Mar 2007 23:09:58 +0000 |
parents | DOCS/tech/new_policy.txt@6c9a391ca7cb |
children | fefb92f3c59a |
comparison
equal
deleted
inserted
replaced
22386:6c9a391ca7cb | 22387:b42d79ee1af8 |
---|---|
1 New Policy Draft | |
2 Version 20070301 | |
3 | |
4 Intro: | |
5 ------ | |
6 This document is an attempt to write a new policy as the old is fairly | |
7 confusing and easy to misunderstand, its intention is not really to | |
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 | |
12 | |
13 Author: | |
14 ------- | |
15 Michael Niedermayer | |
16 the authors of the old policy as i liberally copy and pasted from it | |
17 | |
18 TODO: | |
19 add more explanations, justifications and examples | |
20 how to become/loose maintainer status | |
21 review patches.txt | |
22 security/exploit rules | |
23 ------------------------ | |
24 | |
25 | |
26 1. Definitions | |
27 -------------- | |
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 | |
30 * MPlayer leader, generally referred to simply as leader in this document, every | |
31 leader is also a developer | |
32 * CAN/MUST/SHOULD descriptions ... | |
33 * public developer mailing list (mplayer-dev-eng at mplayerhq in hungary) | |
34 | |
35 | |
36 C. Code and SVN Rules | |
37 ----------------------------- | |
38 Renaming/moving/copying files or contents of files | |
39 Do not move, rename or copy files of which you are not the maintainer without | |
40 discussing it on the public developer mailinglist first! | |
41 | |
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. | |
45 | |
46 To split a file, use 'svn copy' and remove the unneeded lines from each file. | |
47 | |
48 Don't do a lot of cut'n'paste from one file to another without a very good | |
49 reason and discuss it on the mplayer-dev-eng mailing list first. It will make | |
50 those changes hard to trace. | |
51 | |
52 Such actions are useless and treated as cosmetics in 99% of cases, | |
53 so try to avoid them. | |
54 | |
55 Reverting broken commits | |
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 | |
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 | |
77 changes then it is better if it is not part of the visible history as it | |
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 | |
80 should of course be committed again after the reversal but separately, so one | |
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 | |
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 | |
88 the actual change does not clutter the immediately visible history and | |
89 svn annotate. | |
90 If you are even just slightly uncertain how to revert something then ask on | |
91 the mplayer-dev-eng mailing list. | |
92 | |
93 Broken code | |
94 You must not commit code which breaks MPlayer! (Meaning unfinished but | |
95 enabled code which breaks compilation or compiles but does not work.) | |
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. | |
99 | |
100 Testing code | |
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 | |
103 (portability, exploits compiler bugs, unusual environment etc) they will be | |
104 reported and eventually fixed. | |
105 | |
106 Splitting changes | |
107 Do not commit unrelated changes together, split them into self-contained | |
108 pieces. | |
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 | |
111 which are larger then 10kbyte generally should be split into several | |
112 incremental changes if possible even if you think they are all related | |
113 keeping changes well split makes reviewing and understanding them on | |
114 svn log at the time of commit and later when debugging a bug much easier | |
115 | |
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 | |
119 | |
120 4. Do not change behavior of the program (renaming options etc) or | |
121 remove functionality from the code without approval in a discussion on | |
122 the mplayer-dev-eng mailing list. | |
123 | |
124 | |
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 | |
133 | |
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 | |
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. | |
142 | |
143 NOTE: If you had to put if(){ .. } over a large (> 5 lines) chunk of code, | |
144 do NOT change the indentation of the inner part (don't move it to the right)! | |
145 | |
146 | |
147 Commit log message | |
148 Always fill out the commit log message. Describe in a few lines what you | |
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. | |
151 | |
152 | |
153 Applying patches | |
154 If you apply a patch by someone else, include the name and email address in | |
155 the log message. Since the mplayer-cvslog mailing list is publicly | |
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 | |
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. | |
160 | |
161 | |
162 messing with other developers code | |
163 Do NOT commit to code actively maintained by others without permission. Send | |
164 a patch to mplayer-dev-eng instead. | |
165 | |
166 | |
167 Subscribe to svnlog | |
168 Subscribe to the mplayer-cvslog mailing list. The diffs of all commits | |
169 are sent there and reviewed by all the other developers. Bugs and possible | |
170 improvements or general questions regarding commits are discussed there. We | |
171 expect you to react if problems with your code are uncovered. | |
172 | |
173 | |
174 Documentation | |
175 Update the documentation if you change behavior or add features. If you are | |
176 unsure how best to do this, send a patch to mplayer-docs, the documentation | |
177 maintainers will review and commit your stuff. | |
178 | |
179 | |
180 Controversial changes | |
181 Always send a patch to the mplayer-dev-eng mailing list before committing | |
182 if you suspect that the change is going to be controversial. Based on past | |
183 experience, these changes are likely to be controversial: | |
184 - feature removal, even if obsolete | |
185 - changes to "special" output messages (like the "Core dumped ;)" message) | |
186 - verbosity changes from default (info) level | |
187 - changes to "historical" parts of docs and webpages | |
188 - use of internal or external libraries | |
189 - changes to the internal architecture | |
190 - non trivial changes to very fundamental parts of mplayer | |
191 | |
192 | |
193 Public discussions | |
194 Try to keep important discussions and requests (also) on the | |
195 mplayer-dev-eng mailing list, so that all developers can benefit from them. | |
196 IRC is good for quick discussions, but nobody is there 24/7. | |
197 also subscribe to the public developer mailing list | |
198 | |
199 | |
200 Patches | |
201 read and follow patches.txt when sending patches for mplayer | |
202 | |
203 | |
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 | |
209 | |
210 | |
211 Forking | |
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 | |
214 the person forking wants one | |
215 | |
216 | |
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 | |
221 | |
222 | |
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 | |
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 | |
232 any time | |
233 | |
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?) | |
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 | |
243 public developer mailing list and clearly, concise and unmistakably describe | |
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 | |
248 be clearly and unmistakably be answered with true or false | |
249 | |
250 Vv. Voting | |
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 | |
253 public developer mailing list and rate options each with an integer | |
254 unrated options shall be counted equal to the default option | |
255 Any leader 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 | |
257 vote mail on the public developer mailing list and replace | |
258 [VOTE] by [VOTE-VETO] | |
259 Developers and leaders who use gpg/pgp MUST sign their votes and vetoes | |
260 | |
261 Vc. Counting votes | |
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 | |
264 with [VOTE-RESULTS] instead of [VOTE] in the subject | |
265 Vcv. Counting vetoes | |
266 if the majority of leaders that is yes >= no && yes>0 cast a veto against an | |
267 option then it has a required supermajority of 2:1 otherwise it has a | |
268 required supermajority of 0:1 and in either case no quorum requirement | |
269 Vcc. the votes shall be counted by using the Condorcet/Clone Proof SSD | |
270 Voting Method described in http://www.debian.org/devel/constitution A.6 | |
271 | |
272 Reasoning behind avoiding of a quorum and majority requirement except in | |
273 the case of vetoes | |
274 short awnser its stupid and has catastrophical failure modes | |
275 example of one such failure mode, lets assume a 1:1 majority requirement | |
276 as debian uses by default, there are 101 developers who vote, there are | |
277 3 options A,B and D the default (doing nothing / further discussions) | |
278 50 developers prefer A over B and B over discussions (A>B>D) | |
279 50 developers prefer discussions over A and A over B (D>A>B) | |
280 1 developer prefers B over discussions and discussions over A (B>D>A) | |
281 in this case A is approved by 50 of 101 developers and is droped due to | |
282 the lack of majority, B is approved by 51 of 101 developers and is not | |
283 furthermore B wins even though 100 of 101 developers prefer A over B | |
284 | |
285 | |
286 S. Changes to developer and Leader status | |
287 ---------------------------------------- | |
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 | |
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 | |
297 | |
298 | |
299 O. Violations | |
300 ------------- | |
301 Any leader can after at least one leader has warned another developer | |
302 due to breaking policy, suspend his account if he repeats the violation | |
303 Ow. A policy violation warning MUST be CCed to the developer who violated | |
304 the policy | |
305 | |
306 | |
307 We think our rules are not too hard. If you have comments, contact us. |