simon.schvartzman wrote: ↑Tue Mar 17, 2020 5:15 pm
About one hour ago there were 4074 bugs with CONFIRMED status reported on the quality forum, some of them going back to 2003...
Screen Shot 2020-03-17 at 12.05.00.png
Probably many of them are obsolete and some of them have somehow "gone away"...
A great many. I go through the outstanding bugs a couple times a year, flagging those no longer relevant for the OP to close. Too often the OP does not respond. Sometimes I can get one of the engine team members to close those that are obviously irrelevant, but some reports have specialized circumstances and it would be best for the OP to confirm whether related fixed may have addressed their particular use case. Closing a report prematurely is about as unproductive as having an irrelevant report remain in the DB; not an easy call to make, so currently we err on the side of completeness.
Each of the ones affecting your work now appear from the report notes to have ongoing activity:
Still there are some (at least for me) important ones and for which there is no way afaik to know if/when are they going to be fixed. Moreover, and again afaik, there is no way to learn how the priorities are defined and therefore where in the queue my "pet bugs" are standing.
Examples:- Bug 15124 - mobilegetcontactdata crashes app on ios 8.2 reported 2015-03-31
https://quality.livecode.com/show_bug.cgi?id=15124
Comment #9 from Hanson shows the team did investigate the issue shortly after it was reported, but had difficulty reproducing it, requesting additional details from the reporter. It took the reporter a couple months to reply, but LC's Sebastian (comment #11) was still unable to reproduce the issue from the information given. There was some back-and-forth after that regarding testing of related fixes, but given how specific the recipe is your comment added this morning is very helpful, allowing the team to better assess scope of users affected by this specific intersection of circumstances.
Similar to the previous case, there was a long period pinning down the details of the recipe. On the one hand the issue is specific to certain models of Samsung phones, and only with certain Android versions. But on the other hand Samsung is among the leading Android phone makers, so it's definitely worth the effort to pin down. Compounding this issue is that Samsung makes extensive modifications to Android, so issues seen on their phones are sometimes unique to their phones, making diagnosis difficult. With so many phones in the market, bugs that are model-specific can be difficult to pin down. In comment #8 Panos notes that he was able to obtain the model in question and confirmed the issue, though at the moment with your comment the number of affected users for this specific intersection of recipe requirements seems to be about 4. With your comment this morning I hope we see a note from Panos on current status, but there are issues they're working on that affect a much larger number of users, so any fix may not be immediate.
This is another one specific to one version of Android on a subset of compatible hardware. With such a narrow intersection, Panos was unable to reproduce the issue, but has provided instructions for developers to obtain logging info which can help him pin down the root cause. Your submission of log info there is helpful, but appears to be the only developer who did so. With so little information to go on for such a specific bug it may be difficult to diagnose, and with the affected Android version being several years old (5.1), the ever-declining rate of affected users would make this one seem unlikely to become a high priority. Just the same, I appreciate your recent comment there, and have subscribed to the report so I can follow along and provide relevant details as I come across them from elsewhere in our community.
So my points are:
- has LC a plan to change this situation or should we coexist with it for the rest of the times?
- is there something we can do to help LC clean up the inventory warehouse? For instance from time to time we receive promotions ads for new licenses and/or products, what about a promotion to buy X bug fixes?
The answer to both questions is a solid "yes".
I've been working closely with the team for several years in my role as Community Liaison, and have come to appreciate many aspects of their work as I become more familiar with it. They follow good engineering practices and have an uncommonly smart crew, but with a code base of nearly a million lines, and platform coverage almost no other company even attempts, it is indeed a challenge to stay on top of edge cases like these. And all the while OSes update their APIs and compatibility requirements, and staying on top of those is a huge task in itself.
As with any system of LC's scope, bugs must be addressed by priority, which is a balance of severity and scope of affected users. While the three issues listed here are severe, they affect relatively few users. And worse, each is so specific that it's been difficult for the team to reproduce them, slowing progress down further. This isn't to suggest these will never be addressed. But it does mean they will have to take a back seat to things affecting a majority of users, like accommodating OS changes.
Your recent comments on those reports are helpful, and will hopefully assist them in moving forward on those issues.
As for things we can do for bug fixes, there are at least two:
As open source projects go, LC has relatively little in the way of code contributions from its community. This is understandable with engine issues, since most of us are scripters and those among us who are also expert in C++ and Java are few. But if we can find members of our community to address these, perhaps motivated by a modest bounty, progress on edge cases can come more swiftly.
Another option some of my clients and colleagues has used is to negotiate a fee for reprioritizing edge cases above more pervasive issues directly with the company. I've seen about a dozen instances among friends where a given issue had enough value to their business that it was easy to justify the investment, and they got pretty quick results that have wound up in the engine to benefit all of us.
The best option for your needs will of course depend on many factors. As with anything else in life, the more of the work we can do ourselves the easier it is to get others to take action - many times I've researched relevant APIs to find proposed solutions to problems I've encountered, and with a solid recipe even such a modest effort has accelerated results.
I wish there was a simple answer to resolving all outstanding issues quickly. But there isn't. Most companies sidestep the issue altogether by supporting half as many platforms, or having much higher licensing fees, or enjoying the support of generous contributors who donate large sums of money to development.
On the whole, LC seems to be doing a pretty good job of balancing resources for delivery. Given the size of the code base, when we use the industry metric of bugs-per-thousand-lines-of-code, LC is well below the industry average of 15-20 (McConnell).
Of course we'd all like that to be zero, the team most of all, but no non-trivial code base has ever been able to make that claim, and a small company is unlikely to become the first.
Hope all of you and your families do not suffer from the epidemic
Thank you, Simon. Same to you and yours.
(unfortunately) gave me more time to wonder about...
)