summaryrefslogtreecommitdiffstats
path: root/DOCS
diff options
context:
space:
mode:
authormichael <michael@b3059339-0415-0410-9bf9-f77b7e298cf2>2007-03-15 12:45:04 +0000
committermichael <michael@b3059339-0415-0410-9bf9-f77b7e298cf2>2007-03-15 12:45:04 +0000
commit884ae3473e629cb05ec6f9e7bce684772bcc0458 (patch)
tree1bdb5b5c76ce3b523b34ca5737735561211c7984 /DOCS
parentd3b46a6461ccae817bd0e7ca7fb1f641b875e184 (diff)
downloadmpv-884ae3473e629cb05ec6f9e7bce684772bcc0458.tar.bz2
mpv-884ae3473e629cb05ec6f9e7bce684772bcc0458.tar.xz
update spliting rule to what i just added to ffmpeg
comments welcome git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@22609 b3059339-0415-0410-9bf9-f77b7e298cf2
Diffstat (limited to 'DOCS')
-rw-r--r--DOCS/tech/new_policy_proposal.txt14
1 files changed, 7 insertions, 7 deletions
diff --git a/DOCS/tech/new_policy_proposal.txt b/DOCS/tech/new_policy_proposal.txt
index e2eb887045..fc67bffe94 100644
--- a/DOCS/tech/new_policy_proposal.txt
+++ b/DOCS/tech/new_policy_proposal.txt
@@ -105,13 +105,13 @@ Testing code
Splitting changes
Do not commit unrelated changes together, split them into self-contained
- pieces.
- if you have any doubt discuss it on the developer mailing list before
- committing, also when in doubt more splitting is better then less, changes
- which are larger then 10kbyte generally should be split into several
- incremental changes if possible even if you think they are all related
- keeping changes well split makes reviewing and understanding them on
- svn log at the time of commit and later when debugging a bug much easier
+ pieces. Also dont forget that if part B depends on part A but A doesnt
+ depend on B, then A can and should be commited first and seperately from B.
+ Keeping changes well split into self contained parts makes reviewing and
+ understanding them on svn log at the time of commit and later when
+ debugging a bug much easier.
+ Also if you have doubt about spliting or not spliting, dont hesitate to
+ ask/disscuss it on the developer mailing list.
4. Do not change behavior of the program (renaming options etc) or
remove functionality from the code without approval in a discussion on