diff options
author | michael <michael@b3059339-0415-0410-9bf9-f77b7e298cf2> | 2007-03-15 12:45:04 +0000 |
---|---|---|
committer | michael <michael@b3059339-0415-0410-9bf9-f77b7e298cf2> | 2007-03-15 12:45:04 +0000 |
commit | 884ae3473e629cb05ec6f9e7bce684772bcc0458 (patch) | |
tree | 1bdb5b5c76ce3b523b34ca5737735561211c7984 /DOCS/tech/new_policy_proposal.txt | |
parent | d3b46a6461ccae817bd0e7ca7fb1f641b875e184 (diff) | |
download | mpv-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/tech/new_policy_proposal.txt')
-rw-r--r-- | DOCS/tech/new_policy_proposal.txt | 14 |
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 |