[Bf-committers] Blender developers meeting notes - August 2, 2015

[Campbell Barton]

> - 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 [0],
optimizing allocations for slop-space [1, 2], merge-sort for
linked-lists [3], 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.

[0]: https://developer.blender.org/rBcfdd27381c6730dc0d8d4bb51c132b29337b8af5
[1]: https://developer.blender.org/rBe220d3228f48d4cb3256b398b45b40bf6892e550
[2]: https://developer.blender.org/rB19b7bb5975afdc2340538cb48d85e445828e9d7f
[3]: https://developer.blender.org/rB867cd2048e0e8dd9f0552ac996bb1d352136b9a0
[4]: https://developer.blender.org/rB65a95926600027814ef01ce5beaf711d3f41be55
[5]: https://developer.blender.org/rB38eef8deee4261f0139d29eb81584131a862bf59