484 lines
20 KiB
HTML
484 lines
20 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;
|
|
}
|
|
</script>
|
|
</div>
|
|
<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="#test_harness_3_private_extensions">5.3.5. Test Harness #3 Private Extensions</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>
|
|
|
|
|
|
|
|
<center>
|
|
<font color="red" size="5"><b>
|
|
This document is a work-in-progress. It is incomplete and unverified.
|
|
</b></font>
|
|
</center>
|
|
|
|
<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 a open-source software project such
|
|
as SQLite.
|
|
|
|
</p><p>
|
|
The purpose of this document is to brief the reader on how
|
|
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/checklists">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. Patch are distinct
|
|
from maintenance releases in that the number of lines of code changed
|
|
from the previous release is very 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> 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 summary
|
|
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 uncountable clones scattered about the internet.
|
|
|
|
</p><h2 id="repositories"><span>5.3. </span>Repositories</h2>
|
|
|
|
<p>The SQLite code 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 passers by 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/src">https://www3.sqlite.org/src</a>
|
|
</li></ul>
|
|
|
|
<p>There is an unofficial and unsanctioned Git clone of this repository
|
|
at <a href="https://github.com/mackyle/sqlite">https://github.com/mackyle/sqlite</a>.
|
|
|
|
</p><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 extract 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 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/docsrc">https://www3.sqlite.org/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://www2.sqlite.org/th3">https://www2.sqlite.org/th3</a>
|
|
</li><li> Backup B: <a href="https://www3.sqlite.org/th3">https://www3.sqlite.org/th3</a>
|
|
</li></ul>
|
|
|
|
<h3 id="test_harness_3_private_extensions"><span>5.3.5. </span>Test Harness #3 Private Extensions</h3>
|
|
|
|
<p>
|
|
At one point, <a href="th3.html">TH3</a> was sometimes licensed to third-parties.
|
|
Such licensing no longer occurs. However, back when it was
|
|
occurring, some of the TH3 test cases contained information that
|
|
was sensitive and could not be released even to licensees. This
|
|
sensitive information is stored in yet another repository.
|
|
|
|
</p><ul>
|
|
<li> Primary location: <a href="https://www.sqlite.org/th3private">https://www.sqlite.org/th3private</a>
|
|
</li><li> 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><i>TBD...</i>
|
|
|
|
</p><h1 id="software_design_and_coding_standards"><span>7. </span>Software Design And Coding Standards</h1>
|
|
|
|
<p><i>TBD...</i>
|
|
|
|
</p><h1 id="problem_reports"><span>8. </span>Problem Reports</h1>
|
|
|
|
<p><i>TBD...</i>
|
|
</p>
|