From what I read in the comments under the task, the unfixed issues with his addon were causing issues for some other addons. I don’t see anything unreasonable here. No addon should ever be bundled with Blender in such a state it interferes with other addon.
The fact his addon is no longer shipped with Blender also does not mean the addon has vanished. Those who rely on it can still get it from the author directly. But while I’ve never head of this addon, I actively use addons by MACHINE, the guy who he got in conflict with. So if I had to pick a side, the choice is clear
The problem wasn’t that there was a request for a fix to be backported, the problem was in the tone it was done with.
The moderators are very powerless in this area because they are unable to remove comments.Only the people with admin accounts can do it.
I’m not an official Blender dev but there is a pretty clear description of the duties of someone contributing an addon to the official Blender releases at https://wiki.blender.org/wiki/Process/Addons. That page has changed a little in the last few years, but the basic idea has been the same:
The addon is to be maintained by the contributor
He/she is responsible for fixing bugs that users report. It is not the duty of the official Blender devs, as the addon is not maintained or supported by them
“Add-ons that are not supported (or no longer supported) by their authors may be removed from Blender if they are broken & we can not find a maintainer.”
Seems the situation here is that the addon maintainer no longer wanted to maintain it in all the required ways (i.e. not just for 2.90, but also for the LTS releases). Especially one of his comments is telling:
Try downloading de 2.9 version and copy paste to 2.83. I’m going to work for the latest version. I regret the decision to do double duty. I can’t be doing things twice.
The point is: he is the one to do things twice for multiple releases, as he is the maintainer. Sounds like he actually doesn’t want that role. So the contributor could also have been more constructive, in trying to find a second maintainer for his addon to keep it working for older versions of Blender. Instead, he complained about the language being used and pulled the addon.
Edit: one of the Blender devs actually suggested to look for a solution 6 minutes after his announcement to pull the addon, but that apparently wasn’t enough to change his mind.
Edit 2: this, of course, could have been handled better from both sides, but my estimation is that the addon contributor did not really want the role of addon maintainer as described. Maybe that role changed over the years, given that the addon has been around for a long time. Plus the new LTS release indeed adds to the burden.
yeah this whole saga just makes me think that the addon author was kinda tired of maintaining it anyway and just needed an excuse to pull it. I don’t think the request was out of line or inappropriate/inconsiderate at all, and to be completely honest I think it’s probably best that the addon got removed rather than allowing something that’s not being maintained properly be distributed with the official releases.
Right, the whole point of including addons in the official releases would be to provide high-quality addons which are maintained on the same level as Blender itself and work with each official release. If that cannot be guaranteed then an addon would be better off in a standalone repository which the author can maintain as he/she sees fit.
This particular issue seems to have been a collision of a contributor that did not really want the role of official addon maintainer coupled with a commenter that communicated too direct and formal in the bug tracker.
Since the topic has shifted very much into the recently linked issue, just wondering what exactly was bad about that exchange?
There are loads of people who contribute to open source from around the world, and people from the same region can even interpret things differently.
Moreover, the add on did not work in the LTS release, reportedly. If that is the case, should it not be removed? Given that it’s officially distributed in the long term support release? And shouldn’t long term support be, supported for a long time?
Also nitpick but this doesn’t really feel like a Blender Development topic. Seems to make more sense in “other” since this looks more like twitter drama but that’s more opinion than anything.
Respect means a lot of different things to different people. I think the community would be a lot better not drudging up Twitter drama and just respecting people’s decisions and allowing them to live their life. But that is just my opinion and is neither here nor there. Ultimately I think this was a fine outcome since the addon was not supporting the LTS release which would not make sense to officially ship with.
From what I read… it looked like there isn’t even a policy in place about that, yet. I don’t personally think the LTS release should apply to addons. I’m certainly not willing to do that for my addon, although mine isn’t built-in to Blender. If you want to have the newest version, use the newest version!
For small projects like addons, I don’t think it makes sense to have the elaborate branching structure that Blender has. Blender has to do versioning and bug-fix branches and the like because it is a huge project with dozens of active contributors. Addons usually have a handful of total contributors. One maintainer should not be expected to deal with a new branch for each LTS and for each release of each LTS! Even if the bug fixes are simple… especially if they are simple. You might run into a situation where the bug-fix branching structure is as much work as actually fixing the bugs.
And finally-- I think it’s too much work for individuals. I work on my addon in my spare time, sometimes weeks pass and I can’t look at it, let alone work on it. I have to choose between fixing bugs and adding features. I don’t think individual maintainers can be held to the same standard as teams.
And I think the above dialogue is evidence of an equal and opposite problem – maybe some of the bug-trackers have made bad or ill-informed decisions… but there are a lot of entitled and even incompetent bug reporters. You can’t always tell when it’s user-error. The bug-trackers are not inexperienced, but they may seem that way if a) the reporter is inexperienced, or b) the bug-tracker mistakenly assumes that the reporter is inexperienced. In the first case, the reporter just doesn’t understand the technical discussion (and I think this was the case in the initial post, T79518). In the second case, I think the bug triage staff makes wrong assumptions because they don’t know what the user knows.
Ultimately, I think it’s a bit silly to complain about FLOSS code if you aren’t a contributor, or at least an active member of the community. The option of just fixing it yourself is always open!
Be polite and constructive, don’t communicate in demanding tone with volunteers. Treat such conversations as your business correspondence with some extra friendliness on top.
Back to topic:
Also, don’t assume immediately that other people are not experienced enough. Double check your bug evidence. The result of unnecessary discussion is dragging more people into it, and for example, each of 5 developers spend 30-60 minutes to get into discussion and answer, 5 manhours wasted, and this time could be spent to make something cool for blender instead.
Feel free to discuss your issue with ordinary users before you make a decision to submit a bug report.
If I see in some report that some of them have been wrong, I try to discuss and explain my point of view in good terms.
They are working even on weekends. Considering the large number of varied reports in all areas of Blender, they are doing an excellent job. Thanks to all of them!
Both are exactly the same class of the issue - a negligent design resulting in very easy way to lose data. I just can not understand how such a severe issue can be so promptly ignored. How can anyone not realize how serious this is?
I’m not a Blender developer, but for both issues you mention these are strictly speaking not “bugs”. As you say they have to do with the design choices (and someone that doesn’t agree with those choices would probably consider them issues). Although I can see how you would class them as similar, I’d say they’re subtly different.
The hard file deletion from the file browser I can agree was good to get fixed, as it didn’t give a user the choice of moving to trash or actually deleting the file. That it did the latter was the bad part of the behaviour, although it’s still a subjective thing whether that is really bad. E.g. I work a lot from the command line and you learn quickly that rm <file> is destructive. And I have no issue with that and ended up paying closer attention when deleting files, also when using a GUI file manager.
However, for the first case of not showing an overwrite confirmation dialog the file name in red does give you an indication of what is going to happen (i.e. overwriting the file). I certainly learned to recognize that clue, even though it’s different than in most other programs. But then again, Blender does a lot of things different, which is not a bad thing in itself. In fact, I’d say Blender would never have evolved into the success that it is if the devs had always taken the mainstream approach.
But sure, there’s some subjective reasoning going on in how these issues are handled by the developers, which is unavoidable since these are not clear-cut bugs like segfaults, incorrect rendering, regressions, etc. In case of the overwrite indication I’d say adding the option to have an overwrite confirmation dialog would be good. Personally, as I don’t need it, but if others would like to have it then no problem.
The thing is, there is no other mainstream software out there which allows you to overwrite files without the pop up prompt. No amount of GUI highlighting is as efficient as one additional warning step. Even Blender itself sets the precedent of pop up dialog when you attempt to close an unsaved file:
In the same way, you could argue that if you don’t want to lose your unsaved work, you just should not click the close window button, and recognize the X sign as a warning. But we all know that’s simply not enough. So why not just unify the data loss prevention mechanism of having a pop up dialog across entire Blender, in exactly the same manner it’s present in literally almost all the other software.
Incorrect rendering regression or segfault can on average cost you several hours of work. Mistaking Ctrl+Shift+S for Ctrl+O and rapidly pressing enter can cost you even several days of work, depending on your backup frequency. I was lucky that I back up on daily basis, but people on average probably don’t.
This is the exact kind of issue where you want the software to help the user out, not to punish them for not following the unwritten rules.
EDIT: I just realized how I managed to overwrite my file:
The open and save dialogs are nearly identical, but mainly, I realized I’ve adopted a double click habit. if you open save as dialog using a shortcut, it still allows you to rapidly overwrite any file by just double clicking it, and that’s what I did looking back. If you just double click the file, the red highlight appears for only split second. That’s yet another reason, why lack of pop up dialog is so dangerous.
Thinking about this a bit more I think I understand where the current behaviour (red file highlight) came from. Originally, Blender only used a single window. There were no popups, everything was done using non-overlapping areas. So when you saved a file one of the areas would turn into the file save dialog we more-or-less have now. And since there were no windows other than the main one, there also were no pop-up dialogs.
So the only indication for overwriting that could be given was the red file highlight, at least that’s what I thought. I was completely wrong and you’re going to love this one In order to see if my idea above made any sense I downloaded Blender 2.49b (released in 2009!). When you try to overwrite a file in the save file area you get this:
I.e. there used to be a file overwrite confirmation popup You also couldn’t save by double-clicking the file (as you indicated was what go you in trouble). You could select a file and then needed to either press Enter (giving you the overwrite dialog) or press the Save as button.
Strictly speaking that’s not true. Almost all programs allow overwriting the current file you’re working on using Ctrl+S (or whatever shortcut they use). It’s when you “save as” and pick a file name that most indeed will show the confirmation dialog. Which is interesting, as the action to select the file from the list is already a moment to think about the correctness of your action. But anyway, that’s getting very theoretical.
[quote=“LudvikKoutny, post:35, topic:14718”]
In the same way, you could argue that if you don’t want to lose your unsaved work, you just should not click the close window button, and recognize the X sign as a warning. But we all know that’s simply not enough. [/quote]
I agree that the added “you have unsaved changes” dialog is an improvement. But note that having that dialog popup is still an option that can be disabled (Preferences → Save & Load → Save Prompt).
Interestingly, I’m under the impression that the save as dialog slightly changed its behaviour. In 2.92 when you type in the file name to save to (instead of picking using the mouse) you can no longer press Enter to save, you need to click the Save as button with the mouse now. You can still press Ctrl+Shift+S plus Enter to quickly overwrite (without confirmation) to the currently set file name. But if you textually enter the file name then you get red colored feedback to warn when it exists and then need to switch from keyboard to mouse to complete the action. In 2.83 you could simply enter the file name and press Enter to overwrite in quick succession.
This is very different. Ctrl+S simply means “update the changes of the file I am currently working on by storing it on the hard drive” where as Save As means something quite different, in sense of “Overwrite another existing file, which can (and likely has) completely different contents, with the contents of the file I am working on”. One is meant to store the work done in the same file, other is meant to replace different file with the contents of one you are working on.
Anyway, it doesn’t make that much sense to argue about it, because the fact it’s been so widely standardized in all the other software outside of the Blender world is a good indication that it’s probably the right choice. As for the tiny under mouse pop up, I was never fan of those. They were to easy to either lose or accidentally click.
I know Blender always wants to be unique, but in terms of something as essential as preventing data loss, I really think it should follow the global standards of file contents manipulation.
I agree that this is a design issue that should be discussed with the UI team.
The reason why tickets about design issues get closed is because it’s most of the time not clear cut 1.) if the current behavior is wrong and to what extend 2.) what the solution is. Therefore it’s generally a good idea to discuss this with people from the respective module first, e.g. through DevTalk or blender-coders. If the module members agree, then you got approval to post a ticket about it or they will create a design task for you. The reason for this is that users most often have plenty ideas how Blender could work differently and this quickly devolves into feature requests and improvement suggestions that are off-topic.
However, in this case I believe you’ve raised valid points. Maybe have a friendly chat with Julian Eisel about this idea.
The discussion about the file save behavior has little to do with the thread topic. You can open a new thread for this in the #other-topics:user-feedback section, or create a right-click proposal or use the Blender chat.
Done, but the problem is that as long as it doesn’t concern a new feature, people, including the developers, usually just ignore it. Small UI quirks or papercuts can afford to be ignored, but something, that can have as destructive consequences as this should not.
You also couldn’t save by double-clicking the file (as you indicated was what go you in trouble). You could select a file and then needed to either press Enter (giving you the overwrite dialog) or press the Save as button.