[Bf-committers] Blender roadmap article on code blog

[David Jeske]

On Sat, Jun 29, 2013 at 7:41 AM, Ton Roosendaal <ton at blender.org> 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..