It’s not uncommon that I report a bug that gets immediately incorrectly closed or merged as duplicate. If the bug gets triaged correctly or not is currently quite hit and miss, mainly due to the fact some of the people tasked with the triage either don’t seem to have enough experience, or possibly lack of motivation to actually spend time looking in the issues.
I know the bug tracker is completely overflowing with the reported issues, but I don’t think a competition to close as many reports as possible without investigation is a best way to go about solving that issue. It almost feels like many of these people are literally paid per closed issue, and that is their motivation.
There are bright exceptions that confirm the rule, like Philipp Oeser, but most of the time I encounter someone who doesn’t even take a time to read the report.
There are false negatives here and there, but overall I think the triaging team is doing a good job. Your message is a good reminder to be sure to always communicate better though.
The issue you pointed out (T79518) was properly closed as a duplicate. But, indeed, it could use a bit more explanation as to why it was closed.
Both reports are related to how the color management of large float buffers is costly for the computer. When the image is zoomed out, the entire image has to be processed. And there is a big difference in processing a float buffer than a 8bit buffer (the png you got after you saved).
I believe a bit more technical explanation is coming to the respective tasks. but I hope this makes things a bit more clear already.
Just don’t mention a addon that doesn’t ship with Blender. My last report got closed, cause a addon was mentioned in my report. It finally got reopened and the bug got fixed.
Just don’t mention a addon that doesn’t ship with Blender.
Exactly. The tracker can only handle reports that can be reproduced from scratch AND that are guaranteed to not have been caused by 3rd party components.
I have just edited the line about the reproducible steps to report a bug to make that explicit:
Find steps to redo the bug consistently without any non-official add-ons, and include a small and simple .blend file to demonstrate the bug.
I may tweak it a bit further, but indeed all the reports are expected to be tested without any add-on playing interference.
Sergey left a comment saying " This is in fact caused by the same root cause as the T77812."… so I think that it’s a simple case of one bug causing two very different bad results. He wrote a good explanation that is worth reading.
Yeah, I am all for the explanation when the issue gets closed. But somehow I doubt the person who closed it immediately knew a deep technical intricacies that accidentally made the source of the bug related to the issue it was marked as a duplicate of. It seems like a lucky coincidence instead. My guess is that he just wanted to throw it into a bag with as similarly sounding issue as possible.
A lot of behavior regarding bug reports would make sense if they’re getting a lot of really bad bug reports, from people new to Blender and new to 3D. In that case, yeah, to sift through all the chaff, you’re probably just going to reject a lot of reports without investigating them properly. I’m not really sure of the best way to handle it if that’s the case. There are going to be dumb reports. Unfortunately, you can’t really tell if they’re dumb or not without actually putting some work into it.
The behavior that I see regularly, that I think is inappropriate, is saying that it’s due to some particular cause, without checking to see if that’s actually the cause. Plenty of times, it’s not. From the perspective of people handling bug reports, I would encourage them to actually test what they’re saying, not just out of respect to people making reports, but because that’s how you learn the application, by looking at its actual behavior, and you can’t really handle bug reports properly without knowing what Blender does.
I mean, I do this all the time, I troubleshoot Blender issues for people on various parts of the internet, and I’ve seen that if I advance a reason without testing, I should be prepared for embarrassment At the very least, if you’re not going to test, then offer it as a suggestion and ask the reporter to test: “It seems to me like this file is doing something non-standard. Can you please revise the file to follow [linked] standards and let me know if the issue persists?”
No, priority is left to default most of the times.
It’s set to high only if several users are affected or it’s caused due to a recent change.
A triager should make sure that the report contains all the required info. If possible track down the bad commit. And set the status to confirmed and tag the modules.
Fixes are welcome too
Not sure what you mean by this. If someone is causing ruckus, a ban awaits them.
Also, how do you jump all the steps in the bug life flowchart and set the priority directly ?
Wouldn’t that require building a version of Blender for every single commit? Back to 1.0?
I mean, that no special permissions are required in order to close or confirm a bug report? If none are, that would go some way toward explaining why the quality might sometimes be low.
Linked document lists setting priority as an action: " If the issue was introduced between the previous stable release and master this is a regression so its priority should be High , and status Confirmed ." (Plus, doesn’t the very concept of triage suggest setting priority?)
Unfortunately, I’m not qualified to do that. I’m only qualified to reproduce/verify issues and rule out some things that aren’t bugs. (Although I would hope that’s something that somebody, somewhere, would want to verify before letting me do it.)
No. Often it’s the previous release only. So bisecting while using ccache gets it done quickly. It’s good to have previous releases lying around and a working build version mentioned in the report.
For the rest of the comments, better spend some time on the tracker. I started out with only commenting and avoiding any destructive (read noisy emails) actions.
In this case, that makes a perfect sense. If the developer of an addon bundled with Blender does not want to maintain it properly for all currently supported Blender version, then such addon should not be bundled with Blender in the first place.
In fact, I’d argue Blender is bundled with way too many addons. Many of them are also obsolete.
Look, you have your addon supplied with Blender. You are responsible for it.
You are currently at version 4.0.0. However, the 2.90 4.0.0 version differs in various places from the 4.0.0 version in 2.83. One of the differences is the bug I’ve posted here about, and which is fixed in 2.90, but not in 2.83.
Both version also claim to work for Blender 2.80 in the bl_info. I won’t tell you how do do your development, but this is bad practice.
After an enormous and persistent contribution, all he gets this kind of disrespect, and he understandably decides to pull the add-on from Blender. This is a great loss for both Blender and the community.
This is unrelated to this discussion. If you want to bring down the number of included add-ons, you should start that discussion elsewhere.
How is this related to this thread about triagers ?
FYI, anyone can make an account and start commenting.
Phabricator has several options for emails, muting threads etc.
At the very least, if you’re not going to test, then offer it as a suggestion and ask the reporter to test: “It seems to me like this file is doing something non-standard. Can you please revise the file to follow [linked] standards and let me know if the issue persists?”
