Xojo bug bash

Reading the forum posts by the devs, I am under the impression that The bot will bring your next case only if the Top one was rejected, but if your top one is fixed, the bot will NOT choose any nother from your list.

:thinking:

some process is better than none

whether it works out equitably & major bugs get fixed - we’ll see

that it had to come to a “bug bash” instead of a regular process that fixed and didnt introduce more bugs is still … well … frustrating, disappointing, disheartening

all things I’d expresed for years

I read that as we can nominate 10 cases.
The bot will add the label to one of those 10.
The case will be evaluated and either fixed or rejected (not to be fixed in August for whatever reason).
Once the label is removed another of the 10 cases will be labeled next and so on until all 10 are fixed/rejected or we reach September.

I don’t see that it says that only one will be fixed.

The surprising-yet-disapointing thing about this one is it didn’t seem to take Paul any time to fix it. I got a notfication that Paul had been assigned to it, then in a few hours it was fixed. Maybe further proof that this bug didn’t really affect the Xojo devs, because if it was that easy to fix, they would have already.

1 Like

Indeed, but at the end of the day, if the devs plates have been constantly full for 9 years they won’t get the time to fix stuff like this because its “just” a UI issue and not something game breaking. If a dev needed to move something a great distance up the navigator, they might very well have taken a minute to open another workspace to get around the problem instead of getting their hands dirty for 5 hours to fix it. It’s surprising how many times people will perform a mundane task before they bite the bullet and spend 10 or 100 times the time to automate/improve it.

If it did take Paul 5 hours flat out from assign to close then that’s a good chunk of the day for a UI issue, multiply that by the number of UI issues in the system and you could probably lose a full time member of staff to just UI fixes. At the end of the day the ROI on that wouldn’t be quantifiable which is another reason why it might not have been fixed sooner. On the flip side of that though, you can’t quantify how many skipped buying a license because of all the little UI issues they saw with comments like “crikey, if they can’t even be bothered to fix that, I can only imagine what insides of this thing are like”.

But yes, a 9 year issue fixed in 5 hours is pretty sad, I’m sure we’re going to see some more of these over the month. At least they are getting looked at.

I think Alberto explained it, 1 case, fixed or not the label is removed, another ticket is then chosen by the bot.

1 Like

All hail our new overlord, “The Bot.”

1 Like

Why are some bugs listed (and counted) twice as fixed?

Because they are more important? Inflation? Bad organization? Charging twice for the same bug fix?

they want to inflate the “numbers”?

On TOF:

I was just informed that I inadvertently posted duplicate case numbers for two cases on the list this morning (and left two off the list entirely!). Apparently new comments that happen after the case was fixed will bump it to the top of the list. All of the counts, however, are correct. To avoid future confusion, I’ll post weekday count updates and a link to the full list - feel free to bookmark it if you’d like to check it periodically.

Well, that was a very roundabout way of getting something corrected, but hey, it works so don’t bash it …

Looking at the bug bash list , this one horrified me that it could remain unaddressed for 7 years:

PostgreSQL Prepared statements with doubles

I was writing what would have been a major app at work (until the new COO said they would rather buy commercial software) using PostgreSQL…

This bug could have bitten me big time and have been very hard to find!

While developing an app a couple of weeks ago I got bitten by a similar issue using Xojo’s JSON in 2019r1.1 … but luckily the erroneous data caused an obvious issue. As my code looked right, I tried compiling in 2022r1.1 and the doubles were handled correctly there.

Losing precision is not always obvious!

-Karen

2 Likes

Bugs that corrupt or result in the wrong result should ALWAYS have the highest priority. That Xojo doesn’t see it this way shows that they haven’t got their priorities straight, and is the reason for me to move on …

1 Like

That is the nice about the bug bash.
They cleanup a lot of old cases, which never made it to the top list.

1 Like

cases that should have been “cleaned” up a LONG TIME ago.
The best thing for Xojo would have just been to exert this “effort” quietly, and claim the “gold star” during future releases.

By holding this “BUG BASH” event. it just puts more of a focus on their failures in the past

1 Like

But the type of bug that silently corrupts data is the type of bug that should be addressed as soon as found, regardless of how many people they THINK it affects. It’s not like a UI glitch, or slow performance. It is one that is subtle, but can be disastrous in some circumstances.

My question is how does code under the hood like that get through internal code review? Does no one notice that the code would cause loss of precision? The person writing that code should have been aware of that to start with… And as I said at one point there was the same bug in their JSON implementation.

Me making such mistakes is understandable. A professional engineer writing that level of under the hood code should know how to handle doubles …That is why there are computer science degrees.

An organization making the type of mistake multiple times is unfathomable to me as well. The first time that was found and fixed in one area should have sparked a code review of other things where it could be occurring. It should have been recognized that the same error was likely made elsewhere.

Errors in such basic things should not be tolerated or accepted, It should be considered extremely serious and addressed immediately…

-Karen

6 Likes

Bug Bash should have been named Bug fix lottery. Why? While we do not look on a normal vendor behavior: fixing Bugs as soon as possible but on a Big PILE of Bugs nobody can really handle anymore in that small team. The result is: people have to vote which Bug is the most important to fix. Makes it complex to work with while: if my Showstopping bug is not fixed Bug Bashing would never help me. The classification how many users are effected by a Bug for prioritizing is also dangerous. Many users will not report and report and report when they get that a Bug will not even be reviewed or after review will not be fixed while nobody has the time.

So Bug Bash is in my eyes a nice numbing substance for the users of Xojo to hold them silent and happy while the Bug Amount is not sinking but climbing.

And last but not least was the renaming of events and strikethrough of old bugs as deprecated bugs not helping over the big amount of Bugs in Xojo and it’s frameworks.

Hey, nobody is perfect. But let’s have a look on another small vendor and how he is holding it with fixing Bugs. Loog on the Github Panel of CodenameOne and see how it is working. They have fast fixings for Bugs. And on top most of the “bugs” are not Bugs but wrong use of Features.

That shows: it could be so much better. But for this we need a vendor which wants it to be better. Much more manpower is needed for pushing that amount of targets and frameworks through the time and fix the bugs of the Development. That is the fundamental view on the Situation. No Manpower no Bugfixes. And that makes it impossible at the moment to fix the Bugs.

1 Like

It’s a step in the right direction. Bug Bash needs to be every other month. until no one has anything to add.

But it does feel like a lottery. But even before it was a lottery where you had to beg Geoff.

Maybe if Geoff did that a decade ago, more peeps would have stayed around.

2 Likes

We could nominate up to 10 issues. And I could have guessed in advance which one of them will be chosen - the one that’s least important and easiest to fix.

In that sense - it hasn’t felt like a lottery to me, but quite predictable. More lottery feeling would have been to have a bot randomly pick one out of the nominees.

I guess next time I better only nominate the most important one :wink:
Again something that I should have seen before, but got blinded by the “up to 10”.

no, it needs to be every day, a continous process

1 Like

Like exercise… Thing is Xojo has to get off the sofa first. :slight_smile: