[Bf-committers] Handling of user data.

Mon Apr 10 00:52:59 CEST 2023

I mean the thread doesn't specify did they crash but I assume they must
have since the save prompts for unsaved modified image files are on by
default now?

On Mon, 10 Apr 2023 at 00:27, Ray Molenkamp via Bf-committers <
bf-committers at blender.org> wrote:

> Ton,
>
> It's been nearly a year and we're seemingly still hurting people [1]
> you're a clever one!
> you only said it deserved priority, not that it would actually get
> priority, i fell for that one!
>
> I don't see this realistically happening for 3.6, but please I beg you,
> make it a prio for 4.0
> this really has got to stop.
>
> Greetings,
> Ray
>
> [1]
> https://www.reddit.com/r/blender/comments/12f8nh9/omg_spent_hours_texture_painting_and_its_gone_any/
>
> On 2022-05-13 7:09 a.m., Ton Roosendaal via Bf-committers wrote:
> > 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
> > _______________________________________________
> > 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
>