[Bf-committers] Blender Release Cycle

[Knapp]

On Wed, Aug 17, 2011 at 12:06 PM, Thomas Dinges <blender at dingto.org> wrote:
> Hey Matt and Campnell,
> I generally agree with you here, but I don't agree with 5) All new
> features are developed in a branch
> What defines a new feature? How big must the impact be for it? I mean
> it's senseless to write a small feature which only affects a few lines
> in some areas to be developed in a branch. So we need to define what
> features must be developed in a branch and not.
> Also I don't really want to take away the module owners rights really.
> The code should be checked better, but it doesn't make sense really for
> core devs.
> I think it's better to give us the possibility to say "This is not good
> enough" and revert , if it gives us issues, rather than forcing a module
> owner to develop everything in a branch too.
>
> Another thing that came up yesterday by some devs in IRC, is that we
> might better increase the cycle to 12 weeks.
> And on second thought, it's really a lot of work to have 6 really stable
> releases a year, 4 would be sufficient imho.
> This way, we would have more time in trunk to do bug fixing after the
> big merges in bcon 1/2. And I have to agree with it, better not rush
> releases out.
> Fixed cycles and planning yes, but give it a bit more time.
>
> In general I definitely agree with you Matt, we have to be more strict,
> otherwise it can get worse.
>
> Best regards,
> Thomas
>

My favorate linux distro was Kubuntu. Now it has become so unusable
that I have had to change to other distros on my computers. I think
the biggest reason of this is that they have a 6 month release cycle
and them comes new features. After a few years of this the quality is
so bad that it is no longer usable. Open source should be released
when it is ready and not before. It is OK to have time goals but not
time walls. Also I think we all know the real testing comes from the
mass of users, not the programmers. This means public releases and
then bug fixing. I rather like the programs that have a dev version
and a stable version. This work because the users get to pick based on
their own needs. It also leaves the dev version open for big bugs and
fast progress without hurting those that need a stable program.

7. Release early. Release often. And listen to your customers.

This is the basic idea of the open source process. Having a dev
version allows for this and having a stable version allows for the
pros to have their needed stability.

BTW As stated before almost no one runs branches. Ii is NOT a way to
test things out. It is a great way to try new ideas and allow for
programmer freedom but when that is done it should be merged into the
dev branch.

Of course all IMOHO.

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