3 ms·

I’ve found several bugs in SQLite, one of them pretty fundamental and obvious. It’s a complete nightmare to report them, forcing you to use some utterly terribl

by orf 5y ago

I’ve found several bugs in SQLite, one of them pretty fundamental and obvious. It’s a complete nightmare to report them, forcing you to use some utterly terrible forum software with limited searching, visibility and a shockingly poor UI. Genuinely the worst and most confusing thing I’ve had to use in the last decade. Sourceforge issue trackers are a step up from this. They also offer no convenient way to test your system using the latest RC/beta/alpha/whatever without manually staying on-top of the releases page and updating it. I don’t think the rest of the comment warrants much discussion, but I wanted to point that out.

petre 5y ago
> forcing you to use some utterly terrible forum software with limited searching, visibility and a shockingly poor UI You mean Fossil? We use it, it works great for us, doesn't get in the way, doesn't require constant rtfm. Also you could just clone the repo if you want to test. It exports to git.
geofft 5y ago
Are those crashing bugs, though? I'm making a very specific and nuanced claim here - that crash reporting is not a required mechanism for delivering high-quality software. If SQLite is low-quality software, but the manner in which it is low-quality does not involve crashes, then that does not contradict my claim. There are a lot of ways software can have bugs other than crashes: incorrect behavior, confusing defaults, missing features, inaccurate or nonexistent documentation, poor API design, etc. Automated crash reporting can't help with any of that. If you discovered that "SELECT * FROM users WHERE paid = 1" returns unpaid users too, that's a really bad bug, but no automated crash reporter could possibly tell the SQLite developers about it. I do agree with you that users of software at scale don't report bugs and so you can't rely on them reporting bugs; I'm just pointing out that there's no reasonable way around it except for crashes, and there are other ways to address the specific use case of crashes. There is an unreasonable way around it: add an analytics framework that tracks every click and mouse movement and keystroke your users do. There are web analytics libraries that do exactly this and let you replay your users' behavior. I hope we all agree that Audacity should not do that. (By the way, if I go to https://sqlite.org https://sqlite.org , there's a "Support" link at the top that tells me to use their forum. You can then click on the forum link, click "New Thread," and click "Remain Anonymous," and there's apparently a way to post things. I guess this forum does actually use Fossil internally according to the message at the bottom, but it seems really straightforward to me, so I am surprised at your claim that this is confusing....)

by orf 5y ago

petre 5y ago

> forcing you to use some utterly terrible forum software with limited searching, visibility and a shockingly poor UI You mean Fossil? We use it, it works great for us, doesn't get in the way, doesn't require constant rtfm. Also you could just clone the repo if you want to test. It exports to git.

geofft 5y ago

Are those crashing bugs, though? I'm making a very specific and nuanced claim here - that crash reporting is not a required mechanism for delivering high-quality software. If SQLite is low-quality software, but the manner in which it is low-quality does not involve crashes, then that does not contradict my claim. There are a lot of ways software can have bugs other than crashes: incorrect behavior, confusing defaults, missing features, inaccurate or nonexistent documentation, poor API design, etc. Automated crash reporting can't help with any of that. If you discovered that "SELECT * FROM users WHERE paid = 1" returns unpaid users too, that's a really bad bug, but no automated crash reporter could possibly tell the SQLite developers about it. I do agree with you that users of software at scale don't report bugs and so you can't rely on them reporting bugs; I'm just pointing out that there's no reasonable way around it except for crashes, and there are other ways to address the specific use case of crashes. There is an unreasonable way around it: add an analytics framework that tracks every click and mouse movement and keystroke your users do. There are web analytics libraries that do exactly this and let you replay your users' behavior. I hope we all agree that Audacity should not do that. (By the way, if I go to https://sqlite.org https://sqlite.org , there's a "Support" link at the top that tells me to use their forum. You can then click on the forum link, click "New Thread," and click "Remain Anonymous," and there's apparently a way to post things. I guess this forum does actually use Fossil internally according to the message at the bottom, but it seems really straightforward to me, so I am surprised at your claim that this is confusing....)