[Bf-viewport] [Bf-committers] blender2.8 branch being taken too lightly (imho)

[Julian Eisel]

Hi,

I definitely agree here. I was actually planning to write a mail too.
I am really concerned about the state of the 2.8 branch. Right now I'd
consider it completely broken, I find it hard to do any dev work in
it.
While it's super cool to see so much process happening, I'm sure we're
just shooting ourselves into the foot if we take feature quantity over
quality.

Here is a list of things that I'm worried about.
* New collections/layers code breaks half of Blender. Only some parts
of Blender have been converted to the new way we store objects and
their data. IMHO, before any new collection/layer features are added,
we should work on getting this fixed. It's not hard but really dirty
work (I've actually done this before for GSOC, tell me about it!), but
it has to be done.
* API naming: Some new 2.8 code completely breaks consistency in
API/function namings. E.g. with new Gawain code we have functions like
add_attrib or immBegin called *a lot* throughout the entire code base.
New collections/layers code is also pretty sloppy in it's own API
namings (or maybe I just failed to see! ;) )
* Compiler warnings: Lots of code has been committed with warnings
that are easy to fix. Think in master we follow the policy to strictly
avoid any new warnings (with default compiler flags), we should stick
to it in blender2.8 too. We actually had real bugs in blender2.8 that
went by unnoticed because warnings were hidden within the jungle of
other harmless warnings. Right now I get about 300(!) warnings in new
2.8 code.
* Code Style: Commits in blender2.8 handled this quite careless. We
should all stick to our guidelines ([1]) for internal Blender modules.
I recommend using our check_style_c.py script [2] for this.

On top of that all, there is one issue, and I'm afraid it's a really
major one by now: After various actions (like selecting objects),
Blender gets incredibly slow here. This has been confirmed by others.
It's an issue we've discussed many times before, but it's gotten
*much* worse lately, to the point where a simple redraw for changed
button highlights takes seconds. Also happens in release builds.
To be fair, Mike investigated this in the past and added some great
performance improvements for the new immediate mode code (good job
nevertheless!). However, it seems like the actual issue is somewhere
else.
I'm afraid a big part of the 2.8 project will fail if we don't get
this issue resolved. We can't deliver Blender like that so we had to
revert all the OpenGL upgrade work. At least on OSX that would mean
major 2.8 features like the new viewport wouldn't work until we're
fully on OpenGL 3.2 core profile again.

[1] https://wiki.blender.org/index.php/Dev:Doc/Code_Style
[2] https://developer.blender.org/diffusion/BDT/browse/master/check_source/check_style_c.py

Sorry for long mail </rant> ;)
- Julian -

On 23 February 2017 at 14:46, Ton Roosendaal <ton at blender.org> wrote:
> Hi,
>
> No stepping toes here. Branches should just always work, especially the ones more people work on together.
> It's a good habit to never commit code that breaks things. And if that's inevitable, align the other coders to help fixing it with highest priority. Or ifdef things out.
>
> Luca: so, if yo notice someone committing code that breaks things, just notify the person immediate. He/she is not meant to do this without general approval.
>
> Laters,
>
> -Ton-
>
> --------------------------------------------------------
> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> Chairman Blender Foundation, Director Blender Institute
> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
>
>
>
>> On 23 Feb 2017, at 07:58, Luca Rood <dev at lucarood.com> wrote:
>>
>> Hey,
>>
>> I don't mean to cross any lines here, but I feel that this is important to be said.
>>
>> As far as I'm aware, the blender2.8 branch is supposed to replace master eventually, and much of the development has moved there already.
>> Also, the word seems to be to keep blender2.8 stable, within reason.
>>
>> With that in mind, it seems logical to take just as much care of blender2.8 as master. This is one of our main development branches, and shouldn't be treated as lightly as one's personal branch or such.
>>
>> Despite that, and especially with the OpenGL immediate mode work going on, we continue getting commits that break Blender because of simple negligence.
>> For instance, often the UI gets mangled, or we even get segfaults because of simple OpenGL mistakes, that could easily be avoided if the code was actually tested at all.
>>
>> I think everyone would appreciate it if we all tested our code before pushing it, to avoid at least the most obvious mistakes (a successful build does not always mean that stuff actually works :P ).
>> So this is just a reminder for everyone to please test stuff before submitting (at least a little bit...)
>>
>> Again, I mean this just as a friendly observation :)
>> If I'm wrong about my interpretation of the purpose of the blender2.8 branch, please let me know.
>>
>> Happy coding,
>>
>> Luca
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers