利用者:Oneliner

Rules for all Committers

You've been added as bf-blender project member with svn write access, welcome! You can use this access now to work on Blender as member of the Physics & Game Engine team. You're also welcome to work on other features or fixes as discussed with the team online. Please always verify before committing with the module owners in wiki, or with one of the bf-blender admins: Martin Poirier, Campbell Barton, Brecht van Lommel, Matt Ebb or with me. You can also consult the bf-committers email list or with me in IRC if in doubt.

Here's the standard checklist & guidelines I send to new devs:

- The main rules for committing are:

1. Always ensure that what you commit is either on your "own code", or you've verified the patch with the owner of the module. If you want to change things in other parts of the code, check with one of the developers who owns/maintains that.
   
   
2. Always do a 'svn update' and 'svn status' before committing. Check carefully if the files marked "Modified" are actually what you want to commit. Do a 'svn diff' on files if in doubt.
   
   
3. Always contribute code in the style as used in the code you've worked on. We just have a long history of software development, and can't restyle all code to a unified standard. Keeping style per file consistant at least keeps things readable.
   Make sure you use real TABs, and unix LFs (end of lines).
   For new code, check on the style guidelines on blender.org.
   
   
4. Blender is strictly cross-platform, and we only accept code that compiles for all current platforms correctly. for OpenGL (nothing newer than 1.4, or correctly wrapped), Python (3.2), gcc (4.2 should work), msvc (2008 should work), etc. If in doubt, send a patch to the bf-committers list.
   
   
5. If you add new C files, check if those get included in SConstruct and CMakefiles, if you think your commit may cause errors on others configurations, note this in your commit log, or better: notify the bf-committers mailing list or go to the irc.freenode.net #blendercoders channel.
   
   
6. Subscribe to both mailing lists below:
   http://lists.blender.org/mailman/listinfo/bf-committers/
   http://lists.blender.org/mailman/listinfo/bf-blender-cvs/
   

Thanks! :)

-Ton-

Best Practice

Etiquette

• When making very large changes to blenders source, be available some time after (1-3 hrs), in case this breaks blender in some way.
• Don't make large changes before release
  See: http://wiki.blender.org/index.php/Dev:Doc/Process/Release_Cycle
• Developers may reply to your commit logs, even if you don't read every message on the bf-committers mailing list, at least be sure to reply comments on your commit.
• When committing contributions from others, include their name in the log and the patch number from the tracker where applicable.

Code Style

C/C++

We currently don't have a style guide, so if you work with existing code, just use the style in that file.

We did work on a style guide but its still awaiting approval.

http://wiki.blender.org/index.php/User:Nazg-gul/WritingGoodCode

Python

For python we follow pep8 where possible.

See: http://www.blender.org/documentation/blender_python_api_2_61_4/info_best_practice.html#style-conventions

Commit (Best Practice)

• Don't combine code cleanup/refactoring commits with functional changes, since it makes it harder to investigate when a commit causes new bugs.
• Don't mix in your own changes when syncing branch merges, mistake sometimes made when merging trunk back into a branch.
• Store test files in: https://svn.blender.org/svnroot/bf-blender/trunk/lib/tests/

Commit (Subversion Usage)

• Be sure to use svn cp or svn mv (copy / move) when moving files so history isn't lost.

Commit Logs

Bug fixes:

• Don't copy the bug report name verbatim if it's not descriptive, explain what exactly the problem was.
• Explain what you fixed on a user level, not just what was wrong in the code. Do explain those things too, but please do both then.
• Start the commit log with "Fix #12345: ", so it's immediately clear that it's a bugfix.

Features:

• Explain what the feature does on a user level, not just the code changes.
• Keep user level explanation and code changes explanation separate.
• Explain features in terms of their names in the user interface, not internal code terminology.
• If it's not obvious, explain what the feature is useful for or when it should be used.

Code refactoring:

• Make it clear when there are no functional changes, I like to start the commit with "Code cleanup: " then.