On Sat, Jun 29, 2013 at 7:41 AM, Ton Roosendaal <[email protected]> wrote:
> > 1) Include opt-in usage and automatic crash reporting in *every* blender > > build, and a web dashboard to live usage/crash stats to devs and the > > community. > > I always wondered what other projects/companies do with such reports. Is > there a public example where I can see the handling of such report logging, > with evidence for how this is being used well, the benefits? Or is it just > for statistics? > I'm not aware of anyone who publishes information about how much their own software crashes, this would probably be very hard to manage PR on. I will say that at the large well known companies I've worked for, we tracked and graphed usage, error, and performance stats for nearly-all server-side and most client side software (opt-in on the client side). When the graphs all look "good" they are not used much, but when odd things start happening, the graphs are often the only way to know something is going wrong. It also helps avoid bad priorities, because the data is more statistically relevant than "one person telling you XYZ" when there are thousands or millions of users. As for the detailed crash dumps, and stack backtraces.. The utility of these is very related to how much correlation there is between the stack and the actual bug. Parasitic memory-stomp bugs can't be found with these reports. However, many other types of bugs become quite obvious by correlating the stacks and looking at a few user-written descriptions. I have more personal experience with this for server-side than client-side, but then I have been more involved with server-side than client-side development. The real kicker is, IMO, usage, crash, and performance reporting has more value for the application than ANY other similar amount of feature work -- because it tracks activity of all code. Reliability and Performance are two of software's most important features, so it is very useful to pay attention to them. Solutions for having tracking/compositing/sequencer work together are there > too. What I'd like to explore is some kindof image-depsgraph. A user then > can manage image dependencies in Blender like: render to image, which gets > used as a texture in other render, which goes to compositor, which goes > into a VSE, etc etc. > That's an excellent vision. It feels very much like "blender as an art build pipeline". AFAIK, big shops setup that kind of stuff with builds and scripts. Doing it inside blender could have a bunch of great advantages (a) interactivity, (b) easier sharing, (c) more accessible to artists who are not programmers... among others.. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
