On Tue, Nov 03, 2015 at 08:04:03PM +0100, matmenu wrote: > 2) Do you have a proof for this claim? I mean, modifier/operator > combinations already lead to bugs, I don't see why having them as > plugins/modules would make those problems arise more often?
I don't understand your reasoning. To me it reads like "we get bugs now, so why would we get more when we complicate the software?" In the current situation there is a fixed set of functionality in C++ (ignoring precompiler directives). In the case of a plugin structure, not only do we have the same set of functionality, but also situations where that functionality is only partially loaded. More different possible situations -> more complex -> more bugs. > 3) That's true, but then the user decide to install this module, so > he will report the bug to the original dev This is only true if the bug is trivial to to identify by end-users. Plenty of bugs won't be. Think about double-free bugs, where the first free is performed in the plugin. A crash may happen when Blender itself frees the pointer, and thus any traceback (if that's shown at all) will indicate a problem in Blender, not the plugin. > 4) Also true, but we now have a buildbot that can make builds on > demand for all supported OS. It could be used further by > module/plugin devs and avoid having to ship a compiler with Blender. AFAIK FreeBSD is not built by this system. Furthermore, allowing arbitrary third party code to be run on a BI/BF-hosted machine is an invitation for trouble. This already happens, but through the Git repository, so at least it's only done by people that have been vetted by receiving commit access. -- Sybren A. Stüvel http://stuvelfoto.nl/ http://stuvel.eu/
signature.asc
Description: Digital signature
_______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
