In my opinion handling complex reports like this requires as significant effort by both the triaging team and the reporter. As someone who has worked on the triaging team before, I’ll try address your points as good as I can.
I often encounter more complex scenes in commercial production scenarios that are full of interdependent issues. In current case, the scene has about 6 objects with complex modifier stacks which take several dozens of seconds to calculate. This results in Blender freezing for about half a minute.
This sounds like the issue is easily reproducible from a triaging perspective, but there needs to be a good reason why the modifier stack evaluation that causes freezes in combination with heavy use of modifiers is a bug. Performance issues are generally not triaged as bugs.
Refreshes of these modifier stacks are caused by seemingly random things, for example turning off a collection that has absolutely nothing to do with those objects, or adding a new material onto an object completely unrelated to those objects. Or duplicating it. There are numerous different action that seem to trigger update of modifier stack on completely unrelated objects. At some point, the .blend file becomes more or less unusable because doing pretty much anything freezes Blender for over half a minute.
This may be a consequence of Blender’s design that you are not aware of and doesn’t necessarily have to be a bug. Performance issues can have a variety of reasons and addressing them can be quite complex. Based on your description I cannot say whether or not it actually is a bug, but you could ask developers of the relevant modules if the behavior you’re seeing is expected. If it isn’t, then we will try to find a way to address this.
(Note: In my original answer I misread this paragraph and therefore assumed a different cause)
It is required to always report only one thing per report, so all the different things that can incorrectly trigger the modifier stack refresh would have to be reported as separate issues.
There is no need to file different reports if the underlying issue is obviously the same. The important part is that there needs to be at least one way to reliably reproduce the bug.
There is no mechanism for sharing files that are under NDA
That is correct. Depending on the issue, you may be able to replace the meshes with different ones that still allow to reproduce the bug which would avoid the NDA problem in this instance. If that doesn’t work, you should try to take a look at the original mesh and check in what way it is different to the replacement (non-manifold, degenerated faces, topology, …). This may already provide a starting point for further investigation.
Since the file should be limited to parts absolutely necessary to reproduce the problem, it is usually possible to remove or replace content that is covered by the NDA. I do understand that this does require a significant amount of work from the person preparing the report though.
There is no mechanism sharing large files
On the bug tracker itself this is intentional for two reasons:
- Most bugs really don’t need large files and the reporter should try to narrow the cause down as much as possible instead of handing the triaging team a file that contains hundreds of things completely unrelated to the issue. This makes triaging unnecessarily difficult and time consuming. It is in the reporters own interest to provide a simple file that allows to reproduce the issue to keep the triaging process efficient. There may be cases where it’s really not possible to remove or simplify anything, but those are quite rare. In those exceptional circumstance it’s a good idea to have a chat with the triaging team to coordinate. If the issue is only reproducible in that very specific project, but it allows to reproduce the issue reliably, then it might still get accepted.
- Disk space is limited and the infrastructure couldn’t handle it if everybody starts to upload files that are multiple gigabyte in size.
If it is absolutely necessary, then there are ways outside of bug tracker for hosting such files. However, if the triaging team accepts those reports is decided on a case by case basis.
There is no mechanism for interaction with the bug triage staff in real time, since issues of this complexity can rarely be showcased by just a linear list of steps.
That’s not entirely true. While we don’t provide 24/7h phone or chat support, but we can all be contacted on https://blender.chat/ and we have a dedicated channel #blender-triagers. This channel is not meant for user support, it’s for the internal organization of the triaging team. However, if a complex bug situation needs coordination with the team there is the possibility to reach out either to the entire team or specific members.
In general it sounds like you are looking for enterprise customer support, which Blender doesn’t offer. The good news is that Canonical’s support appears to provide pretty much what you’re looking for.
This means you will either have to do your best to provide us with a manageable example file that you can share without breaking the NDA and coordinate with the triaging team or you / your company could sign a contract with Canonical for commercial support.