It takes time and effort to file a bug report. I have filed two. In one case, in line one of the report, I stated it was Postgres-specific. The tester put together a sample project based on my report, using SqlLite. Couldn’t repro the bug. “Oh, I didn’t realize it was Postgres”. Not an auspicious start. Then he asked ME to modify his test project to demo the bug.
On the second bug (requesting column info on a table not working) the same guy tried to argue that it wasn’t really a bug despite that the method claims the table has no columns. I mean in what universe is getting back no data when you ask for it not a bug?
I also noticed at this point that some of the other Xojo users seem to be so used to this that it’s almost like Stockholm Syndrome. People were guessing what some secret trick might be to get it to work. People, it’s a bug, just fix the blasted thing. Nor does it really handle error conditions correctly. If you tell it to return column info for a non existent able blargh, it just returns an empty rowset – so now you can’t tell the difference between a table that doesn’t exist and a table with no columns (which is possible in Postgres). It should throw exceptions when there are … well, exceptions. It doesn’t seem to be aware of Postgres schemas, so unless your table is in the public schema, as far as this function is concerned, the table might as well not exist.
In the end I just said look, I’ve documented the problem – both a bug and poor documentation actually – and I have an acceptable workaround in the meantime so mercifully it’s non-blocking for me (I just went straight to the Postgres system tables. If you want something done right … do it yourself. Took me 5 minutes, which was a fk-ton less time than reporting the bug). The bug is marked Reproducible. At this point, either fix it or tell me I’m full of crap, but I have used up my bandwidth for this about 3 times over and am not going to discuss further.
So … not only do I have the sense that I have to jump through rings of fire and eat little pieces of glass just to get to square one with any bug I might consider reporting, but both of these bugs, especially the second one, seemed to me like something that should be fixable in a few minutes for someone familiar with the source code, and in a lean little company with some pride in the product it could have been pushed out in R3 or at least specifically scheduled for R4. But I have the feeling it’s just going to sit there forever. One reason might be that these bugs have a certain smell to them … the smell of a leaky underlying abstraction or possibly incomplete work on the supplied Postgres driver. To really fix it might involve more than appears because it wasn’t properly implemented to begin with. Maybe the root cause of the Postgres issue leads to things that need review and more test cycles for other supported DBs. And maybe they’ve given up on DB independence like this function seems to represent, and are leaving it to MBS. IDK. Too much of a headache. Just hope it goes away, that’s easier than fixing it properly.
Anyway this is my roundabout way of saying that what would float my boat here is to take the effort to treat bug reports with great respect, quickly and systematically work through them and get them fixed in the next release cycle or at least the following one, every time. NEVER let them languish. NEVER have a silly “bug bash” and don’t even fix all the bugs accepted into it, and then act like that’s some kind of accomplishment when you still have a huge backlog of bugs, including some that are years old.
A bug report represents a failure of the product already. If users have no confidence in the process of reporting and getting bugs fixed, then it’s a triple failure: the original bug, failure to fix it, and disrespect for the value of the time of users who are also BTW paying a fairly pricey subscription to use your product.
(I understand users sometimes consider something a bug that arguably isn’t, and that bugs have to be prioritized. But it’s a failed system if it treats reproduced bugs as, meh, let’s just leave it in there. It’s okay if things are broken. No. Just no.)
ETA: I’m not inclined to file any more bug reports. And maybe that’s the whole point of how the system works. In fairness … neither bug was a show stopper and in general things work fine for my simple test use case of a single desktop target for what amounts to a glorified CRUD app. But if Xojo doesn’t care about anything but show stoppers then I will not report anything but show stoppers [shrug].
