[Bf-committers] Blender developers meeting notes - August 2, 2015
ideasman42 at gmail.com
Mon Aug 3 06:59:51 CEST 2015
> - Reminder: anyone who wants to add something that affects users or other developers (APIs):
> always make a nice doc! *Before the commit* Even when you think it's not interesting (like optimizing).
> Blender work is interesting to share by default! :)
I don't want to quibble here but this statement makes it sound as if
it should be obvious when to document development,
to me this is way too vague/fuzzy.
Optimization and general improvements happen fairly often,
applying some common sense I assume the statement above means
optimizations which users are likely to notice. Not the "~3% speedup
on a good day" variety :)
Even then, we've had improvements to low level code: hashing ,
optimizing allocations for slop-space [1, 2], merge-sort for
linked-lists , misc BMesh improvements [4, 5]
(not a comprehensive list, just to pick some from memory).
Which ones of these would should be documented *before* committing, and where?
Significant speedups are worth mentioning in the release log, but further,
I'd prefer good high level explanations/comments in the code, and
detailed commit-log if its needed.
Instead of docs on the Wiki or developers own blogs which tend to get outdated.
More information about the Bf-committers