remove obsolete directory www. Was leftover from when SVN was hosted on tigris.org. This directory affected some project pages on tigris.org

author: William Deegan <bill@baddogconsulting.com> 2018-04-30 14:11:01 (GMT)
committer: William Deegan <bill@baddogconsulting.com> 2018-04-30 14:11:01 (GMT)
commit: df92a34720a8511f63a12abcd7e0ca2deeeca4d1 (patch)
tree: 30fba26bf120287bc6f5990efb77881de7bcf95b
parent: aebcf66c646c071cb40832c8b721ac13ad70fa75 (diff)
download: SCons-df92a34720a8511f63a12abcd7e0ca2deeeca4d1.zip
SCons-df92a34720a8511f63a12abcd7e0ca2deeeca4d1.tar.gz
SCons-df92a34720a8511f63a12abcd7e0ca2deeeca4d1.tar.bz2
16 files changed, 0 insertions, 1445 deletions
diff --git a/www/bug-submission.html b/www/bug-submission.html
deleted file mode 100644
index abc855b..0000000
--- a/www/bug-submission.html
+++ /dev/null
@@ -1,234 +0,0 @@
-<html>
-<head>
-<title>Bug Submission</title>
-</head>
-<body>
-
-<div id="apphead">
-<h1><small>scons</small><br />Bug Submission</h1>
-
-<p>
-<strong>You must now
-<a href="http://www.tigris.org/servlets/Login">log in</a>
-to a <a href="http://www.tigris.org">tigris.org</a> account
-before submitting a new bug report!</strong>
-</p>
-
-<p>
-Bugs should be reported at the
-<a href="http://scons.tigris.org/issues/enter_bug.cgi?component=scons&subcomponent=scons&issue_type=DEFECT">"Enter Issue" page</a>.
-Please follow the <a href="bug-submission.html#guidelines">submission guidelines</a> below
-to make sure your bug report contains the necessary information.
-A more detailed set of <a href="bug-submission.html#steps">submission steps</a>
-can be found below.
-</p>
-
-<p>
-The above URL is set up for reporting a bug in SCons itself.
-If you are reporting a problem in some other aspect of the SCons Project
-(such as the documentation, or any of the web pages),
-you must change the Subcomponent field of the submission form
-to some other appropriate value.
-</p>
-
-</div>
-
-<div class="h2 app" style="border-left: 0px" id="customcontent">
-
-<h2 id="guidelines">Guidelines for a Useful Bug Report</h2>
-
-<p>
-Your bug will be much more likely to get diagnosed and fixed
-if you supply all the necessary information to make it easy to do so.
-</p>
-
-<ul>
-<li>
-<strong>
-<a href="http://www.tigris.org/servlets/Login">Log in</a>
-to your tigris.org account before submitting a bug report
-</strong>
-<p>
-If you do not already have a tigris.org account,
-register for one at
-<a href="http://www.tigris.org/servlets/Join">http://www.tigris.org/servlets/Join</a>.
-</p>
-<p>
-We no longer accept anonymous bug reports,
-due to spambot abuse of the open-door policy.
-</p>
-</li>
-<li>
-<strong>Specify the version of SCons in which you observed the problem</strong>
-<p>
-This helps avoid wasted time trying to pinpoint the version,
-and also allows us to confirm if a later released version
-has already fixed your problem.
-</p>
-</li>
-<li>
-<strong>Provide SConscript files or other configuration that reproduce the problem</strong>
-<p>
-If you can, simplify the configuration to just the
-minimal subset that demonstrates the problem.
-It's much harder to diagnose a problem
-if the incorrect behavor is due to
-one particular item out of a thousand
-in a large configuration.
-</p>
-<p>
-That said, it's most convenient if you can provide
-an actual configuration (set of SConscript files
-and/or other input files)
-that can be downloaded and run to demonstrate the bug.
-The easiest way is to attach a .tar.gz or .zip file
-to the bug report.
-Note that the tigris.org Issue Tracker
-doesn't let you attach a file like this
-when you initially submit the report.
-You must first create the bug report,
-and then attach a file to it as a separate step.
-See below for the detailed steps.
-</p>
-<p>
-If your problem is evident from a few specific SConscript lines,
-it's perfectly acceptable just to
-paste the lines into the Description field of the bug report.
-</p>
-</li>
-<li>
-<strong>Describe specifically the incorrect behavor you observed</strong>
-<p>
-It's best if you can cut and paste the output from SCons,
-especially any error messages.
-Otherwise,
-Vague descriptions like,
-"SCons errors out," or "Product XYZ doesn't compile"
-are extremely difficult to diagnose,
-because the different installed tools on someone else's system
-may cause SCons to behave differently
-and not demonstrate your bug.
-</p>
-</li>
-<li>
-<strong>Describe what you expected to happen</strong>
-<p>
-This isn't always obvious, especially if the
-bug does not involve an SCons failure or error message.
-Describing the behavior you expected
-helps speed up the diagnosis.
-</p>
-</li>
-</ul>
-
-<h2 id="steps">Steps for Submitting a Bug Report</h2>
-
-<p>
-The following guides you step-by-step through the
-process of submitting a new SCons bug report.
-</p>
-
-<p>
-NOTE:  Creating a bug report with an attached file or files
-(such as a .tar.gz or .zip file containing a sample configuration)
-is a two-step process in the tigris.org Issue Tracker.
-You must first create the bug report,
-and then attach the file(s) in a separate step,
-as described below.
-</p>
-
-<ul>
-<li>
-<strong><a href="http://www.tigris.org/servlets/Login">Log in</a> at tigris.org</strong>
-<p>
-If you do not already have a tigris.org account,
-register for one at
-<a href="http://www.tigris.org/servlets/Join">http://www.tigris.org/servlets/Join</a>.
-</p>
-<p>
-We no longer accept anonymous bug reports,
-due to spambot abuse of the open-door policy.
-</p>
-</li>
-<li>
-<strong>Go to the
-<a href="http://scons.tigris.org/issues/enter_bug.cgi?component=scons&subcomponent=scons&issue_type=DEFECT">"Enter issue" page</a>
-</strong>
-<p>
-By default, the "scons" subcomponent is selected;
-if this bug is for a different subcomponent, select that instead.
-</p>
-</li>
-<li>
-<strong>Specify the version of SCons in which you found the bug</strong>
-<p>
-</p>
-</li>
-<li>
-<strong>Specify the Subcomponent (if the bug is not in SCons itself)</strong>
-<p>
-The URL two steps above assumes that you're reporting
-a bug in the behavior of SCons itself.
-If you're reporting a problem in some other aspect of the SCons Project
-(such as the documentation, or the packaging),
-please change the Subcomponent field to reflect that.
-</p>
-</li>
-<li>
-<strong>Specify the Platform and OS</strong>
-<p>
-The Platform field is less important here
-(SCons doesn't have many behavioral difference
-due to different hardware platforms)
-but the OS field is important.
-</p>
-</li>
-<li>
-<strong>Fill in a good Summary line describing the bug</strong>
-<p>
-This line is what shows up in summary reports,
-so it should be descriptive but not too long.
-Avoid overly-general things like "SCons error," etc.
-</p>
-</li>
-<li>
-<strong>Fill in the Description field</strong>
-<p>
-This is where you should go into detail
-about the configuration,
-the exact error you see,
-what you expected to happen, etc.
-When in doubt, include more information rather than less.
-</p>
-</li>
-<li>
-<strong>Press the "Submit issue" to submit your report</strong>
-<p>
-You will now receive a <tt>Posting issue</tt> page
-that gives you the number of the issue you submitted.
-</p>
-</li>
-<li>
-<strong>If you have a .tar.gz, .zip or other file to attach:</strong>
-<ul>
-<li>
-<strong>Click the "Attach a file to this issue" link</strong>
-</li>
-<li>
-<strong>Fill in the "File" field with the path to the file you want to upload</strong>
-(You can also do this through the <tt>Browse...</tt> button.)
-</li>
-<li>
-<strong>Fill in the Description field</strong>
-</li>
-<li>
-<strong>Click the "Submit" button</strong>
-</li>
-</ul>
-</li>
-</ul>
-
-</div>
-
-</body>
-</html>
diff --git a/www/cn-project-pages/Administrivia/snippets/HtmlSnippet1.html b/www/cn-project-pages/Administrivia/snippets/HtmlSnippet1.html
deleted file mode 100644
index a311062..0000000
--- a/www/cn-project-pages/Administrivia/snippets/HtmlSnippet1.html
+++ /dev/null
@@ -1 +0,0 @@
-<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><ul><li><a title="Messages pending approval" href="/ds/viewPendingApprovalMessages.do">Messages pending approval</a></li><li><a title="Deleted discussions" href="/ds/viewDeletedForums.do">Deleted discussions</a>  <br /></li></ul>                                             
-\ No newline at end of file
diff --git a/www/cn-project-pages/Administrivia/snippets/description.txt b/www/cn-project-pages/Administrivia/snippets/description.txt
deleted file mode 100644
index 08c477b..0000000
--- a/www/cn-project-pages/Administrivia/snippets/description.txt
+++ /dev/null
@@ -1 +0,0 @@
-<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />Administrative information and links
-\ No newline at end of file
diff --git a/www/cn-project-pages/Administrivia/snippets/page.xml b/www/cn-project-pages/Administrivia/snippets/page.xml
deleted file mode 100644
index 7086b8d..0000000
--- a/www/cn-project-pages/Administrivia/snippets/page.xml
+++ /dev/null
@@ -1,10 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<page visibility="1">
-  <component_list>
-    <component visibility="2" type="Html" order="1">
-      <title localize="false">Administrative links</title>
-      <filename>HtmlSnippet1.html</filename>
-    </component>
-  </component_list>
-</page>
-
diff --git a/www/cn-project-pages/snippets/page.xml b/www/cn-project-pages/snippets/page.xml
deleted file mode 100644
index 005b144..0000000
--- a/www/cn-project-pages/snippets/page.xml
+++ /dev/null
@@ -1,16 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<page visibility="1">
-  <component_list>
-    <component visibility="1" type="ProjectMetadata" order="1">
-      <title localize="false" />
-    </component>
-    <component visibility="1" type="Html" order="2">
-      <title localize="false" />
-      <filename>index.html</filename>
-    </component>
-    <component visibility="1" type="Subproject" order="3">
-      <title localize="true">Subprojects</title>
-    </component>
-  </component_list>
-</page>
-
diff --git a/www/cn-project-pages/structure.xml b/www/cn-project-pages/structure.xml
deleted file mode 100644
index 2c1f3bb..0000000
--- a/www/cn-project-pages/structure.xml
+++ /dev/null
@@ -1,10 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<structure>
-  <page>
-    <id>g2uyOi</id>
-    <name>Administrivia</name>
-    <directory>Administrivia</directory>
-    <ordinal>1</ordinal>
-  </page>
-</structure>
-
diff --git a/www/favicon.ico b/www/favicon.ico
deleted file mode 100644
index 1541e5b..0000000
--- a/www/favicon.ico
+++ /dev/null
diff --git a/www/feature-request.html b/www/feature-request.html
deleted file mode 100644
index e644a16..0000000
--- a/www/feature-request.html
+++ /dev/null
@@ -1,99 +0,0 @@
-<html>
-<head>
-<title>Feature Requests</title>
-</head>
-<body>
-
-<div id="apphead">
-<h1><small>scons</small><br />Feature Requests</h1>
-</div>
-
-<p>
-<strong>You must now
-<a href="http://www.tigris.org/servlets/Login">log in</a>
-to a <a href="http://www.tigris.org">tigris.org</a> account
-before submitting a feature request!</strong>
-</p>
-
-<p>
-Feature requests should be submitted to the
-<a href="http://scons.tigris.org/issues/enter_bug.cgi?component=scons&subcomponent=scons&issue_type=FEATURE">"Enter Issue" page</a>.
-A more detailed set of <a href="feature-request.html#steps">submission steps</a>
-can be found below.
-</p>
-
-<p>
-The "Enter Issue" links on this page,
-by default, create a <tt>FEATURE</tt> request,
-a request for completely new SCons functionality.
-If your request is for modified behavior
-of an already-existing SCons feature,
-you may wish to change the Issue type
-to an <tt>ENHANCEMENT</tt> request.
-If you're not sure, leave the issue as a <tt>FEATURE</tt> request;
-it can be reclassified in the future, if necessary.
-</div>
-
-<div class="h2 app" style="border-left: 0px" id="customcontent">
-
-<h2 id="steps">Steps for Submitting a Feature Request</h2>
-
-<p>
-The following guides you step-by-step through the
-process of submitting a feature request.
-</p>
-
-<ul>
-<li>
-<strong><a href="http://www.tigris.org/servlets/Login">Log in</a> at tigris.org</strong>
-<p>
-If you do not already have a tigris.org account,
-register for one at
-<a href="http://www.tigris.org/servlets/Join">http://www.tigris.org/servlets/Join</a>.
-</p>
-<p>
-We no longer accept anonymous feature requests,
-due to spambot abuse of the open-door policy.
-</p>
-</li>
-<li>
-<strong>Go to the
-<a href="http://scons.tigris.org/issues/enter_bug.cgi?component=scons&subcomponent=scons&issue_type=FEATURE">"Enter issue" page</a>
-</strong>
-<p>
-By default, the "scons" subcomponent is selected;
-if this bug is for a different subcomponent, select that instead.
-</p>
-</li>
-<li>
-<strong>Fill in a good Summary line describing the feature you're requesting</strong>
-<p>
-This line is what shows up in summary reports,
-so it should be descriptive but not too long.
-</p>
-</li>
-<li>
-<strong>Fill in the Description field</strong>
-<p>
-This is where you should go into detail
-about what you'd like to see SCons do differently.
-When in doubt, include more information rather than less.
-</p>
-</li>
-<li>
-<strong>Press the "Submit issue" to submit your request</strong>
-<p>
-You will now receive a <tt>Posting issue</tt> page
-that gives you the number of the issue you submitted.
-If you want to attach a file to your feature request,
-you can do so by clicking the
-<tt>Attach a file to this issue</tt>
-link and using that page to upload a file.
-</p>
-</li>
-</ul>
-
-</div>
-
-</body>
-</html>
diff --git a/www/gen_sched_table.py b/www/gen_sched_table.py
deleted file mode 100755
index 85b1b81..0000000
--- a/www/gen_sched_table.py
+++ /dev/null
@@ -1,51 +0,0 @@
-#!/usr/bin/env python
-from __future__ import print_function
-
-import sys
-import datetime
-
-months = ['Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun',
-	  'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec']
-
-print('<table width="100%">')
-def row(*cells, **kw):
-	td = kw.get('tr','td')
-	print('  <tr>')
-	for cell in cells:
-		print('    <%s>%s</%s>' % (td,cell,td))
-	print('  </tr>')
-row('Estimated&nbsp;date', 'Type', 'Comments', tr = 'th')
-
-if len(sys.argv) > 1:
-	f = open(sys.argv[1])
-else:	f = open('schedule')
-now = None
-current = 'UNKNOWN'
-for line in f:
-	if line[0] == '#': continue	# comment
-	if line[0] == '=':
-		date,current = line[1:].strip().split(None, 1)
-		now = datetime.date(*tuple([int(i) for i in date.split('-')]))
-		continue
-	if line[0] == '+':
-		incr,type,desc = line[1:].strip().split(None,2)
-		now = now + datetime.timedelta(int(incr))
-	else:
-		print('dunna understand code', line[0])
-		sys.exit(1)
-	#name = current + '.d' + str(now).replace('-','')
-	date = '%s-%s-%s' % (now.day,months[now.month-1],now.year)
-	if type == 'ck':
-		category = 'Ckpt'
-	elif type == 'rc':
-		category = 'RC'
-	else:
-		category = current = type
-	row(date, category, desc)
-print('</table>')
-
-# Local Variables:
-# tab-width:4
-# indent-tabs-mode:nil
-# End:
-# vim: set expandtab tabstop=4 shiftwidth=4:
diff --git a/www/index.html b/www/index.html
deleted file mode 100644
index 203435d..0000000
--- a/www/index.html
+++ /dev/null
@@ -1,288 +0,0 @@
-<html>
-<head>
-</head>
-<body>
-
-<div class="h2 app" style="border-left: 0px" id="customcontent">
-
-<h2>What is SCons?</h2>
-
-<p>SCons is a next-generation, 
-cross-platform, build tool.
-Think of SCons as an improved
-substitute for the classic
-<tt>Make</tt> utility
-with integrated functionality
-similar to <tt>autoconf</tt>/<tt>automake</tt>
-and compiler caches such as <tt>ccache</tt>.
-</p>
-
-<p>
-Unlike build tools that invent their own mini-language
-or wedge a scripting language onto some other
-configuration file syntax,
-SCons configuration files
-are actually Python scripts.
-The ability to script your build
-gives you a tremendous amount of flexibility
-to solve complicated build problems
-in surprisingly small amounts of maintainable code.
-</p>
-
-<p>
-In short, SCons is an easier, more reliable
-and more flexible way to build software.
-</p>
-
-<!--
-
-<h2><b>Goal</b></h2>
-
-<p>The primary goal of The SCons Project
-is to become the premiere enterprise-quality tool for
-building cross-platform, multi-language software projects
-by offering unparalleled <b>reliability</b> and <b>flexibility</b>
-to software buildmasters and developers.
-</p>
-
-<p>
-Yeah, yeah, every project has similar lofty mom-and-apple-pie goals,
-blah, blah, blah...
-So why is SCons any different?
-Fair question.
-If you go to our public home page at
-<a href="http://www.scons.org/">http://www.scons.org</a>
-you'll get the usual lists of
-supported features and platforms, testimonials, etc.
-But you're presumably at <emphasis>this</emphasis>
-project page because you're interested in digging a little deeper.
-So here are the <emphasis>philosophical viewpoints</emphasis>
-that we think contribute to SCons being
-a really distinctive software build tool:
-</p>
-
-<ul>
-
-<li>
-<strong>Software builds are getting more complicated, not less</strong>
-<p>
-The proliferation of programming languages and technologies
-have led to increasingly difficult demands being
-placed on traditional software build tools Make.
-EVen if you stick to one language--a well-worn
-and mature one like C, for example--the
-differences between the various C tool chains
-and how they behave on various platforms
-make it a real challenge
-to keep your software builds simple and reliable.
-</p>
-<p>
-Consequently, SCons is a build tool
-</p>
-</li>
-
-<li>
-<strong>Effective software building is not a language design issue</strong>
-<p>
-There are a lot of build tools out there,
-and it seems like a new one pops up every week
-as someone gets the urge to fix some particularly
-bad build problem that they're facing.
-Most build tools have, historically,
-invented some special configuration file format
-to express dependencies and actions.
-The problem is that by the time you take care of all
-of the different ways people 
-you really want to have the flexibility
-that a scripting language gives:
-loops, conditionals, real data structures, etc.
-(It's interesting to note that the Ant community is
-working hard on adding more scriptability to their
-XML-based Ant files,
-and James Duncan Davidson, Ant's creator,
-is on record as saying that he'd use a scripting
-language if he were doing it over again.)
-</p>
-<p>
-</p>
-<p>
-Note that SCons is not completely pure in this regard.
-</p>
-</li>
-
-<li>
-<strong>You want to encapsulate software build complexity
-so most developers don't even have to think about it</strong>
-<pp>
-XXX
-</pp>
-</li>
-
-<li>
-<strong>Overall, a reliable build that takes a little longer is
-cheaper than a fast build that you can't rely on</strong>
-<p>
-This one is sometimes tough to swallow,
-because we all want the build to be as quick as possible
-when we're in that tight edit-build-debug development cycle.
-The problem is that if you take shortcuts in how your
-build tool manages the dependencies,
-you waste time chasing phantom problems
-that simply go away because you finally give up
-and do a <tt>make clean; make</tt>.
-</p>
-</li>
-
-<li>
-<strong>Building software in multiple side-by-side variants is crucial
-in a multi-platform world</strong>
-<pp>
-XXX
-</pp>
-</li>
-
-</ul>
-
--->
-
-<h2><b>SCons Features</b></h2>
-
-<ul>
-
-<li>
-<strong>Configuration files are Python scripts</strong>
-<p>
-This provides much more flexibility for solving
-difficult build problems
-than traditional build tools.
-</p>
-</li>
-
-<li>
-<strong>Reliable, automatic dependency analysis</strong>
-<p>
-C, C++ and Fortran are scanned for dependencies,
-eliminating the need for a separate <tt>make depend</tt> step
-or a <tt>make clean</tt> to get all of the dependencies.
-Avoids the time waste from debugging phantom problems
-that mysteriously disappear after you
-<tt>make clean; make</tt>.
-Easily extended to scan for other languages or file types.
-</p>
-</li>
-
-<li>
-<strong>Built-in support for multiple languages</strong>
-<p>
-C, C++, D, Java, Fortran, Yacc, Lex, Qt and SWIG.
-Can also build TeX and LaTeX documents.
-Easily extended for other languages or file types.
-</p>
-</li>
-
-<li>
-<strong>Cross-platform</strong>
-<p>
-Known to work on Linux,
-other POSIX systems (AIX, *BSD, HP/UX, IRIX, Solaris),
-Windows (NT, 2000, XP),
-Mac OS X,
-and OS/2.
-</p>
-</li>
-
-<li>
-<strong>Fetch files from SCM systems or central directory trees</strong>
-<p>
-Built-in support for SCCS, RCS, CVS, BitKeeper and Perforce.
-On-disk directory trees can be searched for source files
-or pre-built target files.
-</p>
-</li>
-
-<li>
-<strong>Support for Microsoft Visual Studio .NET and 2005</strong>
-<p>
-Generates <tt>.dsp</tt> and <tt>.dsw</tt> files,
-or <tt>.sln</tt> and <tt>.vcproj</tt> files,
-from the same build configuration used to build on all platforms.
-Allows Windows developers to do all the productive
-point-and-click debugging they're used to
-without having to maintain a separate build configuration
-just for Windows.
-</p>
-</li>
-
-<li>
-<strong>Reliable detection of file changes using MD5 signatures</strong>
-<p>
-Use of traditional file timestamps instead of MD5 can be configured.
-</p>
-</li>
-
-<li>
-<strong>Parallel builds</strong>
-<p>
-Keeps up to N jobs running simultaneously regardless
-of directory hierarchy.
-</p>
-</li>
-
-<li>
-<strong>Global view of dependencies</strong>
-<p>
-Simplifies builds by eliminating multiple passes
-or reording targets to build everything correctly.
-</p>
-</li>
-
-<li>
-<strong>Multi-platform configuration (like <tt>Autoconf</tt>)</strong>
-<p>
-Support for finding <tt>#include</tt> files,
-libraries, functions and <tt>typedef</tt> declarations.
-</p>
-</li>
-
-<li>
-<strong>Shared built-file cache</strong>
-<p>
-Speeds up multiple builds by allowing developers
-to share pre-built targets
-(like <tt>ccache</tt>, but for any type of target file,
-not just C/C++ compilation).
-</p>
-</li>
-
-</ul>
-
-<!--
-
-<h2></h2>
-
-<p>What are the high-level assumptions or ground rules for the project?
-</p>
-
-<p>For example:
-</p>
-
-<ul>
-<li> we will use programming language X on operating system Y for now.
-
-<li>We will, or will not, consider certain functional areas like
-internationalization, high security, concurrency, etc.  The list of
-functional areas will depend on what you are trying to do.
-
-<li>Try to keep this part short.
-</ul>
-
--->
-
-<h2>Future</h2>
-
-See the <a href="roadmap.html">Roadmap</a> page.
-
-</div>
-
-</body>
-</html>
diff --git a/www/patch-submission.html b/www/patch-submission.html
deleted file mode 100644
index a2d9b95..0000000
--- a/www/patch-submission.html
+++ /dev/null
@@ -1,355 +0,0 @@
-<html>
-<head>
-<title>Patch Submission</title>
-</head>
-<body>
-
-<div id="apphead">
-<h1><small>scons</small><br />Patch Submission</h1>
-</div>
-
-<p>
-<strong>You must now
-<a href="http://www.tigris.org/servlets/Login">log in</a>
-to a <a href="http://www.tigris.org">tigris.org</a> account
-before submitting a patch!</strong>
-</p>
-
-<p>
-Patches should be submitted to the
-<a href="http://scons.tigris.org/issues/enter_bug.cgi?component=scons&subcomponent=scons&issue_type=PATCH">"Enter Issue" page</a>.
-Please follow the <a href="patch-submission.html#guidelines">submission guidelines</a> below
-to make sure your patch contains the necessary information.
-A more detailed set of <a href="patch-submission.html#steps">submission steps</a>
-can be found below.
-</p>
-
-</div>
-
-<div class="h2 app" style="border-left: 0px" id="customcontent">
-
-<h2 id="guidelines">Guidelines for Patch Submission</h2>
-
-<p>
-To try to maintain and improve the quality of SCons releases,
-we have some pretty high standards for the quality of patches
-that make it into the SCons code base.
-This list of guidelines describes how to make it as
-easy as possible for your patch to be accepted for integration.
-We're still interested in your code
-even if you don't follow all of these guidelines,
-but then your patch will more than likely sit in the queue
-until someone else has time to supply all of the
-necessary missing items.
-</p>
-
-<ul>
-
-<li>
-<strong>
-Please
-<a href="http://www.tigris.org/servlets/Login">log in</a>
-to your tigris.org account before submitting any patch
-</strong>
-<p>
-If you do not already have a tigris.org account,
-register for one at
-<a href="http://www.tigris.org/servlets/Join">http://www.tigris.org/servlets/Join</a>.
-</p>
-<p>
-We no longer accept anonymous patches,
-due to spambot abuse of the open-door policy.
-</p>
-</li>
-
-<li>
-<strong>If your patch is extensive, discuss it first on the
-<a href="mailto:scons-dev@scons.org">scons-dev@scons.org</a>
-mailing list
-</strong>
-<p>
-In fact, for extensive changes, it's a good idea to have this discusssion
-<em>before</em> you invest too much time in coding.
-It's possible that your idea overlaps with something else
-already in the works,
-or that your idea is unlikely to be accepted
-because it would conflict with planned directions for SCons.
-It's much better to find that out,
-or get advice on acceptable design choices.
-before you've spent a lot of time polishing code
-that will be rejected because it doesn't fit
-plans for the architecture.
-</p>
-</li>
-
-<li>
-<strong>It's better to submit multiple patches with separate bits of functionality than a big patch containing lots of changes</strong>
-<p>
-Big, intertwined sets of changes
-increase the chances of unintended side effects
-that could cause the entire patch to be rejected.
-If you submit separate functional changes in separate patches,
-those change that meet all the criteria can
-still be integrated even
-though other pieces might be held up for one reason or another.
-</p>
-</li>
-
-<li>
-<strong>Submit your patch in <tt>diff -u</tt> or <tt>diff -c</tt> format</strong>
-<p>
-In particular, do <em>not</em> submit whole source files,
-or <tt>diff</tt> output without any kind of context information.
-It's much more difficult to integrate whole source files
-or plain <tt>diff</tt> output with other changes to
-the SCons code base,
-especially other changes that might be integrated
-after you've submitted your patch.
-</p>
-</li>
-
-<li>
-<strong>Your patch must include test case(s) before it can be integrated!</strong>
-<p>
-THIS IS THE SINGLE MOST COMMON REASON FOR DELAYS IN INTEGRATING PATCHES
-AND THE SINGLE MOST IMPORTANT THING YOU CAN DO TO INCREASE THE
-CHANCES OF YOUR PATCH BEING INTEGRATED QUICKLY.
-</p>
-<p>
-The SCons development methodology requires
-that each change be accompanied by one or more
-new or modified test cases
-that get added to our extensive regression test suite.
-This is to make sure that the behavior added by your patch
-doesn't get inadvertently broken by other changes in the future.
-Patches that fix bugs should contain at least one test case
-that demonstrates the behavior being fixed by the patch.
-For example, if you're fixing a configuration that causes
-SCons to exit with an error and a stack trace,
-the test case should trigger that stack trace
-when run against the current code.
-Patches that add new features or enhancements
-should contain test cases that use
-the new behavior being added to SCons.
-</p>
-<p>
-You can do any of the following to supply
-test cases with your patch:
-</p>
-<ul>
-<li>
-<strong>Include actual new or modified SCons test scripts in your patch</strong>
-<p>
-This is the best option because it's the easiest to integrate,
-and therefore maximizes the chances of your patch being accepted quickly.
-(Note that, yes, there's a curve to learning how to
-write test scripts in the SCons testing harness.
-We're working on documentation to deal with that.)
-</p>
-</li>
-<li>
-<strong>Include a .tar.gz or .zip file containing test configurations</strong>
-<p>
-If you can't quite figure out how to deal with the SCons test scripts,
-the next best option is to include with your patch an archive file
-containing one or more actual test configurations
-(<tt>SConscript</tt> files, input files, etc.).
-It will be relatively straightforward for someone integrating your patch,
-and who's presumably familiar with the SCons testing harness,
-to turn this into an appropriate test script.
-Be sure to include a description of how to run your recommended test scenario,
-or a script for doing so.
-</p>
-</li>
-<li>
-<strong>Describe how to go about testing the patch</strong>
-<p>
-If you really can't cook up a test configuration to include with the patch,
-the lowest-common-denominator approach is to just describe
-how to go about testing the patch.
-Be as specific as possible,
-even if you think it should be obvious
-how to test the patch.
-It might be clear to you while you're writing the code,
-but it will still take someone else time
-to make sure they understand your intent
-and work out the details of how to set up an appropriate case.
-The point is you're trying to use your existing knowledge
-of the bug being fixed or new feature being added
-to make the process of integrating your patch as
-simple and quick as possible,
-thereby increasing the chance of your patch making it
-into the SCons code base.
-</p>
-</li>
-</ul>
-<p>
-If you don't supply <em>any</em> sort of testing
-information with your patch,
-well, you're still welcome to submit the code.
-Just be aware that the patch will likely stay
-in the queue until someone has time to reverse-engineer
-a test case.
-</p>
-</li>
-
-<li>
-<strong>Your patch should not break any existing tests</strong>
-<p>
-This almost sounds like it should go without saying,
-but the reason we put so much emphasis on test cases
-is so that we can make sure functionality doesn't break.
-Your patch will almost certainly be run through the
-the complete set of checked-in test scripts,
-and if any of them break,
-your patch will either be rejected outright
-or delayed while someone else figures out how to fix it
-(or the tests) so that everything works correctly.
-You should, of course, avoid this by running your patch
-against the regression tests and fixing any problems
-<em>before</em> submitting your patch.
-If you run your patch against against the regression tests
-but can't figure out how to fix all the cases,
-the best bet would be to ask the
-<a href="mailto:scons-dev@scons.org">scons-dev@scons.org</a>
-mailing list.
-</p>
-</li>
-
-<li>
-<strong>Your patch should include documentation changes</strong>
-<p>
-We also insist that changes to the SCons code base
-be accompanied by appropriate changes to the documentation.
-In practice, right now we make sure the man page is up to date,
-and updates to the User's Guide often lag.
-</p>
-<p>
-Similar to the guidelines above for testing,
-if you don't submit changes to the actual man page with your patch,
-it's helpful if you at least provide
-some suggested text describing your change.
-Even if the actual words get rewritten
-(usually to make the style consistent with the rest of the man page),
-taking the time to provide this
-makes the integration easier because
-the person integrating the patch doesn't have
-to reverse-engineer the <em>intent</em>
-of your change to figure out how to describe it.
-</p>
-</li>
-
-</ul>
-
-<h2 id="steps">Steps for Submitting a Patch</h2>
-
-<p>
-The following guides you step-by-step through the
-process of submitting a patch to SCons.
-</p>
-
-<p>
-NOTE:  Attaching a file or files
-(such as a .tar.gz or .zip file containing your patch)
-is a two-step process in the tigris.org Issue Tracker.
-You must first create the patch issue in the Tracker,
-and then attach the file(s) in a separate step,
-as described below.
-</p>
-
-<ul>
-
-<li>
-<strong><a href="http://www.tigris.org/servlets/Login">Log in</a> at tigris.org</strong>
-<p>
-If you do not already have a tigris.org account,
-register for one at
-<a href="http://www.tigris.org/servlets/Join">http://www.tigris.org/servlets/Join</a>.
-</p>
-<p>
-We no longer accept anonymous bug reports,
-due to spambot abuse of the open-door policy.
-</p>
-</li>
-
-<li>
-<strong>Go to the
-<a href="http://scons.tigris.org/issues/enter_bug.cgi?component=scons&subcomponent=scons&issue_type=PATCH">"Enter issue" page</a>
-</strong>
-<p>
-By default, the "scons" subcomponent is selected;
-if this bug is for a different subcomponent, select that instead.
-</p>
-</li>
-
-<li>
-<strong>Specify the version of SCons that you used as a baseline</strong>
-<p>
-You can leave this <tt>-unspecified-</tt>,
-in which case the assumption will be that you started with
-the code checked in to our Subversion repository
-at the time you opened the issue.
-</p>
-</li>
-
-<li>
-<strong>Fill in a good Summary line describing the patch</strong>
-<p>
-This line is what shows up in summary reports,
-so it should be descriptive but not too long.
-Avoid overly-general things like "SCons error," etc.
-</p>
-</li>
-
-<li>
-<strong>Fill in the Description field</strong>
-<p>
-This is where you should describe
-the nature of your patch:
-the exact error it fixes,
-the feature that it adds,
-how to go about testing it,
-etc.
-When in doubt, include more information rather than less.
-</p>
-</li>
-
-<li>
-<strong>Press the "Submit issue" to submit your report</strong>
-<p>
-You will now receive a <tt>Posting issue</tt> page
-that gives you the number of the issue you submitted.
-</p>
-</li>
-
-<li>
-<strong>Click the "Attach a file to this issue" link</strong>
-<p>
-</p>
-</li>
-
-<li>
-<strong>Fill in the "File" field with the path to the patch file you want to upload</strong>
-<p>
-(You can also do this through the <tt>Browse...</tt> button.)
-</p>
-</li>
-
-<li>
-<strong>Fill in the Description field</strong>
-<p>
-</p>
-</li>
-
-<li>
-<strong>Click the "Submit" button to attach your patch file</strong>
-<p>
-</p>
-</li>
-
-</ul>
-
-</div>
-
-</body>
-</html>
diff --git a/www/project_highlights.html b/www/project_highlights.html
deleted file mode 100644
index 98f00bc..0000000
--- a/www/project_highlights.html
+++ /dev/null
@@ -1,24 +0,0 @@
-<html>
-<head>
-</head>
-<body>
-
-
-<p>
-<strong>09 Sep 2011:</strong>
-Release 2.1.0 is now available at the
-<a href="http://sourceforge.net/project/showfiles.php?group_id=30337">download page</a>.
-</p>
-
-
-<p>
-<strong>15 Aug  2010:</strong>
-Release 2.0.1 is now available at the
-<a href="http://sourceforge.net/projects/scons/files/">download page</a>.
-</p>
-
-
-
-
-</body>
-</html>
diff --git a/www/project_issues.html b/www/project_issues.html
deleted file mode 100644
index dc28ca8..0000000
--- a/www/project_issues.html
+++ /dev/null
@@ -1,123 +0,0 @@
-<div id="apphead">
-<h1><small>scons</small><br />         Issue Tracker
-    </h1>
-</div>
-
-
-<div id="projectissues" class="application">
-
-
-<table class="axial">
-
- <tr>
-   <th><a href="http://scons.tigris.org/issues/query.cgi">Query database</a></th>
-   <td>
-  Search for issues and defects here or find a specific issue. Always search first before reporting an issue to avoid duplication.
- <form id="ProjectIssuesForm" method="get" action="http://scons.tigris.org/issues/show_bug.cgi">
-  <p>
-  <input type="submit" value="Find" /> Issue # <input name="id" size="6" />
-
-  </p>
- </form>
-  <p>
-  Common queries:
-  </p>
-  <table>
-    <tr>
-      <td COLSPAN="4"> <a href="http://scons.tigris.org/issues/buglist.cgi?Submit+query=Submit+query&component=scons&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&issue_status=UNCONFIRMED">All Open Issues</a> </td>
-    </tr>
-    <tr>
-      <td> <ul> <li> Bug Reports: </li> </ul> </td>
-      <td> <a href="http://scons.tigris.org/issues/buglist.cgi?Submit+query=Submit+query&issue_type=DEFECT&component=scons">All</a> </td>
-      <td> <a href="http://scons.tigris.org/issues/buglist.cgi?Submit+query=Submit+query&issue_type=DEFECT&component=scons&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&issue_status=UNCONFIRMED">Open</a> </td>
-      <td> <a href="http://scons.tigris.org/issues/buglist.cgi?Submit+query=Submit+query&issue_type=DEFECT&component=scons&issue_status=RESOLVED&issue_status=VERIFIED&issue_status=CLOSED">Non-Open</a> </td>
-    </tr>
-    <tr>
-      <td> <ul> <li>Enhancement: </li> </ul> </td>
-      <td> <a href="http://scons.tigris.org/issues/buglist.cgi?Submit+query=Submit+query&issue_type=ENHANCEMENT&component=scons">All</a> </td>
-      <td> <a href="http://scons.tigris.org/issues/buglist.cgi?Submit+query=Submit+query&issue_type=ENHANCEMENT&component=scons&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&issue_status=UNCONFIRMED">Open</a> </td>
-      <td> <a href="http://scons.tigris.org/issues/buglist.cgi?Submit+query=Submit+query&issue_type=ENHANCEMENT&component=scons&issue_status=RESOLVED&issue_status=VERIFIED&issue_status=CLOSED">Non-Open</a> </td>
-    </tr>
-    <tr>
-      <td> <ul> <li>Feature Requests: </li> </ul> </td>
-      <td> <a href="http://scons.tigris.org/issues/buglist.cgi?Submit+query=Submit+query&issue_type=FEATURE&component=scons">All</a> </td>
-      <td> <a href="http://scons.tigris.org/issues/buglist.cgi?Submit+query=Submit+query&issue_type=FEATURE&component=scons&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&issue_status=UNCONFIRMED">Open</a> </td>
-      <td> <a href="http://scons.tigris.org/issues/buglist.cgi?Submit+query=Submit+query&issue_type=FEATURE&component=scons&issue_status=RESOLVED&issue_status=VERIFIED&issue_status=CLOSED">Non-Open</a> </td>
-    </tr>
-    <tr>
-      <td> <ul> <li> Patches: </li> </ul> </td>
-      <td> <a href="http://scons.tigris.org/issues/buglist.cgi?Submit+query=Submit+query&issue_type=PATCH&component=scons">All</a> </td>
-      <td> <a href="http://scons.tigris.org/issues/buglist.cgi?Submit+query=Submit+query&issue_type=PATCH&component=scons&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&issue_status=UNCONFIRMED">Open</a> </td>
-      <td> <a href="http://scons.tigris.org/issues/buglist.cgi?Submit+query=Submit+query&issue_type=PATCH&component=scons&issue_status=RESOLVED&issue_status=VERIFIED&issue_status=CLOSED">Non-Open</a> </td>
-    </tr>
-    <tr>
-      <td> <ul> <li> Tasks: </li> </ul> </td>
-      <td> <a href="http://scons.tigris.org/issues/buglist.cgi?Submit+query=Submit+query&issue_type=TASK&component=scons">All</a> </td>
-      <td> <a href="http://scons.tigris.org/issues/buglist.cgi?Submit+query=Submit+query&issue_type=TASK&component=scons&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&issue_status=UNCONFIRMED">Open</a> </td>
-      <td> <a href="http://scons.tigris.org/issues/buglist.cgi?Submit+query=Submit+query&issue_type=TASK&component=scons&issue_status=RESOLVED&issue_status=VERIFIED&issue_status=CLOSED">Non-Open</a> </td>
-    </tr>
-  </table>
-  </td>
-</tr>  
-
-
- <tr>
-   <th>Enter an issue</th>
-   <td>
-
- To enter an issue, you must first be a project member and know the component you want to report on.  
-
-                        
-    
-<p>
-
-Enter: 
-</p>
- <ul>
-        <li><a href="http://scons.tigris.org/issues/enter_bug.cgi?issue_type=DEFECT">Defect</a></li>
-        <li><a href="http://scons.tigris.org/issues/enter_bug.cgi?issue_type=PATCH">Patch</a></li>
-        <li><a href="http://scons.tigris.org/issues/enter_bug.cgi?issue_type=TASK">Task</a></li>
-        <li><a href="http://scons.tigris.org/issues/enter_bug.cgi?issue_type=FEATURE">Feature</a></li>
-        <li><a href="http://scons.tigris.org/issues/enter_bug.cgi?issue_type=ENHANCEMENT">Enhancement</a></li>
-
-</ul>
-  </td>
-</tr>  
-
- 
-
- <tr>
-   <th><a href="http://scons.tigris.org/issues/buglist.cgi?cmdtype=runuserdefault">My issues</a></th>
-   <td>
-  View both active issues assigned to you and those that you have entered.
-  </td>
-</tr>  
- <tr>
-   <th><a href="http://scons.tigris.org/issues/userprefs.cgi">My preferences</a></th>
-
-   <td>
-  View and edit your Issue Tracker user settings.  
-  </td>
-</tr>  
-
- <tr>
-   <th><a href="http://scons.tigris.org/issues/reports.cgi">Reports</a></th>
-   <td>
-  Generate and view issue tracking reports.
-  </td>
-</tr>
-
-        
-
- <tr>
-   <th><a href="http://scons.tigris.org/issues/admin.cgi">Configuration options </a> 
-   </th>
-   <td>
-    Add, view and edit Issue Tracker configuration parameters, including project member permissions, issue tracking groups, project components and subcomponents, etc.
-   </td>
-</tr>  
-
-
-
-</table>
-</div>
diff --git a/www/project_tools.html b/www/project_tools.html
deleted file mode 100644
index cf80234..0000000
--- a/www/project_tools.html
+++ /dev/null
@@ -1,41 +0,0 @@
-<!--
-This is a customization of the tigris.org nav bar to try to make
-things a little more navigable.  This isn't really approved by
-tigris.org (I copped the basic idea from the Subversion project pages),
-but it works for our purposes.
-
-The main changes are:
-
-* Added links to the scons.org home page and scons.org wiki.
-* Our custom issue tracker page, which contains common queries.
-* Subheadings for reporting a bug / submitting a patch / request a feature.
-* Link to our Roadmap page.
--->
-<li><a href="http://scons.org/">SCons Home Page</a></li>
-<li><a href="https://github.com/SCons/scons/wiki/">SCons Wiki</a></li>
-</dd>
-
-<dd>
-<li><a href="/servlets/ProjectMemberList">Project Membership</a></li>
-<li><a href="/servlets/ProjectNewsList">Announcements</a></li>
-<li><a href="http://scons.org/lists.php">Discussion lists/fora</a></li>
-<!-- <li><a href="/ds/viewForums.do">Discussion lists/fora</a></li> -->
-<li><a href="/servlets/ProjectDocumentList">Documents &amp; files</a></li>
-<li><a href="/source/browse/scons/">Browse source code</a></li>
-<li><a href="/servlets/ReportingHome?scope=Project">Project metrics</a></li>
-</dd>
-
-<dd>
-<li>
-<!-- <a href="/servlets/ProjectIssues">Issue Tracker</a> -->
-<a href="/project_issues.html">Issue Tracker</a>
-<ul>
-<li><a href="/bug-submission.html">Report a Bug</a></li>
-<li><a href="/patch-submission.html">Submit a Patch</a></li>
-<li><a href="/feature-request.html">Request a Feature</a></li>
-</ul>
-</li>
-</dd>
-
-<dd>
-<li><a href="/roadmap.html">Roadmap</a></li>
diff --git a/www/roadmap.html b/www/roadmap.html
deleted file mode 100644
index 333d0fd..0000000
--- a/www/roadmap.html
+++ /dev/null
@@ -1,173 +0,0 @@
-<html>
-<head>
-<title>scons: Release Roadmap</title>
-</head>
-<body>
-
-<div id="apphead">
-<h1><small>Release Roadmap</small></h1>
-</div>
-
-<div class="h2 app" style="border-left: 0px" id="customcontent">
-
-<h2>Current Releases</h2>
-
-<p>
-The current stable release is 2.1.0, released 09 Sep 2011.
-The latest 2.1.x release is 2.1.0, released 09 Sep 2011.
-</p>
-
-<p>
-The latest 1.3.x release is 1.3.1, released 25 July 2010.
-</p>
-
-<h2>Upcoming Releases</h2>
-
-<p>
-Our goal is to meet the dates
-for release candidates and the releases themselves;
-the beta checkpoint dates are our best guess as this was published,
-but they may be adjusted without notice.
-</p>
-
-<!--
-
-DO NOT EDIT THE FOLLOWING TABLE DIRECTLY.
-
-Edit the "schedule" file and replace it with the output from
-running "gen_sched_table.py".
-
--->
-
-<table width="100%">
-  <tr>
-    <th>Estimated&nbsp;date</th>
-    <th>Type</th>
-    <th>Comments</th>
-  </tr>
-  <tr>
-    <td>May 2010</td>
-    <td>Ckpt</td>
-    <td>Beta for 2.0; breaks backward compatibility</td>
-  </tr>
-  <tr>
-    <td>June 2010</td>
-    <td>RC</td>
-    <td>Release candidate for 2.0.</td>
-  </tr>
-  <tr>
-    <td>June 2010</td>
-    <td>2.0</td>
-    <td>Public release that breaks backward compatibility and drops deprecated features</td>
-  </tr>
-  <tr>
-    <td>July 2010</td>
-    <td>Ckpt</td>
-    <td>Beta for testing new features.</td>
-  </tr>
-  <tr>
-    <td>Aug 2010</td>
-    <td>Ckpt</td>
-    <td>Beta for testing new features.</td>
-  </tr>
-  <tr>
-    <td>Sept 2010</td>
-    <td>RC</td>
-    <td>Release candidate for 2.1.</td>
-  </tr>
-  <tr>
-    <td>Oct 2010</td>
-    <td>2.1</td>
-    <td>First minor release of v2</td>
-  </tr>
-</table>
-
-<!--
-
-<h2>Upcoming Features</h2>
-
--->
-
-<h2>Release Planning</h2>
-
-<h3>Release numbering</h3>
-
-<p>
-Our release numbers are of the form <i>major</i>.<i>minor</i>.<i>revision</i>.
-</p>
-
-<ul>
-<li>
-<strong>Major release (1.0, 2.0, 3.0, etc.)</strong>
-<p>
-The major number increments when one of two things happens:
-</p>
-  <ul>
-  <li>The release knowingly breaks backwards compatibility in some way.
-  <li>The release knowingly causes a rebuild when you upgrade.
-  </ul>
-<p>
-Our goal is that as a user of SCons,
-you should always be able to upgrade to a later
-release of the same major version
-with complete confidence that your build will not break.
-We expect that our major releases will be long-lived platforms
-with many minor releases to add functionality and fix bugs.
-</p>
-</li>
-<li>
-<strong>Minor release (1.1, 1.2, 1.3, etc.)</strong>
-<p>
-Minor numbers increment for releases
-that add new functionality and/or bug fixes
-to an existing major release.
-Any new functionality will never knowingly break backwards compatibility
-with any previous minor releases from the same major release.
-</p>
-</li>
-<li>
-<strong>Bug-fix revisions (1.0.1, 1.1.1, 1.2.1, etc.)</strong>
-<p>
-Revision numbers are appended and/or incremented
-whenever a critical bug fix is necessary
-for a major or minor release.
-Because most new functionality and bug fixes
-will be delivered in minor releases,
-we expect that there will be few of these&mdash;at most
-one per minor release.
-</p>
-</li>
-<li>
-<strong>Release candidates (x.y.z.dyyyymmdd)</strong>
-<p>
-A release candidates is a special form of checkpoint
-(see below)
-that is expected to be the next major or minor release.
-If blocking issues show up in the candidate,
-another candidate will normally be issued
-(potentially delaying the release date),
-otherwise the candidate will be repackaged as the major or minor release.
-</p>
-</li>
-<li>
-<strong>Checkpoints (x.y.z.dyyyymmdd)</strong>
-<p>
-A checkpoint has a 'd<i>yyymmdd</i>' suffix
-and is made every couple of weeks between major or minor releases.
-It is intended for beta testing new features
-and for ensuring that bug fixes work as intended.
-Although existing features from the previous release will not change,
-compatibility of features under test is not guaranteed between checkpoints
-(<i>i.e.</i>, the implementation of the feature may change).
-Checkpoints are intended not only to allow for wider testing,
-but also to make new features available to users
-(who may urgently need one of them)
-in advance of them being published in the next major or minor release.
-</p>
-</li>
-</ul>
-
-</div>
-
-</body>
-</html>
diff --git a/www/schedule b/www/schedule
deleted file mode 100644
index 4b1e9eb..0000000
--- a/www/schedule
+++ /dev/null
@@ -1,19 +0,0 @@
-#=2008-09-13 1.0.1
-#=2008-10-01 Release candidate for 1.1.
-#=2008-10-10 1.1.0
-=2008-12-01 1.1.0
-+4 rc	Release candidate for 1.2. (released 7-Dec)
-+7 1.2	Second minor release of 1.0. (released 21-Dec)
-+17 ck	Beta for testing new features.
-+14 ck	Beta for testing new features.
-+7 rc	Release candidate for 1.3.
-+7 1.3	Third minor release of 1.0.
-+7 ck	Beta for 2.0; breaks backward compatibility
-#+7 ck	Beta for 2.0.
-+7 rc	Release candidate for 2.0.
-+7 rc	Release candidate for 2.0, if needed.
-+7 2.0	Public release that breaks backward compatibility and drops deprecated features
-+21 ck	Beta for testing new features.
-+21 ck	Beta for testing new features.
-+21 rc	Release candidate for 2.1.
-+7 2.1	First minor release of 2.0
author	William Deegan <bill@baddogconsulting.com>	2018-04-30 14:11:01 (GMT)
committer	William Deegan <bill@baddogconsulting.com>	2018-04-30 14:11:01 (GMT)
commit	df92a34720a8511f63a12abcd7e0ca2deeeca4d1 (patch)
tree	30fba26bf120287bc6f5990efb77881de7bcf95b
parent	aebcf66c646c071cb40832c8b721ac13ad70fa75 (diff)
download	SCons-df92a34720a8511f63a12abcd7e0ca2deeeca4d1.zip SCons-df92a34720a8511f63a12abcd7e0ca2deeeca4d1.tar.gz SCons-df92a34720a8511f63a12abcd7e0ca2deeeca4d1.tar.bz2