Adding upstream version 3.45.1.upstream/3.45.1

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
author: Daniel Baumann <daniel.baumann@progress-linux.org> 2024-04-13 14:07:11 +0000
committer: Daniel Baumann <daniel.baumann@progress-linux.org> 2024-04-13 14:07:11 +0000
commit: 63847496f14c813a5d80efd5b7de0f1294ffe1e3 (patch)
tree: 01c7571c7c762ceee70638549a99834fdd7c411b /www/qmplan.html
parent: Initial commit. (diff)
download: sqlite3-63847496f14c813a5d80efd5b7de0f1294ffe1e3.tar.xz
sqlite3-63847496f14c813a5d80efd5b7de0f1294ffe1e3.zip
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">&#x25ba;</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 = "&#x25bc;";
+} else {
+sub.style.display = "none";
+mk.innerHTML = "&#x25ba;";
+}
+}
+</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>
+
author	Daniel Baumann <daniel.baumann@progress-linux.org>	2024-04-13 14:07:11 +0000
committer	Daniel Baumann <daniel.baumann@progress-linux.org>	2024-04-13 14:07:11 +0000
commit	63847496f14c813a5d80efd5b7de0f1294ffe1e3 (patch)
tree	01c7571c7c762ceee70638549a99834fdd7c411b /www/qmplan.html
parent	Initial commit. (diff)
download	sqlite3-63847496f14c813a5d80efd5b7de0f1294ffe1e3.tar.xz sqlite3-63847496f14c813a5d80efd5b7de0f1294ffe1e3.zip