[Bf-committers] Commit logs

Dalai Felinto dfelinto at gmail.com
Wed Feb 1 19:24:21 CET 2012


If I may add:

* store test files in
https://svn.blender.org/svnroot/bf-blender/trunk/lib/tests/
* images are will need to be hosted on wiki at time of commit, so make sure
they are stored in a place that will be up until then
(paste all.org seems ok, but if you leave images in dropbox make sure you
don't delete them).

I'm saying that because I myself am guilty of this. I just put a test file
from dropbox to svn test folder and moved the image from pasteall to the
release log wiki.

--
Dalai
www.dalaifelinto.com

2012/2/1 Brecht Van Lommel <brechtvanlommel at pandora.be>

> Hi all,
>
> In going over the commit logs for the release notes, I found many are quite
> cryptic, or could be improved so that it's easier to make release notes
> from them. I don't want to make strict guidelines for how things should be
> formatted, just some general hints:
>
> 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.
>
> Thanks,
> Brecht.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list