Hence the comparison he’s making against another product - one where there aren’t that many bugs to be fixed (obscure or not), so they all receive attention and fixes (if warranted) in short order. Much like your own products Christian.
We can’t do this - they don’t give us the ability to see more than ~150 non-beta/non-private cases in any list, which doesn’t even cover an entire month. But I’m pretty sure a) is indeed much greater than b).
One interesting thing I noticed is that there’s a lot of “missing” case numbers which I assume are either beta cases (I no longer have a current license) or private cases. Either that or they just delete some cases.
For me the newest list is covers about 15 days
Of the 150 cases I can see
114 are bug reports
9 closed as duplicates, 5 closed misc, 2 closed no longer reproducible
22 fixed
2 information required
10 needs review
58 reproducible
1 reviewed
5 verified
8 are beta bug reports
28 are feature requests
Thats a lot of new bug reports to accumulate in this short time
The only way I see to stem the flood is to improve release quality so fewer bugs initially go out the door initially to be found eventually
EDIT : but like AA the FIRST requirement is to admit you have a problem
You cant fix what you dont believe exists
Looking at the bugs in Feedback is depressing. Xojo could fix 10times the bugs and it wouldn’t make a dent in the huge mass of bugs. The old and obsolete bugs need to be closed. But even telling them “hey, bug xyz can be closed” is like talking to yourself:
well since this site and forum exists, why don’t we list here most wanted bug fixes here ?
so we can vote freely for a bug fix, and if a bug has dozens of vote listed maybe they will care more
i know it has been said for years, but this way to make constantly new things like iOS or web apps doesn’t focus on fixing bugs.
Norman, you worked there.
You know it’s a small company with lots of clients in diverse usages of the product.
So you may know they need to prioritize and can’t fix all of them.
I did
I know they cant
Its why I say the things I do
They cant fix every bug that comes in in a timely fashion
Couldnt then
Cant now either
Improving the initial quality the day a release goes out should STILL be a goal
There are ways to achieve that
Most of it comes down to process - not technical skill etc
Comments where people say “this bug says it was fixed”, sometimes years ago, but cant find a release note saying it is in a release. That sort of thing
Thats process
Regressions creeping into releases. Thats a lack of regression testing.
Thats process
Finding new bugs in new code or new changes. That demonstrates a lack of unit testing.
Thats process
The process is what needs improving
And I make NO claim about my work there having been perfect.
That would be arrogant
Looking at my past bug reports: they fixed nearly 40% of them (some fix took very long time). Is that an acceptable number? Not for me anymore. I am rewriting my apps in Java.
Since I used the MBS-Complete plugin I can make a comparison: You answered every question I had and you tried to solve every problem I had (but there were almost no problems). In the end, I have nothing to complain about your product, I was 100% satisfied.
Thanks. But Xojo Inc. is at a bigger scale.
They get probably a magnitude higher numbers of bug reports.
Feedback numbers are a bit bloated for automatic crash reporting, which causes tons of duplicates. Older IDEs may send in crash reports for fixed issues in current version.
OMG !
seriously, i’m thinking i’m traveling back in time, reading some exact statements like 5-10 years ago ?
so why we don’t do a most important bugs list needed here, so everybody can relate, the feedback app is not readable as web page.
I guess the point is WHY do they get that many more bug reports ?
They have what - 5 developers ?
Do they get 5x the number of bug report you do ?
or more than that ?
I’m sure no one has a way to know
BUT - to say “oh there’s nothing we can do about this” is untrue
Do something to improve release quality so new bug reports slow to a trickle
Do more regular releases that are JUST bug fix releases.
Thats it
No one is suggesting much beyond that
Even 2021r2 which I think is the one they say is JUST bug fixes in response to case http://feedback.xojo.com/case/61900 has a bunch of “new features” for the code editor , etc and so has a decent chance of having injected NEW bugs
When I created that case I literally meant BUG FIXES ONLY
no features no enhancements
ONLY FIX BUGS
I know that wont be popular with marketing but TBH marketing shouldnt be driving what needs to be in any release
yes we all could agree that you provide great support for your product. no doubt, we should all thanks you for that for all the years you spent, so thank you
That is actually really sad, and totally on the Technicall debt reasons. A bug is a bug even if it is “little”. Any company saying “yea, I dont care about bugs while the tool kind of work” that is a mediocre attitude and they will have their mediocre success, “still existing” after many years…
I have some of those, not relevant anymore but still open. Others, fixed or implemented with a private FC and mine still open , and some that was closed because it is not reproducible any more (Do they fix it by accident and no one knows how it was fixed? )
As long as they see that mediocre “still existing” as success…
Good example, years ago I made a FC to exactly avoid that by just adding a simple “DON’T SEND” button. 2 minutes fix to save them from that bloated Feedback…
To this day: “Status: Reviewed”
Why is that so difficult to understand for some?
Basic QA and improve quality of existing features before chasing “new” features (which are released half baked and really buggy anyway)
That right there says it all. Trying and retrying to make excuses does zero to improve or correct the issue. And it is not a new issue, these discussions have gone on for a long time and if history says anything they will continue for the life of the product. For anyone that wants to use Xojo the reality is that they have to come to grips with the poor quality (good enough for most things) - that is the company’s expectation.
While you’re always prompted to report the bug from the ide aka open feedback, you’re not required to submit the ticket as there’s a Discard button when you get to the feedback app. I often do this when I’m trying to reproduce an error and don’t see the need to keep spamming in similar reports.
For one, Christian doesn’t have to develop ui which is notoriously difficult to automate the testing of. I probably have 100+ unresolved ide ui bugs, do they stop me using xojo, the majority of them don’t. Should they all be fixed, yes as they reflect poorly on the perceived quality of the app.
I don’t get to test releases any more as they booted me out of the testers group, on the release of 2021r2 the first bug I found was less than 20 seconds after first run while testing new functionality. I’ve now put in 38 bugs in a week, they were all newly discovered bugs with only 2 being marked as by design. Out of those 36, only 6 have been fixed so far. They weren’t all related to work done in this release but the number of bugs being found far outweighs the number being fixed as I’ve looked at the data a number of times and even posted the figures in a rebuttal to Geoff about it on TOF.
If each of those bugs takes two hours to fix which is probably a low average over the the entire set of bugs accounting for all processes involved then they’ve got 2 weeks worth of bugs to fix on just what I’ve reported.
Then you get into the discussion about who fixes a bug, is it quicker for the bug creator to fix it or a new set of eyes, which is more efficient, a well versed bug fixer can be a totally different beast to a new feature developer. Do you have you person with all the knowledge doing the dirty work or more quickly making new features because they know how everything works.
Do you bug fix on certain days, do you bug fix at certain times of the day, what happens if it’s an urgent fix do you interrupt someone who is working on something else. How good/quick is that person as task switching, do you lose 10-15 minutes of productivity every time they do.
It’s never black and white or easy to figure out, in fact, I’m glad I’m out of that rat race.
On this I’d agree
Was one of my pet peeves as well
IF making canvas based controls accessible were decently possible then a person could use AppleScript on macOS to do UI testing of the IDE
That doesnt help with Windows or Linux though (not sure what does there TBH)
Non UI-framework bugs should be possible to reduce to close to 0 with decent unit & regression tests
The list of bugs with API 2 newly introduced method etc suggests this isnt being done
, and some that was closed because it is not reproducible any more (Do they fix it by accident and no one knows how it was fixed? 
)
Why is that so difficult to understand for some?