I just found it. I haven’t had a chance to open a ticket yet but then again, I’ve got tickets from 4 years ago I was assured would be handled by the CFO. Still open. I’ll report it when I have the chance.
Yeah, I have zero confidence that things are ever going to be handled in any kind of reasonable timeframe.
Example: @lgaetz suddenly hit a year old ticket of mine and now it will be closed in 5 days because I do not have time to respond immediately? I mean I would have to recreate the entire scenario at this point.
https://issues.freepbx.org/browse/FREEPBX-21590
1 Like
Supposed to be, Corportate stated “there is”, and reality are 3 completely unrelated realities, when it comes to this project.
He didn’t ask you to reproduce it… He asked basically why can’t you.
Based on the other replies it looks like the ticket is basically a won’t fix…
I agree, that is looking how this is going. However, why wasn’t this handled that way back in June 2020? The fact that the ticket system is poorly managed is not helpful for anyone. Not the users, contributors or the developers that need to do the work.
If this ticket is truly a Won’t Fix, then comment on that and mark it Won’t Fix so it’s closed out. The current ticketing system looks like a mess of unattended and ignored bugs and feature requests. It really makes it look like no one is paying attention and there’s no real structure.
Just before I left I closed out anything over 2 years old. That seemed to be the consensus that anything within the last two years is probably workable but anything older may have already been taken care of. That said I know we did triage calls every Tuesday where we would go through all of the open bugs and build out what needed to be done. I don’t know what the current engineering plan is obviously. I have noticed in watching commits and pull requests which I still do that many tickets are done under FREEI which are internal tickets so you can’t necessarily see the relation or reasoning behind it. One of the things I saw recently made zero sense to me but it was an internal ticket so any explanation to why can’t be publicly seen. I hate to say this but one of my reasons for leaving was the project being controlled by project management which is 100% business case focused. This means all engineering decisions had to have a business case related to the bottom line. Some things that made it into 15 were forgiveness over permission.
1 Like
That was obvious from the start.
You don’t show why/how things cause a problem with having a scenario in place to (re)produce it. Also, somehow I didn’t have a thread here first. I usually do. Annoying.
Would this be like the conversation from certain Sangoma members in the Open Source Lounge meetings 100% commenting on how things can be sold?
Yes, I believe that the version of mariadb should be more up to date (coinciding with the version shipping with CentOS8, IIRC).
EDIT:
Oops, I misread the question. FreePBX 16 will continue to have the SNG 7 version of MariaDB. The eventual SNG8 will have the more current version of MariaDB that is associated with CentOS 8. so sorry about the misunderstanding.
2 Likes
Hey,
There is indeed a QA group that works, verifies and tests FreePBX.
Unfortunately, due to the complexity and breadth of features that FreePBX covers, it’s a challenge to have 100% test coverage, especially when doing manual testing.
It’s a lot easier to do more comprehensive testing with automated testing and automated test frameworks, which is a direction we’re slowly trying to figure out how to take FreePBX in so that we can catch more corner cases in a more scalable manner.
As far as the sip to pjsip converter bug, that does sound like something we’d want to address at some point, especially considering our long term goal as a project to make sure that there are no solid technical reasons (or major challenges) that would cause someone to need to remain on chan_sip. We’ve been generally prioritizing working tickets (from Sangoma’s perspctive) that fit within that theme.
Would you mind opening a ticket on it so that it doesn’t get lost?
Thanks,
Matthew Fredrickson
1 Like
As the Open Source community liaison, it’s my job to cheerfully receive questions, comments, thoughts, rants, via email or PM. @BlazeStudios if you, or anyone, want to share any old closed tickets with me, please don’t hesitate to do so. We can re-evaluate things based on how things stand now.
My email is my forum handle at sangoma.com
1 Like
I guess there are lots of different perspectives on this - my previous experience with the Asterisk project has seen a similar balance that has to be maintained for it as well.
For commercially sponsored open source projects like FreePBX or Asterisk, at the end of the day part of what the commercial sponsor has to do is to make sure that we’re working enough commercial or commercially driven work balanced with general open source work so that we can keep paying developers as well as hopefully trying to hire more so we can keep driving the project forward.
This is generally a good thing from the larger project perspective as it means that there are more people involved in evolving it and moving it forward. The other angle is to get more people involved from the community developer contribution perspective. This last year or so I think we’ve seen a solid increase in regular community contributions which is very encouraging thing. Hopefully that will continue as we seek out ways to make the project more accessible to open source developers.
The other challenge is that we have on an ongoing basis a large enough influx of tickets on issues.freepbx.org that we can’t work them all and complete them in a given period of time. So sometimes even important tickets get overlooked or forgotten about. Usually not intentionally, just by the shear volume of ticket inflow that we’re dealing with and the size of the backlog, and other emergencies/tickets we may be handling at the same time.
We are humans, and sometimes we make mistakes. If you feel that there is an important ticket that has been forgotten about or overlooked, it’s very appropriate to add a friendly bump comment to the ticket (particularly for old ones) or petition myself, @lgaetz, or other friendly open source community developers that may be seeking an interesting bug to work.
I know that was a lot, but hopefully it lends a bit of clarity into some of these things from a Sangoma perspective.
Best wishes,
Matthew Fredrickson
1 Like
While I 100% agree that everything costs money, I find it extremely annoying to be in a meeting called “Open Source Lounge” and then continually hear certain Sangoma people discussing nothing but monetization.
I’ve recently convinced my company to setup a partnership agreement with Sangoma, and we are going to begin offering your products. I have zero objection to making money.
But, it annoyed me enough last meeting I actually said “except this is the open source lounge” in the actual meeting last time.
1 Like
So I’ve been dealing with a large install today so I haven’t been able to fully follow this. I did see something about how people make mistakes and hey, I have another thread for custom keys on Yealink I was having issues with. I had a mistake in the config. I also made a mistake about the bug I thought existed because I forgot it was a customized box and one other key thing.
There’s no support for outboundproxy setting for extensions in FreePBX so the issue with the conversion isn’t really a bug since that setting shouldn’t exist in normal FreePBX setups. I had injected it on this box. So no need to open a ticket.
And @lgaetz my tickets I am referring to are from when v14 was still being worked on, so 2017. If @jfinstrom already closed tickets going back two years in 2019 the tickets are most likely closed. But they mainly revolved around the UCP and the fact that anyone converting from 13 to 14 would have to rebuild every single users UCP dashboard and that there should be templates the PBX admins can create for this. At the time I had systems that had 100’s of users on them that had UCP access and going through each of those systems and creating their panels was just a real PITA and a huge time suck.
Here we are four years and another version later, I am about to migrate an old v13 box to v15 with 100’s of users that have UCP access and I’m going to need to rebuild all of them because it will just confuse the hell out of the end users if I leave it to them. In scenarios like this or new deployments of this size it becomes a real nightmare for admins who need to give UCP access to the users. Got the extra step of training how to build their UCP before training how to use it. In cases of upgrades, it changes the entire user experience and in some ways not for the better. Sorry, I’m just dreading the horror this is going to be for weeks.
2 Likes
Yeah, I would tend to agree that having an overemphasis on commercial topics is probably the wrong balance for the Open Source Lounge. I’d love to have more open source related discussion topics in the meeting.
To some extent, there are a lot of people that build businesses around open source and open source products and are generally very entrepreneurial in nature so I do understand that there are some people that may be very focused on it, but having more general topics (outside of commercial) is interesting to me as well.
Matthew Fredrickson
How 'bout tickets that are still open after 18+ months and the problem still exists in FreePBX 16?:
3 Likes
I haven’t seen that problem for months, for any system I have built on Debian 10. Might be something peculiar about the RPi implementation.
Okay try this one from a year ago. IMO a decently important bug with more and more systems migrating to 15+
https://issues.freepbx.org/browse/FREEPBX-21423
Even a comment on the quality of the bug report……
Edit: not saying this needs fixed over other things. But it is an example as asked.
@lgaetz with chansip disabled, will that need to be enabled to use chan_sip based upstream trunks?
I’ve not dealt with chan_sip clients for many many years now, only pjsip, but trunks are a different story, most of the big boys use broadsoft and most still dont support/enable pjsip