[Bf-committers] Handling of user data.

[Ton Roosendaal]

Hi Ray,

> deleting the users data without their consent
> isn't OK, has never been OK, will never be OK,

Fully agree with that.

The list of critical issues is way too long. But this deserves top 
priority for fixing.

-Ton-

----------------------------------------------------------------------
Ton Roosendaal - ton at blender.org - www.blender.org
Chairman Blender Foundation, CEO Blender Institute / Studio
Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands


On 12/05/2022 22:17, Ray Molenkamp via Bf-committers wrote:
> I don't think there's any disagreement between me and bastien
> we both agree it's a problem that just isn't getting the
> attention it deserves. The disagreement is with the people who
> set the priorities.
>
> Most of the priories are seemingly set by the needs of the
> blender studio, they have learned a long long time ago, how
> to "not lose data" to the point it has seemingly become a
> out of sight out of heart style problem.
>
> My somewhat cheeky prod on the mailing list was meant as
> a reminder, deleting the users data without their consent
> isn't OK, has never been OK, will never be OK, and we should
> be fixing it rather than waving it away going "it's fiiine,
> work on this instead" it's very much not "fine"
>
> --Ray
>
>
>
> On 2022-05-10 2:12 p.m., Zack Brown via Bf-committers wrote:
>> Hi,
>>
>> I'm also curious about this issue. It seems like Ray is giving one side of
>> the argument, but I'm not clear on the other side. This can't simply be a
>> debate between one group that is in favor of destroying user data, and
>> another group that opposes it.
>>
>> Looking at the developer task, it seems like one concern is that any
>> solution to the problem would need to take account of workflow issues, so
>> that production workflows won't be slowed down. I'd like to hear an example
>> of a production workflow that relies on blender's current behavior, and how
>> it might be slowed down if the data were simply not deleted instead.
>>
>> There definitely seems to be something to what Ray says, about saving users
>> from a data-loss baptism of fire. And there also seems to be something to
>> what Bastien says, about various big projects that currently have a higher
>> priority than fixing a standard blender behavior that has always been this
>> way. I know there are a lot of features I eagerly look forward to, more
>> than fixes for some of the known misfeatures. But I also know that I got
>> bit by the inexplicable data-loss issue myself at first, and it was a pain
>> in the butt.
>>
>> Could someone take a stab at explaining what this debate really is about,
>> in such a way that both sides would feel fairly represented? All I know
>> right now is that there's a disagreement about something that currently
>> feels over my head.
>>
>> Be well,
>> Zack
>>
>>
>>
>>
>>
>> On Tue, May 10, 2022 at 9:05 PM Ray Molenkamp via Bf-committers <
>> bf-committers at blender.org> wrote:
>>
>>> That task is over 3 years old though, it mostly reconfirms
>>> the notion that the people who set the priorities just
>>> don't see silently destroying end user data being a problem.
>>>
>>> I hope this short thread serves as a wake-up call and this
>>> and the other core improvements you mentioned will be made
>>> more of a priority and time will actually be allocated for
>>> it in the next release cycle.
>>>
>>> But I'm not getting my hopes up here.
>>>
>>> --Ray
>>> On 2022-05-10 12:54 a.m., Bastien Montagne via Bf-committers wrote:
>>>> Hi Ray,
>>>>
>>>> We already have a task to address this issue:
>>>>
>>>> https://developer.blender.org/T61209
>>>>
>>>> But this needs time to be properly handled, and these days we spend
>>> everything besides regular maintenance on 'big projects', so... this one
>>> and several other relatively small core improvements and fixes keep being
>>> delayed from one release to the other.
>>>> -- Bastien
>>>>
>>>> On 5/9/22 21:12, Ray Molenkamp via Bf-committers wrote:
>>>>> All,
>>>>>
>>>>> It's been years [1] (2018) since I last was rather
>>>>> vocal on this subject, but how is this [2] still
>>>>> happening? "Yes, blender deleted your data (and silently
>>>>> at that), that means it's working correctly!" cannot
>>>>> possibly be the best we can do, is it?
>>>>>
>>>>> While I'm excited with all the directions blender
>>>>> development is currently going, it's utterly depressing that
>>>>> users are still losing data on a daily basis because
>>>>> we can't quite get the basics right like "do not delete the
>>>>> users data without their consent".
>>>>>
>>>>> These are *NOT* isolated incidents [3]. Losing your
>>>>> data and learning about "the fake user" shouldn't be
>>>>> a right of passage to become "a real blender user".
>>>>> Users shouldn't be silently *losing* data in an operation
>>>>> ironically called *saving*. That's crazy, no other
>>>>> application behaves like this!
>>>>>
>>>>> Yes, I know this is how we have always done it. No,
>>>>> this is not OK, never was.
>>>>>    Ton: Please make protecting the user’s data a
>>>>> priority, as it doesn’t seem this will happen otherwise.
>>>>>
>>>>> --Ray
>>>>>
>>>>>
>>>>> [1]https://devtalk.blender.org/t/oh-no/505/2
>>>>> [2]https://developer.blender.org/T97968
>>>>> [3]https://devtalk.blender.org/t/more/22715
>>>>>
>>>>> _______________________________________________
>>>>> Bf-committers mailing list
>>>>> Bf-committers at blender.org
>>>>> List details, subscription details or unsubscribe:
>>>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> List details, subscription details or unsubscribe:
>>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> List details, subscription details or unsubscribe:
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers