[Bf-committers] Blender Release Cycle

[Knapp]

> @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/