Xojo bug bash

There are a pile that have been archived that arent even that old
4000+ last time I looked
No idea how many of those still exist

I’ve given up trying to reopen mine that do still exist as its futile

I nominated 10
1 has been chosen so far and labelled with the bug bash 2022 label
Not fixed yet

Very predictable

The lottery is: will it be fixed or not. People voting the bugs they have. In this case a low level not too much disturbing bug can have much more votes than your ShowStopper Bug. That IS lottery. Prioritizing Bugfixes begins not with User Voting it begins with the resulting problems of a Bug. Fixing should always be in the right direction. Starting with the Showstoppers and ending with for example simple typos. But here it comes the other way around: people voting a Bug and while many people more are disturbed from this small and not show stopping detail it will be fixed.

Bugs that crash the IDE or the framework should be TOP priority
Not triaged based on an estimate of how many people it might affect

After that things like conversion errors etc, that could & should be caught in regression testing need to be fixed

After that do whatever they want

Correctnees and stability are too important

Whether anyone likes it or not.
Xojo Inc. has limited resources and they have to decide which bugs to prioritize.
The whole idea of the bug bash was, that some MVP complained in the MVP chat, that the whole prioritization would cause some bugs to be never fixed as they never rank high enough to get attention.

clearly said: in the current situation it is wrong what ever you do. I know that situations.

Great they are doing one

USERS have been asking for Snow Leopard releases (basically bug bash set of release) and bug bashes and bug fix only releases for way longer than the MVP program existed

Never occurred

But now MVP’s requested/complained/petitioned and OMG It has to happen

So yes
Great that it IS happening

We’ll see what the results are I guess

Maybe a change from bug + new features in every release and a tick tock “feature release”/“bug fix release” cycle right alleviate some of the complaints about the lack of bug fixing ?

Its as much perception as it is reality

EDIT : since this topic comes up so frequently I decided to add to my now pissed off self’s post

Perception is sometimes MORE important than reality
Xojo could switch to bug fix release/feature release/bug fix release/feature and I bet they’d be able to counter the perception that bugs dont get fixed promptly

AND its a good marketing opportunity

In recognition of the issues our MVP’s and USER’s have brought up over the years we’re making a small change to our rapid release model …

folks would CHEER !
Hell I’d cheer and congratulate them for finally altering the perpetual beta state of things

But no Geoff is right and to hell with all those complainers and whiners

Anyone wonder where the percerption that Xojo DOESN’T listen to its users comes from ?

1 Like

There are certain things that should be addressed regardless immediately… and subtle data corruption is one of those things.

Maybe I’m making a bad assumption, but I have to think fixing such handling issues for doubles under the hood should be pretty trivial…

So it is seems to me it is really more of a matter of priorities/values more than resources for things like that. The resources needed to fix that when first discovered would have been (or should have been) minimal for an engineer who knows what they are doing, is concerned with data integrity, and is familiar with the code.

Tolerance for such bugs makes the product seem unreliable for whole classes of applications.

As I said, this one could have bitten me badly and made me look very bad at work…

-Karen

1 Like

They do fix a lot of bugs right away in the pre-release stage.

We’ll see how well the bug bash goes by comparing how many bugs are fixed in the next release compared to previous releases.

Amen brother. When the IDE is wonky I lose all motivation to work in Xojo.

And with those limited resources the lousy management chose to prioritize Renaming things a couple of times, change the documentation and marketing over bug fixing for years.

5 Likes

:+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1::+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1::+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1::+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1::+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1::+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1::+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1::+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1::+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1::+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1::+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1:

Yes, Xojo has “limited resources” - like absolutely everybody else.

But THAT was never the problem.

The problem was what they CHOSE to do with those resources.

And THAT is plainly on the guy at the top.

3 Likes

That is a lame excuse for a company that has been around for 25 years. You can hide yourself behind that reason for (maybe) the first 5 years because you are still building up to something real, but Xojo Inc is kind of stuck in this permanent ‘start-up/beta’ state.

They should ask themselves why is that. Why do they still have not enough funds to expand their engineers team? Not enough sales is the obvious answer. But why is that? Mediocre product? Bad management? No long term vision? No fresh/young ideas? Neglecting doing bug fixes year after year? Bad planning capabilities? Bad testing procedures? Missing a senior software architect that can make the right high-level design choices? All of the above?

There are plenty of companies doing similar things that do seem to be able to manage all of that with success (sometimes with even smaller teams). Mainly because they provide stable and reliable end products and timely intervene before the pile of bugs becomes insurmountable. Xojo’s pile does not come out of the blue, but is an infection that has been lingering for nearly a decade and nobody in Xojo Inc. seems to have seen it coming, while the warning signs were pretty obvious for outsiders.

3 Likes

What will they do starting September 1st ?

a. Issue a new Release with all the fix…
b. Resume work as usual until 2023r1 ?

like B4J/I/A, like CodenameOne, like Vaadin…and many many many more

I know there are as well
But when you look over
https://tracker.xojo.com/xojoinc/xojo/-/issues/?sort=popularity&state=opened&first_page_size=20

The fact that so many popular things are feature requests probably pays into why the do what they do
Not saying I agree with it
Bugs shouldnt need piles of votes or bug bashes to get fixed
As sooner or later they tend to affect a lot of people even if one person voted for it
Its not IF you’ll hit that bug - just WHEN

3 Likes

Sigh.

I explained for YEARS that FEATURE REQUESTS are CUMULATIVE (“Everyone wnats iOS support”) but BUGS are SOLITARY (“Your listbox bug is not the same as my listbox bug”). And as a consequence feedback is heavily skewed towards feature requests.

Is that really so hard to understand? Or why else is that myth still propagated?

I could scream when I read “…but most top cases are feature requests!”. It’s idiotic. Of course they are.

Oh dont get me wrong Markus
I agree with you

I’m just saying tat the fact that there ARE so many top items in Issues and formerly Feedback that are feature requests probably influences Xojo to think that feature requests are vastly more important to implement than bug fixes.
I have reason(s) to believe they believe this myth

1 Like

I’m guilty of voting for feature requests. Toss your tomatoes, I’m part of the problem. However, it’s easy to vote for a cool wizz-bang feature without knowing all the pain it could cause. Or that the result will fall short of what you imagined. Even the name changing had applause from me because I heard consistency like “0-based” and such. Little did I know…

Part of the problem with “Voting”, is when a “bug” languishes for years, and people say “WHY!”
Xojo just say “Hey, not OUR fault, you voted other things higher”

1 Like