> @Knapp, don't think comparing blender to kubuntu makes sense in, a > collection of packages and a single software project are very > different - Enough distros manage to get this right so expect they > have internal troubles getting enough maintainers or quality of > packages. > - Campbell
Another example of a release failure is KDE 4. They released and called it stable and thus it was being using in distros. Problem was that it was far from finished and very buggy. This lead to the massive flood of users going to other desktops. To this day KDEs reputation is not as good as it was. There needs to be a clear communications between devs and users about what is alpha, beta and final releases. Stable releases are expected to be full featured, stable and usable products, dev releases are not. Any software released is a collection of programs for the most part. They might be called programs as they are in a distro or they might be called libraries as they are in Blender. What is important is that we have devs that can make new features and fix bugs and that we have a large group of users that will report these bugs. Devs get grumpy when they can't write cool new things that they are into. Fixing bugs is not as much fun but really important. Users get grumpy when these features don't work or the program is to buggy to use or the new features take to long to come out. Users come in two groups, pros that want stability and hobbyist that are OK with a few bugs as long as they get to use the COOL NEW stuff and they can save their work between problems. Everyone hates it when a bug hangs out and gets ignored. The biggest group of users of Blender was hobbyist according to that graph (last year?). But perhaps the most important are the pros? I think that is a hard call because pros are important but how long has it been since pros had much respect for Blender compared to the expensive programs. I think it is the hobbyist (talking users here) that really have pushed and pulled Blender to where it is. Publishing often as a dev version and also having a stable version lets both groups have what they want. Branches are the playground areas for the development of new ideas but surely not the areas with the best testing. Code review is great for learning and maintaining quality but how many bugs does it catch? I have to say I have a lot of respect for Michael Fox because he was ALWAYS on IRC Blender and has always helped me greatly there. It is because of his help that I managed to become somewhat good with Blender art. I would really like to know what bugs he is talking about and why they have not been fixed. A great key to Blender is keeping good users happy. This brings me back to my, "The Cathedral and the Bazaar", quote. 7. Release early. Release often. And listen to your customers. So Mr Fox, what is up? What errors are not being fix that are bugging you? How long has this been true? What do you think needs to be done to fix this problem? (perhaps a new thread here.) I know one bug that has been sitting there for a really long time. Blender sees two different keyboards in KDE linux with the keyboard switcher being used. Sometimes it sees the CLI base keyboard like with hot keys and then other times it sees the keyboard switcher keyboard like in the text editor. I think this is a the type of bug that is not often seen because not many users have the Dvorak keyboard as their base CLI keyboard but it is a real pain in the butt for me. I used to do all my blender work in the qwerty keyboard (that would be the switched one) until this bug showed up. At this point I am so used to it that I bet it would be a pain to relearn again. So as I understand it the plan is to keep code in the branches until it is solid or bug free (as good as that goes) and then merge it into trunk. The problem as has been pointed out is that beta users and normal users don't use branches. They will use Stable or they will use Dev. In the case of Blender I see Stable as the one you get from the front web page and Dev as the SVN compile it yourself (or in my case the daily build that I get with Ubuntu). I will never go through different blanches and try them out on a regular basis. This mean that branch code will violate the ideas of release early and release often in terms of getting many eyes to find the bugs. I think this brings us full circle back to where we were. Forcing a stable release before it is ready is a bad idea because users start to think Blender is buggy and it sucks. Releasing stable just because of a deadline is bad for the same reason. Having lots of quick releases of a dev version is a great idea because we expect bugs there and it lets uses use the coolest newest features. As was pointed out, many users did not switch to the 2.5 line until it was called stable. I am really against having a stable release that is not well tested and debugged. It just makes Blender look bad and that looses users, especially the pros who don't have time to waste of don't want to hurt their work reputations on buggy half ass software. A solid stable Blender means a solid stable Blender 3d reputation! One other point to think about. Locking the program down to find bugs and not allowing new feature work tends to make devs loose interest and go elsewhere so it is good to keep locks from inhibiting new code addition work. This is a great thing about having branches. Branches let devs play with new ideas without hurting the bug killing going on in stable prerelease (alpha, beta). @ Ton Roosendal. I think you have great track record with Blender. You will manage to make to find the best path. -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers