How to submit changes
(1) By Shaun Case (shaunc) on 2021-07-22 08:33:15 [link] [source]
Hi, I'd like to submit a change to sqlite consisting of spelling corrections I found and fixed with an open source tool called CodeSpell, but I can't figure out how to submit my commit to the maintainers. I built fossil from source, cloned and built the sqlite project from source as outlined at https://www.sqlite.org/src/dir?ci=trunk I made my changes on the trunk, rebuilt, ran make tests (which succeeded through session3.test; session4.test doesn't run because it requires Tcl devel 8.6 which isn't available for the CentOS 7.9 distro I'm using). I committed to my local repo I created a forum account (shaunc) on sqlite.org, and did ~/sqlite$ fossil remote-url -R ~/Fossils/sqlite.fossil https://email@example.com/src password for shaunc: remember password (Y/n)? y ~/sqlite$ fossil push Push to https://firstname.lastname@example.org/src Round-trips: 1 Artifacts sent: 0 received: 0 Error: login failed Round-trips: 1 Artifacts sent: 0 received: 0 Push done, wire bytes sent: 7539 received: 208 ip: 188.8.131.52 So, login failed doing a fossil push, and my forum credentials don't work for logging in to https://sqlite.org/src/login. I gather that I either need to have a different account for push access, or some additional permissions, or do something completely different. I hunted around on sqlite.org and StackOverflow and the official sqlite mirror on github for a how-to-submit-changes/contributing guide, but I didn't find one. How do I go about submitting my changes? Do I need to email someone a diff, or set up a github mirror and put the work there, or... ? Thanks for any guidance. If there is a howto document I missed, I'd be happy to be pointed at that too. Best, Shaun
(2.1) By Harald Hanche-Olsen (hanche) on 2021-07-22 13:01:18 edited from 2.0 in reply to 1 [link] [source]
Look at https://sqlite.org/copyright.html for some pointers
If it's about spelling mistakes in the documentation, I imagine they are not so strict about not accepting patches. Perhaps you could simply post a diff to the forum, if it is not too large.
(5) By Shaun Case (shaunc) on 2021-07-22 18:40:46 in reply to 2.1 [link] [source]
Thank you Harald, David, Larry. That copyright page clarifies everything, and is exactly the information I was looking for. I guess I'm used to looking for a "Contributing" page or markdown file, and I couldn't find anything even with searches on the sqlite.org.
Anyway, the policy makes perfect sense, given the goals of the project.
The patch is rather long, even though I didn't fix all the misspellings, so I'll create a public gist containing the patch and the commands I used to find and fix the errors with CodeSpell so the patch can be recreated from scratch if desired. I'll put the whole gist into the public domain.
The maintainers are welcome to ignore it or use it as they see fit.
(7) By Larry Brasfield (larrybr) on 2021-07-22 19:02:45 in reply to 5 [link] [source]
Shaun, I think that a per-file list of misspelled words, as misspelled, would be simplest. (In essence, a denormalized table.) I hope to not strain credulity by stating: Typos and abnormal spellings do get fixed in the normal course of work on the sources. Not reliably at first opportunity, but when noticed.
I'll see about getting a link-landing into the copyright page so that "Contributing" shows up in the site keyword index.
(3) By David Raymond (dvdraymond) on 2021-07-22 13:01:58 in reply to 1 [link] [source]
If I understand you correctly, you're saying you tried to commit your own code to the master SQLite repository?
SQLite is open source, but not open-contribute. You can suggest changes here in the forums for example, but only the select few actual members of the team can commit code.
If it's "just" spelling issues (in the code and not the docs) then don't fret if they say no. I remember someone submitted a thing to remove all the trailing white space for example, and the decision was that was going to explode and cause noise in deltas with no actual benefit to the binaries. So someone looking for what changed from version A to B would see 1,000 lines of code changed... but none of those code changes would actually effect how anything worked.
(4) By Larry Brasfield (larrybr) on 2021-07-22 14:22:57 in reply to 1 [link] [source]
As David replied, and as you gather, you would need check-in privilege on the source repo to push such changes.
I do not think small spelling fixups would be welcome en masse. The developers like to avoid churn in the change history and timelines that distracts from the "meaningful" history.
However, codespell appears to be a great tool, and it is conveniently available on Ubuntu. For source files about to see substantial change anyway, or new ones, it will or may be used, depending on exigencies at the time. Thanks for the tip.
You may have noticed a marker, CAPI3REF, in the sqlite.h.in file. Comments so marked end up in the documentation. Spelling corrections are very welcome and normally taken for the documentation. I see now, using codespell, that there are several spelling improvements possible there which I will fold into the next change made for substantive reasons.
(6) By Shaun Case (shaunc) on 2021-07-22 18:53:51 in reply to 4 [source]
@larrybr, and whoever else is interested, here is the gist containing the spelling/typo fix patch and info about using CodeSpell to find and make the changes: