diff options
Diffstat (limited to 'www/qmplan.html')
| -rw-r--r-- | www/qmplan.html | 564 |
1 files changed, 564 insertions, 0 deletions
diff --git a/www/qmplan.html b/www/qmplan.html new file mode 100644 index 0000000..9c03c7b --- /dev/null +++ b/www/qmplan.html @@ -0,0 +1,564 @@ +<!DOCTYPE html> +<html><head> +<meta name="viewport" content="width=device-width, initial-scale=1.0"> +<meta http-equiv="content-type" content="text/html; charset=UTF-8"> +<link href="sqlite.css" rel="stylesheet"> +<title>Quality Management</title> +<!-- path= --> +</head> +<body> +<div class=nosearch> +<a href="index.html"> +<img class="logo" src="images/sqlite370_banner.gif" alt="SQLite" border="0"> +</a> +<div><!-- IE hack to prevent disappearing logo --></div> +<div class="tagline desktoponly"> +Small. Fast. Reliable.<br>Choose any three. +</div> +<div class="menu mainmenu"> +<ul> +<li><a href="index.html">Home</a> +<li class='mobileonly'><a href="javascript:void(0)" onclick='toggle_div("submenu")'>Menu</a> +<li class='wideonly'><a href='about.html'>About</a> +<li class='desktoponly'><a href="docs.html">Documentation</a> +<li class='desktoponly'><a href="download.html">Download</a> +<li class='wideonly'><a href='copyright.html'>License</a> +<li class='desktoponly'><a href="support.html">Support</a> +<li class='desktoponly'><a href="prosupport.html">Purchase</a> +<li class='search' id='search_menubutton'> +<a href="javascript:void(0)" onclick='toggle_search()'>Search</a> +</ul> +</div> +<div class="menu submenu" id="submenu"> +<ul> +<li><a href='about.html'>About</a> +<li><a href='docs.html'>Documentation</a> +<li><a href='download.html'>Download</a> +<li><a href='support.html'>Support</a> +<li><a href='prosupport.html'>Purchase</a> +</ul> +</div> +<div class="searchmenu" id="searchmenu"> +<form method="GET" action="search"> +<select name="s" id="searchtype"> +<option value="d">Search Documentation</option> +<option value="c">Search Changelog</option> +</select> +<input type="text" name="q" id="searchbox" value=""> +<input type="submit" value="Go"> +</form> +</div> +</div> +<script> +function toggle_div(nm) { +var w = document.getElementById(nm); +if( w.style.display=="block" ){ +w.style.display = "none"; +}else{ +w.style.display = "block"; +} +} +function toggle_search() { +var w = document.getElementById("searchmenu"); +if( w.style.display=="block" ){ +w.style.display = "none"; +} else { +w.style.display = "block"; +setTimeout(function(){ +document.getElementById("searchbox").focus() +}, 30); +} +} +function div_off(nm){document.getElementById(nm).style.display="none";} +window.onbeforeunload = function(e){div_off("submenu");} +/* Disable the Search feature if we are not operating from CGI, since */ +/* Search is accomplished using CGI and will not work without it. */ +if( !location.origin || !location.origin.match || !location.origin.match(/http/) ){ +document.getElementById("search_menubutton").style.display = "none"; +} +/* Used by the Hide/Show button beside syntax diagrams, to toggle the */ +function hideorshow(btn,obj){ +var x = document.getElementById(obj); +var b = document.getElementById(btn); +if( x.style.display!='none' ){ +x.style.display = 'none'; +b.innerHTML='show'; +}else{ +x.style.display = ''; +b.innerHTML='hide'; +} +return false; +} +var antiRobot = 0; +function antiRobotGo(){ +if( antiRobot!=3 ) return; +antiRobot = 7; +var j = document.getElementById("mtimelink"); +if(j && j.hasAttribute("data-href")) j.href=j.getAttribute("data-href"); +} +function antiRobotDefense(){ +document.body.onmousedown=function(){ +antiRobot |= 2; +antiRobotGo(); +document.body.onmousedown=null; +} +document.body.onmousemove=function(){ +antiRobot |= 2; +antiRobotGo(); +document.body.onmousemove=null; +} +setTimeout(function(){ +antiRobot |= 1; +antiRobotGo(); +}, 100) +antiRobotGo(); +} +antiRobotDefense(); +</script> +<div class=fancy> +<div class=nosearch> +<div class="fancy_title"> +Quality Management +</div> +<div class="fancy_toc"> +<a onclick="toggle_toc()"> +<span class="fancy_toc_mark" id="toc_mk">►</span> +Table Of Contents +</a> +<div id="toc_sub"><div class="fancy-toc1"><a href="#overview">1. Overview</a></div> +<div class="fancy-toc2"><a href="#about_this_document">1.1. About This Document</a></div> +<div class="fancy-toc1"><a href="#software_development_plan">2. Software Development Plan</a></div> +<div class="fancy-toc2"><a href="#software_life_cycle">2.1. Software Life Cycle</a></div> +<div class="fancy-toc3"><a href="#maintenance_releases">2.1.1. Maintenance Releases</a></div> +<div class="fancy-toc3"><a href="#patch_releases">2.1.2. Patch Releases</a></div> +<div class="fancy-toc2"><a href="#release_history">2.2. Release History</a></div> +<div class="fancy-toc2"><a href="#schedule">2.3. Schedule</a></div> +<div class="fancy-toc1"><a href="#software_development_environment">3. Software Development Environment</a></div> +<div class="fancy-toc1"><a href="#software_verification_plan">4. Software Verification Plan</a></div> +<div class="fancy-toc1"><a href="#software_configuration_management">5. Software Configuration Management</a></div> +<div class="fancy-toc2"><a href="#version_control">5.1. Version Control</a></div> +<div class="fancy-toc2"><a href="#survivability">5.2. Survivability</a></div> +<div class="fancy-toc2"><a href="#repositories">5.3. Repositories</a></div> +<div class="fancy-toc3"><a href="#sqlite_source_code">5.3.1. SQLite Source Code</a></div> +<div class="fancy-toc3"><a href="#sqlite_documentation_sources">5.3.2. SQLite Documentation Sources</a></div> +<div class="fancy-toc3"><a href="#sql_logic_test">5.3.3. SQL Logic Test</a></div> +<div class="fancy-toc3"><a href="#test_harness_3">5.3.4. Test Harness #3</a></div> +<div class="fancy-toc3"><a href="#dbsqlfuzz">5.3.5. Dbsqlfuzz</a></div> +<div class="fancy-toc2"><a href="#software_verification_results">5.4. Software Verification Results</a></div> +<div class="fancy-toc1"><a href="#software_requirements_standards_and_data">6. Software Requirements Standards And Data</a></div> +<div class="fancy-toc1"><a href="#software_design_and_coding_standards">7. Software Design And Coding Standards</a></div> +<div class="fancy-toc1"><a href="#problem_reports">8. Problem Reports</a></div> +</div> +</div> +<script> +function toggle_toc(){ +var sub = document.getElementById("toc_sub") +var mk = document.getElementById("toc_mk") +if( sub.style.display!="block" ){ +sub.style.display = "block"; +mk.innerHTML = "▼"; +} else { +sub.style.display = "none"; +mk.innerHTML = "►"; +} +} +</script> +</div> + + + +<h1 id="overview"><span>1. </span>Overview</h1> + +<p> +This is the Quality Management Plan for SQLite. + +</p><p> +Quality management documents tend to expand into +binders full of incomprehensible jargon that nobody +reads. This document strives to break that pattern by +being concise and useful. + +</p><p> +The inspiration for this document is +<a href="https://en.wikipedia.org/wiki/DO-178B">DO-178B</a>. +Among quality standards, DO-178B seems to have the highest usefulness +to paperwork ratio. Even so, the amount of documentation needed +for a full-up DO-178B implementation is vast. SQLite strives to be +nimble and low-ceremony, and to that end, much of the required +DO-178B documentation is omitted. We retain only those parts that +genuinely improve quality for an open-source software project such +as SQLite. + +</p><p> +The purpose of this document is to brief the reader on how the +SQLite development team functions on a daily basis, as they continuously +enhance the SQLite software and work to improve its already high reliability. +The document achieves its purpose if a competent developer can be +assimilated into the development team quickly after perusing this +document. + +</p><h2 id="about_this_document"><span>1.1. </span>About This Document</h2> + +<p> +The quality management plan was originally composed by going through +the description of outputs in section 11 of DO-178B (pages 48 through 56) +and writing down those elements that seemed relevant to SQLite. +The text will be subsequent revised to track enhancements to the +SQLite quality process. + +</p><h1 id="software_development_plan"><span>2. </span>Software Development Plan</h1> + +<p> +This section is a combination of the Plan For Software Aspects Of +Certification and the Software Development Plan sections of DO-178B. + + +</p><p> +See <a href="about.html">About SQLite</a> for an overview of the +SQLite software and what it does and how it is different. + +</p><h2 id="software_life_cycle"><span>2.1. </span>Software Life Cycle</h2> + +<p> +SQLite uses a continuous integration process. The software +is under constant enhancement and refinement. The latest trunk +check-ins are frequently used internally for mission-critical +operations. + +</p><p> +There is no pre-defined release cycle. Releases occur +when there is a critical mass of feature enhancements and/or +bug fixes. Historically, releases have occurred about 5 or 6 +times per year. +Users of SQLite pick up new releases from the website on an +as-needed basis. + +</p><h3 id="maintenance_releases"><span>2.1.1. </span>Maintenance Releases</h3> + +<p> +Routine maintenance releases of SQLite contain feature enhancements, +performance enhancements, and/or fixes for non-critical issues. +The version number for major releases are of the form "3.N.0" +for some integer N. See the <a href="versionnumbers.html">version numbering conventions</a> document +for details. + +</p><p> +Upcoming maintenance releases announced on the sqlite-users and +sqlite-dev <a href="support.html#mailinglists">mailing lists</a> about two weeks prior to the anticipated +release. Approximately one week prior to release, the lead developer +declares "pencils down" after which only bug-fix check-ins are +allowed on trunk. A new +<a href="https://sqlite.org/src/ext/checklist/top/index">release checklist</a> +is created and updated as needed. As items of the checklist are +verified, they are checked off and turn green. The release occurs +when all elements of the checklist are green. That process normally +takes about a week. + +</p><h3 id="patch_releases"><span>2.1.2. </span>Patch Releases</h3> + +<p> +Occasionally, a serious problem is found and a small "patch" release +must be made against a regular maintenance release. Patches are distinct +from maintenance releases in that the number of lines of code changed +from the previous release is small. Every effort is made to avoid +patch releases by making sure that maintenance releases are bug free. + +</p><p> +Patch releases may or may not have a release checklist, depending on the +issue. This is a judgement call by the project leader. + +</p><h2 id="release_history"><span>2.2. </span>Release History</h2> + +<p>The documentation system automatically maintains a +<a href="chronology.html">chronology</a> of past releases, as well as a +<a href="changes.html">complete list of SQLite releases</a> with change summaries. + +</p><h2 id="schedule"><span>2.3. </span>Schedule</h2> + +<p>SQLite has a long-range vision. +Planning is done with the assumption that SQLite +will be used and supported through at least the year 2050. +All code is written with the idea that it will one day be read and +maintained by people not yet born. The code is carefully commented +with an eye toward helping those future developers more easily +understand the logic and the rationale behind the code. + +</p><h1 id="software_development_environment"><span>3. </span>Software Development Environment</h1> + +<p> +SQLite is written in portable C code. +Development work occurs on a mix of Linux, Mac, and Windows workstations. +The developers use command-line tools and eschew integrated development +environments (IDEs) whenever possible. All developers are expected to be +fluent with the unix command-line. + +</p><p> +A minimum setup for compiling and testing SQLite from canonical +sources is as follows: + +</p><ul> +<li> A host computer with a 32-bit or 64-bit address space. + The OS can be Linux, Mac, Windows, *BSD, Solaris, or some other. +</li><li> A C99 compiler such as GCC (including MinGW variants for Windows), + Clang, or MSVC +</li><li> A text editor of the user's choice supporting UTF-8 text. +</li><li> <a href="https://core.tcl.tk/">Tcl</a> version 8.6 or later. +</li><li> The "make" utility, or optionally "nmake" on Windows. +</li></ul> + +<p> +The Tcl script language is used to help translate canonical source code +into the <a href="amalgamation.html">amalgamation</a> and to manage testing. Tcl is not used directly +by SQLite itself (unless requested by a compile-time option). End users +of the SQLite amalgamation sources do not need Tcl. + +</p><p> +When building the <a href="cli.html">CLI</a>, it is helpful, but not required, to have +the following third-party libraries on hand: + +</p><ul> +<li> <a href="https://zlib.net/">zLib</a> +</li><li> <a href="http://git.savannah.gnu.org/cgit/readline.git?h=devel">readline</a> + or <a href="http://thrysoee.dk/editline/">editline</a> + or <a href="https://github.com/antirez/linenoise">linenoise</a> for + command-line editing. +</li></ul> + +<p> +A complete release-test of SQLite requires additional software, + +</p><ul> +<li> <a href="http://www.valgrind.org/">valgrind</a> +</li><li> <a href="https://gcc.gnu.org/onlinedocs/gcc/Gcov.html">gcov</a> +</li></ul> + +<p> +SQLite is expected to operate the same, and use exactly the same +<a href="fileformat2.html">on-disk format</a>, +on all modern operating systems, on all modern computer architectures, +and using all modern C compilers. The developers are constantly testing +SQLite on as many diverse platforms as they can get their hands on. + +</p><h1 id="software_verification_plan"><span>4. </span>Software Verification Plan</h1> + +<p>The testing process for SQLite is described in the <a href="testing.html">testing</a> document. +Testing objectives include: + +</p><ul> +<li> 100% MC/DC in an as-delivered configuration +</li><li> Testing of both source code and object code +</li><li> Testing on multiple platforms and with multiple compilers +</li><li> Fuzz testing +</li><li> Code change inspection +</li><li> Dynamic and static analysis of the code +</li></ul> + +<p>The testing process is controlled by the +<a href="testing.html#cklist">release testing checklists</a>. The checklists succinctly summarize +all steps necessary to fully validate SQLite, and they record when +and by whom each validation step was performed. + +</p><p>The set of checklist items for release checklist is potentially +updated for each release. The content and complete +history of each release checklist are retained for the historical +record. + +</p><h1 id="software_configuration_management"><span>5. </span>Software Configuration Management</h1> + +<h2 id="version_control"><span>5.1. </span>Version Control</h2> + +<p> +SQLite source code is managed using the <a href="https://fossil-scm.org">Fossil</a> +version control system. Fossil was written specifically to support +SQLite development. Fossil provides both distributed version control +and issue tracking. + +</p><h2 id="survivability"><span>5.2. </span>Survivability</h2> + +<p> +All code is archived on three separate machines: +<a href="https://www.sqlite.org">https://www.sqlite.org</a>, <a href="https://www2.sqlite.org">https://www2.sqlite.org</a>, <a href="https://www3.sqlite.org">https://www3.sqlite.org</a>. +These machines are located in different cities (Dallas, Newark, and +San Francisco, respectively) and managed by two different hosting +companies (<a href="https://linode.com">Linode</a> for the first two and +<a href="https://digitalocean.com">Digital Ocean</a> for the third). +This diversity is intended to avoid a single point of failure. + +</p><p> +The main machine in Dallas <a href="https://www.sqlite.org/">https://www.sqlite.org/</a> is the primary +server and the one that most people use. The other two are considered +backups. + +</p><p> +In addition to the official repositories, the developers typically +keep complete clones of all software on their personal machines. +And there are other clones scattered about the internet. + +</p><h2 id="repositories"><span>5.3. </span>Repositories</h2> + +<p>The SQLite source is broken up into multiple repositories, each described +in a separate section below. + +</p><h3 id="sqlite_source_code"><span>5.3.1. </span>SQLite Source Code</h3> + +<p>The SQLite source code and the <a href="testing.html#tcl">TCL test suite</a> are stored together +in a single repository. This one repository is all that is required to +build the SQLite. The source repository is public and is +readable by anonymous passersby on the internet. + +</p><ul> +<li> Primary location: <a href="https://www.sqlite.org/src">https://www.sqlite.org/src</a> +</li><li> Backup A: <a href="https://www2.sqlite.org/src">https://www2.sqlite.org/src</a> +</li><li> Backup B: <a href="https://www3.sqlite.org/cgi/src">https://www3.sqlite.org/cgi/src</a> +</li><li> GitHub mirror: <a href="https://github.com/sqlite/sqlite/">https://github.com/sqlite/sqlite/</a> +</li></ul> + +<h3 id="sqlite_documentation_sources"><span>5.3.2. </span>SQLite Documentation Sources</h3> + +<p>The documentation sources include documentation text and images with the +scripts and makefile needed to construct the SQLite website documentation. +This document is contained within the documentation sources. The +document sources are kept in a separate repository distinct from the +source code. The documentation sources repository is publicly readable. + +</p><p>The makefiles and scripts used to generate the documentation gather +text from baseline documents in the documentation source repository. +Additional text is extracted from comments in the SQLite source code. +Requirements coverage information is extracted from special comments in the +<a href="testing.html#tcl">TCL test suite</a> which is part of the source repository, and from +comments in the <a href="th3.html">TH3</a> test suite which is in a separate private repository. + +</p><ul> +<li> Primary location: <a href="https://www.sqlite.org/docsrc">https://www.sqlite.org/docsrc</a> +</li><li> Backup A: <a href="https://www2.sqlite.org/docsrc">https://www2.sqlite.org/docsrc</a> +</li><li> Backup B: <a href="https://www3.sqlite.org/cgi/docsrc">https://www3.sqlite.org/cgi/docsrc</a> +</li></ul> + +<h3 id="sql_logic_test"><span>5.3.3. </span>SQL Logic Test</h3> + +<p> +The <a href="testing.html#slt">SQL Logic Tests</a> are a set of test cases designed to show that +SQLite behaves the same as other SQL database engines. These tests +are hosted in a separate code public repository. + +</p><ul> +<li> Primary location: <a href="https://www.sqlite.org/sqllogictest">https://www.sqlite.org/sqllogictest</a> +</li><li> Backups on private servers +</li></ul> + +<h3 id="test_harness_3"><span>5.3.4. </span>Test Harness #3</h3> + +<p> +The <a href="th3.html">Test Harness #3</a> or <a href="th3.html">TH3</a> test suite is a private set of +test cases used to test SQLite to 100% MC/DC in an as-delivered +configuration. TH3 sources are served on the same servers as the +other SQLite repositories, but differ from the others in being +proprietary. The TH3 code is only accessible to SQLite developers. + + +</p><ul> +<li> Primary location: <a href="https://www.sqlite.org/th3">https://www.sqlite.org/th3</a> +</li><li> Backup A: <a href="https://www3.sqlite.org/cgi/th3">https://www3.sqlite.org/cgi/th3</a> +</li><li> Additional backups on private servers +</li></ul> + +<h3 id="dbsqlfuzz"><span>5.3.5. </span>Dbsqlfuzz</h3> + +<p> +The dbsqlfuzz module is a +<a href="https://www.llvm.org/docs/LibFuzzer.html">libFuzzer</a>-based fuzzer +for SQLite. Dbsqlfuzz fuzzes both the SQL and the database file at +the same time. Dbsqlfuzz uses a customized mutator. + +</p><p> +Dbsqlfuzz seems to work better at finding problems than any other +fuzzer available. For that reason, it is kept private. We do not +want hacker gaining access to this technology. + +</p><ul> +<li> Primary location: <a href="https://www.sqlite.org/dbsqlfuzz">https://www.sqlite.org/dbsqlfuzz</a> +</li><li> Backup A: <a href="https://www3.sqlite.org/cgi/dbsqlfuzz">https://www3.sqlite.org/cgi/dbsqlfuzz</a> +</li><li> Additional backups on private servers +</li></ul> + +<h2 id="software_verification_results"><span>5.4. </span>Software Verification Results</h2> + +<p> +Release testing proceeds by <a href="testing.html#cklist">checklist</a>. The current status and +complete change history for each checklist is stored in a separate +SQLite database file. These files are not version controlled, but +separate copies are maintained on private backup servers. + +</p><p>The source code to the software that runs the checklists is stored +in its own Fossil repository at <a href="https://www.sqlite.org/checklistapp">https://www.sqlite.org/checklistapp</a>. + +</p><h1 id="software_requirements_standards_and_data"><span>6. </span>Software Requirements Standards And Data</h1> + +<p>In the SQLite project, the "requirements" are the project documentation. +Special markup in the documentation text indentifies individual requirements. +The requirement numbers are based on a cryptographic hash of normalized +requirement text, so that it is impossible to change the requirement text +without also changing the requirement number. + +</p><p>Documentation text (and hence requirement text) is taken from the +SQLite Documentation source repository, described above, and also from +comments in the implementation. The makefiles to build the documentation +are in the documentation source repository. + +</p><p>When the documentation is build, requirements are identified and labeled. +The documentation build process also scans for test cases that verify +each requirement and constructs a matrix showing which requirements have +been testing and identifying the specific test cases that test those +requirements. + +</p><h1 id="software_design_and_coding_standards"><span>7. </span>Software Design And Coding Standards</h1> + +<p>Objective coding standards for SQLite are minimal: + +</p><ul> +<li> 2-space indentation +</li><li> No lines over 80 characters in length +</li><li> No tabs +</li></ul> + +<p>All other design and coding rules are subjective. The +goal here is to make the software so that it is readable +and maintainable through the year 2050. To that end, we look +for succinct yet useful comments (no boilerplate), carefully +chosen variable names, and careful explanation of the meaning +of each data structure and the role of each code block. + +</p><h1 id="problem_reports"><span>8. </span>Problem Reports</h1> + +<p>All problems are fixed expeditiously. There are no lingering problems +in the sQLite software. + +</p><p>The <a href="https://fossil-scm.org/">Fossil version control system</a> utilized by +SQLite contains built-in support for tracking trouble-tickets. This built-in +ticket system is used to track and document many historical problems. + +</p><p>The <a href="https://fossil-scm.org/forum">SQLite Community Forum</a> is a place +where anybody on the internet can go to ask questions about or report bugs +against SQLite. Bugs found by third-parties are often reported initially +on the Forum. Forum-reported bugs will sometimes be transferred to tickets, +though recent practice as been to just deal with the bugs on the Forum. +The Forum has an excellent full-text search feature, is mirrored to +multiple machines, and is just as searchable and survivable as the ticket +system, so it seems unnecessary to duplicate Forum-originated bug reports +into the ticket system. The public locations of the Forum are: + +</p><ul> +<li> Primary location: <a href="https://www.sqlite.org/forum">https://www.sqlite.org/forum</a> +</li><li> Backup A: <a href="https://www2.sqlite.org/forum">https://www2.sqlite.org/forum</a> +</li><li> Backup B: <a href="https://www3.sqlite.org/cgi/forum">https://www3.sqlite.org/cgi/forum</a> +</li></ul> + +<p> +As with the source repositories, the Forum is also synced to various +private machines. +Note that because of the way Fossil works, the "backups" are more than just +read-only backups. They can also function as data inputs. All content +entered is synced to all repositories, regardless of which repository is +used for insertion. +</p><p align="center"><small><i>This page last modified on <a href="https://sqlite.org/docsrc/honeypot" id="mtimelink" data-href="https://sqlite.org/docsrc/finfo/pages/qmplan.in?m=601675a989">2022-04-18 02:55:50</a> UTC </small></i></p> + |