[Bf-committers] Commit logs

Campbell Barton ideasman42 at gmail.com
Wed Feb 1 22:56:59 CET 2012


Looks good,

I'd like to be able to link new developers to a page with this kind of
info, since we are adding devs more quickly now they are not always
familier with how we're (supposed to) work.

IIRC we even agreed to some commit log format years ago but nobody
really followed it.

Heres a wiki which page I just created and included your suggestions.

wiki.blender.org/index.php/Dev:Doc/New_Committer_Info

linked to from...
http://wiki.blender.org/index.php/Dev:Contents

We have a page like for for extension authors already.
http://wiki.blender.org/index.php/Dev:Py/Sharing#Rules_for_SVN_Committers

On Thu, Feb 2, 2012 at 5:24 AM, Dalai Felinto <dfelinto at gmail.com> wrote:
> 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
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell


More information about the Bf-committers mailing list