diff --git a/planning/EclipseSimultaneousRelease.html b/planning/EclipseSimultaneousRelease.html
index abd53dc..7357860 100644
--- a/planning/EclipseSimultaneousRelease.html
+++ b/planning/EclipseSimultaneousRelease.html
@@ -7,17 +7,11 @@
 </head>
 <body>
 <h1 style="text-align: center">The Eclipse Simultaneous Release</h1>
-<h1 style="text-align: center; font-size: smaller">November 8, 2010<br />
+<h1 style="text-align: center; font-size: smaller">December 1, 2010<br />
 <a href="http://wiki.eclipse.org/Planning_Council">Eclipse Planning
 Council</a><br />
 Contact: <a href="mailto: david.williams@eclipse.org">David Williams</a></h1>
 
-<p><i>Note: This document, for Indigo release, has yet to be
-formally reviewed and approved by the Eclipse Planning Council. It is
-unlikely to change substantially, but could have items added or removed
-up to M4. After M4, only clarifications or changes in wording would
-occur, no changes to expectations or requirements.</i></p>
-
 <p>This document defines the rules and criteria for participating in
 the yearly Simultaneous Release. There are more criteria than when
 releasing at other times partially because there are more projects
@@ -75,15 +69,22 @@
 <p>Also, for long term planning, remember that being in a
 Simultaneous Release also means a commitment to participating the SR1
 and SR2 simultaneous maintenance releases.</p>
-<p><b>Once in, always in.</b> Once a project joins one year's
-Simultaneous Release, it is assumed they will be in the next one, unless
-they formally withdraw. So, for example, it is required they will meet
-the subsequent year's Milestone Schedule, have plans done by M2 of
-following year, etc. Put another way, being part of the Simultaneous
-Release is not a &quot;one time&quot; activity, covering only the
-literal release date and not even a &quot;part time&quot; activity
-covering only part of the yearly development cycle. Instead it is a
-commitment to stay &quot;simultaneous&quot; on an on-going basis.</p>
+<p><b>Joining implies continuous participation. </b> After a
+release, there are two follow on activities that must be planned for.
+First is that releases maintenance stream. The second is the subquent
+year's release. In both cases, it is (as always) up to the project to
+decide what to fix or what to enhance, but being part of the train
+implies you will always be able to build, in maintenance and in the
+subsequent release's milestone builds. Sometimes this means simply
+leaving repositories intact, etc., but occasionally projects may need to
+fix "prereqs" or similar. Put another way, being part of the
+Simultaneous Release is not a &quot;one time&quot; activity, covering
+only the literal release date and not even a &quot;part time&quot;
+activity covering only part of the yearly development cycle. Instead it
+is a commitment to stay &quot;simultaneous&quot; on an on-going basis.
+Once in, if projects decide to not be part of future simultaneious
+releases, they need to communicate that widely, and as early as
+possible, since could effect adopters or downstream projects.</p>
 
 
 <h3>IP Documentation</h3>
@@ -132,7 +133,8 @@
 <p>In addition to the ordinarily required Release Review Archival
 Materials, all Projects participating in yearly Release agree to provide
 a checklist-with-detail form that describes their compliance (or not)
-with all of the criteria items described in this document. Note that
+with all of the criteria items described in this document. May be in the form of providing a URL 
+to the checklist, ideally as part of the normal docuware. Note that
 this checklist-with-detail must be updated every milestone as things are
 completed, or details added, so progress can be reviewed by Planning
 Council and potential adopters. The primary report of compliance with
@@ -141,13 +143,11 @@
 each other, PMCs may decide to document things at a subproject level,
 and then &quot;roll-up&quot; to a Top Level document, or, if a Top Level
 Project is known to be uniform and &quot;close knit&quot; then they may
-provide one summary document that applies to all sub-projects. [This
-will likely be automated as web-app, possibly with &quot;automatic&quot;
-roll up].</p>
+provide one summary document that applies to all sub-projects.</p>
 <p></p>
 <h2>Play well with others ... to be in common repository</h2>
 <p>The requirements in this section must be met for a project to be
-on the common, central repository (e.g. /releases/indigo) for end users
+on the common, central repository (e.g. /releases/helios) for end users
 to discover easily and minimum requirements to be included in EPP
 Packages. The criteria in this section are designed to make sure
 projects work relatively well, and work well together. This is
@@ -155,7 +155,7 @@
 complicated, interwoven ways so each piece of the puzzle must fit
 together well and be dependable and be maintainable, as well as being on
 time and IP clean.</p>
-<p><b>Communication</b>:</p>
+<p><b>Communication</b>:
 <p>At least one person from each project in a Simultaneous Release
 must subscribe to cross-project mailing list, since that is the primary
 communication channel for issues related to the Simultaneous Release.
@@ -207,11 +207,13 @@
 Eclipse certificate</a>.</p>
 
 <p><b>Jarred Bundles</b>. Projects must use jarred plug-ins (with
-unpack=false) unless authorized by the planning council for technical
-exceptions. Also, nested jars should be avoided if possible since it
-creates problems for projects that has dependencies to such plug-ins.
-The OSGi runtime is fine with it but the PDE environment is not able to
-handle classpaths that contain nested jars.</p>
+unpack=false) unless there are technical reasons not to do so. Also,
+nested jars should be avoided if possible since it creates problems for
+projects that has dependencies to such plug-ins. The OSGi runtime is
+fine with it but the PDE environment is not able to handle classpaths
+that contain nested jars. Exceptions to these principles should be
+documented by the project, so we can learn the reasons and extent of
+unjarred bundles.</p>
 <p><b>Re-use and share</b><b> </b>common third party jars. Any
 third-party plug-ins that are common between projects must be consumed
 via <a href="http://www.eclipse.org/orbit">Orbit</a>; a Simultaneous