@freak
If you read what @tm1000 indicated, it was that attempts by the dev team to reproduce this were unsuccessful. He said once there is a dianosis that translates into something that can be reproduced, by all means file a bug so we can take further action. There are many more eyes in the forums, and much more brain power available when there are what appear to be ambiguous or un-reproducable problems. We triage every issue and we have multiple engineers who's full time job it is to develop, work the bugs, etc.
Part of managing a large project is to triage issues and apply the limited resources in the most efficient way possilbe. Problems like this are often solved much more quickly by asking that they be hashed out to where we can get reproducable and actionable issues that we can go after. We could have just left your ticket in the ticket system, and then it would simply stagnate. That wouldn't do anyone any good. It's entirely more productive to encourage further disussion here and one of the HUGE benefits of the code base being Open Source.
Thank you for pointing that out. The information is wrong and outdated and I've brought this up to the team. That was written a few years ago when app_confbridge was in fact new. In the supported versions of Asterisk, it is not only mainstream, but I believe we should no longer support app_meetme. I've already brought such up to the team and we will make the evaluation. We should have noticed this during FreePBX 13 development and simply removed it, but this was an oversight. At a minimum we will make sure app_confbridge is the default and the information is updated appropriately, and then remove app_meetme from the next version. The team will however deliberate if we should be removing it from 13 as an oversight for something that should have already been done.
So are you insinuating that there isn't a community of people of all calibers here, including all the developers of the project, who don't ineract in the forums, never provide help, never contribute to troubleshooting, finding bugs, etc.? Your very interaction in this thread and the feedback and help you've provided to @freak would seem to show the opposite.
Yup, that appears to be the case here. I can tell you from a decade of experience on this project that this happens often. It's usually "impossible" to solve in the lab because there is something different. So we can have an engineer spend hours beating their head on the wall with no results while a lot of other bugs go un-worked, but that doesn't make sense for the rest of the user base or us. When this happens, it's usually solved by discussions in the forums. Sometimes it leads to a bug that gets reported and fixed, sometimes it's a mis-configuration, external component, portions of the system not fully updated where the problem is already fixed, or other localized issues. We are very far from perfect, but with hundreds of thousands of systems out there, we've gotten reasonably good at also detecting when to "look harder" even if we can't reproduce it in the lab. We do not ignore issues. When there are enough signs, between forum reports, tickets opened from multiple sources, our own support services, etc. we go beyond our own development and test systems to further diagnose issues 'in the field' where they can be reproduced. We do that based on data though, and there's enough systems out there to get that data, we don't do it because one individual is "a bit pissed off" and "is going to be pretty annoyed with this whole situation." Our goal is to maximize the value for as much of the community as we can.
If you are going to make such bold statements, maybe you can back them up with data from the ticket system, after all, it's completely transparent and the data is there for you to pull and either demonstrate that we have "lost our way" or otherwise show there may be a big difference between your perception and the reality of the situation. Given that I sit on our bug triage meeting every week, I can tell you that we assign out dozens and dozens of tickets constantly to be fixed, further triaged, dialoged with reporters to get more needed information, etc. Maybe I'm seeing what I want to see? Why don't you go to the ticket system and see which way the scale tips since if it's in the direction that you are claiming, I would very much like that corrected. However, I think you may find otherwise.