New Interface and BF-Blender

[mjordan]

What we are waiting?
Who knows when it will be committed to bf-blender sources?

Isn't it finished?

[matt_e]

Isn't it finished?

No, it's not.

[mjordan]

Isn't it finished?

No, it's not.

What I don't understand of the Blender development cycle is why some features are worked on directly on BF-Blender and some others on Tuhopuu.

For examples, new "Sine, Saw, Triangle" wavelets for marble textures have been committed without too much testing, while the Minnaert Shading is still in Tuhopuu.

[matt_e]

What I don't understand of the Blender development cycle is why some features are worked on directly on BF-Blender and some others on Tuhopuu.

I don't understand it either. IMO, all new functionality should go through development and user testing first in tuhopuu, then when it is tried and tested, and the way it works is 'approved' by users, as well as the code, by the bf module owners/admins, it gets added in then.

[halibut]

I have seen some quite nice features that have been in one build, and then they just dissapear, eg: grab the cursor. Would be nice to have this stuff as an option (or would that cause too much bloat?)

[joeri]

I think tupuhuu is a fork.
So nothing in tupuhuu makes it into blender unless the developer working on the tupuhuu branch also submits his patches to the BF release.
And... (me get looked angry at by broken) vice versa.
CVS releases should be releases to test on. And announced and published releases are the 'real' releases, be it BF, tupuhuu or superGlue (or whatever Luxuriousity is calling it's release today).

But,.. I'm not in the dev cycle, so I'm only saying what I would find logical.

[Pierre-Luc_Auclair]

all new functionality should go through development and user testing first in tuhopuu, then when it is tried and tested, and the way it works is 'approved' by users, as well as the code, by the bf module owners/admins, it gets added in then.

To do that we should actually have Tuhopuu builds. Don't wanna sound mean. I know it takes some time to compile all the stuff. But some of the new real cool features like the new timeline are stuck in tuhopuu right now.

No build = No testing = No going forward

[gabio]

all new functionality should go through development and user testing first in tuhopuu, then when it is tried and tested, and the way it works is 'approved' by users, as well as the code, by the bf module owners/admins, it gets added in then.

To do that we should actually have Tuhopuu builds. Don't wanna sound mean. I know it takes some time to compile all the stuff. But some of the new real cool features like the new timeline are stuck in tuhopuu right now.

No build = No testing = No going forward

Hey I do my best to provide build. Sometime I even debug it to compile. But joeedh work is just too complex for me to dive in just then, and it's still not working with msvc. So i wait.

[theeth]

As I see it, tuhopuu is for unstable/unproved features and experiementations.

Various patches slips in there that aren't really unstable, just not approved for bf yet but some tuhopuu dev might think it's fun to play with an commit there.

Tuhopuu has no garranty of stability so coders can go free for all style on experiementations.

Martin

[malCanDo]

gabio wrote...

> Hey I do my best to provide build. Sometime I even debug it to compile. But joeedh work is just too complex for me to dive in just then, and it's still not working with msvc. So i wait.

And your builds are VERY much appreciated!

Mal

[Pierre-Luc_Auclair]

Hey I do my best to provide build. Sometime I even debug it to compile. But joeedh work is just too complex for me to dive in just then, and it's still not working with msvc. So i wait.

I don't complain, it was just a remark. And you don't have to be the one doing the new builds of Tuhopuu. You are already doing a very good job on the bf-blender, someone else should do it IMO.

[mjordan]

As I see it, tuhopuu is for unstable/unproved features and experiementations.

Various patches slips in there that aren't really unstable, just not approved for bf yet but some tuhopuu dev might think it's fun to play with an commit there.

Tuhopuu has no garranty of stability so coders can go free for all style on experiementations.

Martin

I understand this point, but sometimes there are some features that are just committed to bf without passing through Tuhopuu first. I make an example. The softbodies code has been committed BEFORE it can have a usable form and only now developers are discussing on how to make a good integration into Blender (and this make this code UNSTABLE by definition. If it is worked on, it means it has not so much testing) So I'm wondering why the new interface should be in Tuhopuu and softbodies, for example, should stay into BF tree directly.
Many users tests only BF trees. No one is going to test something is classified unstable directly by developers. So, to me, sounds like there is not much criteria in what should be here or there. I don't want to attack anyone, be clear Just my poor views.

[llunasol]

Many users tests only BF trees. No one is going to test something is classified unstable directly by developers.

Yes, that's quite a logical conclussion. I test usually BF builds (mostly the ones from Gabio), but I don't like to test Tohopuu, because I don't like to appreciate features that I'm not sure if are going to be added to the "official" Blender. The new Timeline, new lights visualization on the viewports and new text window with coloring are really nice features, that doesn't look so compromising to be added on the official tree

BTW, almost a month since the last Tohopuu compilation on the "Testing Build" forum...

[lukep]

I understand this point, but sometimes there are some features that are just committed to bf without passing through Tuhopuu first. I make an example. The softbodies code has been committed BEFORE it can have a usable form and only now developers are discussing on how to make a good integration into Blender (and this make this code UNSTABLE by definition. If it is worked on, it means it has not so much testing) So I'm wondering why the new interface should be in Tuhopuu and softbodies, for example, should stay into BF tree directly.

the thing is, features making it directly in bf are release targets that will be finished in time. Also Ton works only in bf, so work that needs him is in bf only.

Matt work is very good, but still wip. When he feels it's ok, it will be ported back to bf.

the 2 trees have different goals and the coders review regularely what should ported back to bf.

now, of course sometime the boundary is a bit blurred between what is what