> PS. I was truly impressed with Richard Hipp fixing each and every of these cases within a couple of hours of sending in a report.
I can't stress how quickly this will turn me from "it's a good library" to "it's an amazing library". (Or prevent me from tacking on, "but it's kinda abandoned".) I've never sent patches SQLite's way, but I've sent patches to other open source projects, and whole quarters go by with nary a peep. This is not only frustrating, but often it feels like it pushes more work onto me than just accepting an even potentially buggy patch would cause. If I'm sending a patch, there's a good chance I'm using it myself, and thus your library has become a special-cased wart in my deployment process that I'd very much like to kill. (E.g., since I work in Python: I can't `pip install package==version` anymore; it needs to be on Github or something; thankfully pip makes this fairly easy; patches to things that some other package has decided to bundle rather than just use the package-manager approved version of are especially painful.)
OT but important: We do not normally accept patches at SQLite because (1) that would endanger the "public domain" status of the project unless the patch is accompanied by a lot of paperwork and the sender resides in a British Common Law country and (2) we don't put untested changes into the SQLite source tree and (3) no matter how hard you try, your patch is unlikely to met our strict style guidelines. If you do send a patch, we may use it as a reference to try to figure out what the problem is, but we won't actually apply the patch.
It is far, far better to send us a test case. The smaller the test case, the better, but any test case will do. We are much freer to accept test cases without copyright complications, and test cases have to be written anyhow before any changes are checked in. So just send in a test case and let us find and fix the bug for you. If it is a crash bug, it is usually fixed quickly - within hours.
lcamtuf always sent us succinct test cases. Never patches.
I can't stress how quickly this will turn me from "it's a good library" to "it's an amazing library". (Or prevent me from tacking on, "but it's kinda abandoned".) I've never sent patches SQLite's way, but I've sent patches to other open source projects, and whole quarters go by with nary a peep. This is not only frustrating, but often it feels like it pushes more work onto me than just accepting an even potentially buggy patch would cause. If I'm sending a patch, there's a good chance I'm using it myself, and thus your library has become a special-cased wart in my deployment process that I'd very much like to kill. (E.g., since I work in Python: I can't `pip install package==version` anymore; it needs to be on Github or something; thankfully pip makes this fairly easy; patches to things that some other package has decided to bundle rather than just use the package-manager approved version of are especially painful.)
While I'm not sure I'd go this far, the lament reminds me of http://felixge.de/2013/03/11/the-pull-request-hack.html