565 lines
23 KiB
HTML
565 lines
23 KiB
HTML
|
<!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>
|
||
|
|
|