Am 24.06.2012 01:59, schrieb Campbell Barton: > On Sun, Jun 24, 2012 at 1:29 AM, Matt Ebb<[email protected]> wrote: >> On Fri, Jun 22, 2012 at 12:05 AM, Ton Roosendaal<[email protected]> wrote: >>> with the evident benefits but also with as danger that it can go out of >>> control with a huge pile of postponed todo items and issues. :) >>> >>> http://en.wikipedia.org/wiki/Technical_debt >> This is an issue for blender, and has been for a while. It may not be >> as exciting to rally volunteer developers around, but I think >> post-2.6, a period of 'paying off these debts' would be very good for >> blender users, especially those using it in production. >> >> I think that this isn't just related to short release cycles though, a >> lot of it's also due to the open movie projects ('Business pressures' >> in that list, I suppose). They certainly have their benefits, but they >> also leave a lot of unfinished work in their wake. >> >> One of the original ideas for the open movies was to use a practical >> animation project to 'get blender ready for production', however in >> the heat of the project, under deadlines and resource pressures, this >> becomes more like 'fit in the minimum required to allow this >> particular production to get done'. >> >> Using blender in production at the time, I was quite sensitive to this >> happening during BBB, with features implemented well enough for the >> team's specific purposes, but not so practical for other use cases. It >> happened in Sintel (hair dynamics is one example), and it now seems to >> be happening in Mango. One example that I'm familiar with right now is >> how the render API seems to have been bypassed and all but forgotten, >> during the rush to get Cycles in a usable state. >> >> Another issue is that the open project are usually exploring new >> territory for the development team - that's often a major reasons for >> existence of the projects (eg. 'improve blender's furry hair styling >> and rendering' or 'improve live-action vfx compositing'). It's great >> to have a focused target, and it's often a good way to get things >> done. The danger however is that often the coders and artists involved >> have little experience in a particular field that they're exploring, >> and the design decisions and implementations may turn out to not be so >> good in hindsight, and maybe aren't so good to commit to for Blender. >> >> There's a tendency to think that since a movie project got completed, >> then that particular area of functionality is 'solved', eg. "BBB got >> finished, therefore hair styling and rendering is done, and we can >> move on". In reality, Blender users can be left with tools that really >> don't work that well outside of the project's specific needs, or tools >> that now with the benefit of hindsight and experience, should have >> been implemented in a better way. However if developers keep moving on >> to newer things, and if this happens across all areas of >> functionality, the end result is an application made up of parts which >> are all first-draft attempts, which work 'ok' in some situations but >> not in others, and never smoothly and elegantly. >> >> One positive example on the other hand was the render branch after >> Sintel. The easy thing to do would have been to satisfy the casual >> users who want to play with new toys, add it all in, and move on. >> After all the development work that was done on it, it was really >> commendable to see self-reflection and the willingness to step back, >> critique it, and say "This isn't right for Blender and its users, it >> needs to be done a better way", and throw a lot of it away. In the >> end, it led to cycles, which I'm sure most Blender users will be much >> happier using in the long term, and is hopefully shaping up to be >> something that's actually a great tool to use, not just a 75% done >> first-version. >> >> This is also a good argument for doing movie project-specific >> development in a separate branch. Adding these things into trunk as >> they are coded makes it much more difficult to revert later on. >> >> So! For these open projects to become more effective ways of achieving >> the goal of improving Blender as a package, not as a project-specific >> tool, there needs to be a period of critique and further work after >> each project. I know from experience that at the end of a tiring job >> when you just want to forget it all, have a rest, and move on, the >> last thing you want to do is go back over it all and re-work it, but >> that's the difference between doing this development for that movie >> project only, or for Blender in general. >> >> Questions need to be asked - "Is this the right way to go?" "Should we >> revise this with better design decisions?" "What worked and didn't >> work well during the course of the project?" "What hacks did we have >> to do to make this work, that we should clean up?". And even if the >> design is good, and it worked well, and you wouldn't do it differently >> a second time around, it's still very important to ask "Is this enough >> for general use by other Blender users, not just this open movie team >> working on this project?". Some of these will come out as feedback >> from other users during the course of the project. Each time a >> response to feedback is: "It's not a target for our project", it would >> be a good idea to write it down, and re-visit the idea in this >> debt-paying period afterwards. >> >> Anyway, this is just my observation from many years of watching these >> projects, and quite a few of using Blender in production. I know in >> the past I'd have found using Blender to have been a much more >> positive experience if more effort had been spent on finishing >> unfinished work and paying off these technical debts, rather than >> moving on to newer things. >> >> cheers >> >> Matt > Hi Matt, you hit the nail on the head! > > This is something I'm quite conscious of and try to avoid the habit of > hacking in stuff just for the movie. > > Even so - we aim to make blender great for some open movie but only > have 2-3 devs working on it and what with bug fixes, hardware failure > and random features that are needed `yesterday`, We end up something > much more limited/crappy - as you describe. > > It would be interesting to investigate ways to mitigate this effect > (with follow up development projects, or more time spent before to > meet the dev targets needed for the project). > I really would like to see a stabilizing phase that concentrates on refactoring and documentation, while at the same time fixing various postponed issues. 2.49b was nearly rock stable, 2.5 was a pain at first but got better over time and was quite stable with 2.6.2 or so, even if i have to admit that not all design goals for 2.5 were reached (still a lot of dependency issues). But recently i noticed several new bugs introduced through bloated code (mainly because of various fixes/hacks). The 3D view is a good example. One bug gets fixed two new bugs arise.
I would assume that there were to many new big things included at once in a too short time window, while many needed things/fixes moved onto the todo lists. I'm happy that we have cycles now. But at the same time I'm a bit frustrasted because of the dependency: Why would i need a good renderer if several bugs keep me from creating the models and animations needed for a good looking render? _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
