> - 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 _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
