dev_process/implementation-phase.php - www.eclipse.org/projects - Git at Google

 <?php  																														require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php");	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); 	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); 	$App 	= new App();	$Nav	= new Nav();	$Menu 	= new Menu();		include($App->getProjectCommon());    # All on the same line to unclutter the user's desktop'

 $pageTitle 		= "Implementation Phase";
 $pageKeywords	= "development process";
 $pageAuthor		= "Bjorn Freeman-Benson Nov 20/05";

 ob_start();
 ?>
     <div id="maincontent">
 	<div id="midcolumn">

 <h1>Implementation Phase</h1>
 <p><i>version 030 - December 16, 2005</i></p>
 <p><a href="index.php">[This is one page of the larger document.]</a></p>
 <h2>Implementation (Mature) Phase</h2>
 <p>The project has demonstrated process, community, and technology and is now a
 mature member of the Eclipse Community. </p>
 <p>During the Implementation Phase, the project and project leadership maintain the
 project's infrastructure and continue to participate in the Eclipse Community
 using these, and other, mechanisms. The more frequent are:</p>
 <ul>
   <li><b>Status Reports.</b><br>
     All projects are required to report their status quarterly, if not more
     often. See the <a href="project-status-infrastructure.php">Project Status
     Reporting documentation</a> for more details.
   </li>
   <li><b>Milestone Releases.</b> Interim milestone and release candidate
     releases will be named n.nMn (e.g., 3.3M4) or n.nRCn (e.g., 4.1RC2). The n.n
     release numbering is reserved for the final Reviewed release. Additionally,
     all nightly, integration, milestone, release candidate, and final releases
     will be available via a download link found on the project's home page.</li>
   <li><b>Use the Correct Servers.</b> The eclipse.org infrastructure is solid
     and capable, but it is also capable of being brought to its knees by poor
     file placement. Projects will follow these guidelines:
     <ul>
       <li>Do not use viewcvs links in any web pages. Use normal links instead.
         Your project's web pages are stored in CVS and can be committed via CVS,
         but the links need to be normal links to reduce server load and enable
         load sharing.</li>
       <li>Do not place downloads or large files on the dev.eclipse.org
         machine (the web pages or the CVS).&nbsp; Use the download.eclipse.org
         machine for all downloads - these machines are load balanced, mirrored,
         and have a separate bandwidth allotment.
         <ul>
           <li>Large files that change often should be placed on download
             servers.</li>
           <li>Files larger than 5Mbs should be placed on the download servers.</li>
           <li>All zip and gzip files should be placed on the download servers.</li>
         </ul>
       </li>
     </ul>
   </li>
   <li><b>Release Reviews.</b><br>
     Each major release (where <i>major</i> is defined as any release whose N or
     M version number changes in the N.M.P version number) must go through a <a href="release-review.php">Release
     Review</a>. Please schedule enough time to complete the Review and any
     potential remedial actions so as not to impact the project's release
     schedule.</li>
   <li><b>Continue encouraging the three communities.</b><br>
     As the project has completed its Validation Phase, this should already be
     happening, but I include it here for completeness. Continue
     to use the public mailing lists, respond in the newsgroups, write articles,
     staff code camps, triage the bugzilla, attend the Eclipse community events (<a href="http://www.eclipsecon.org/">EclipseCon</a>,
     <a href="/org/foundation/council.php">Council meetings</a>, ...) and so on.</li>
   <li>
     <p align="left" style="border-style: dotted; border-width: 2; padding-left: 5; padding-right: 5; padding-top: 2; padding-bottom: 2"><b>Following the Eclipse IP Policy.<br>
     </b>The <a href="/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf"> Eclipse IP Policy</a> requires
     <a href="/legal/committerguidelines.php"> certain due
     diligence and record keeping</a>.
     Small contributions in the form of bugzilla patches and the like can be
     committed directly to the code base (after the appropriate contributor
     information is recorded). Medium<sup>2</sup>, large, and all third-party (non-EPL
     licensed) contributions require the <a href="/legal/ContributionQuestionnairePart1-v1.0.htm"> Code Contribution
     Questionnaire</a> and
     additional record keeping (also see the <a href="/legal/EclipseLegalProcessPoster-v1.2.4.pdf">descriptive process flowchart poster</a>). Maintaining a current and accurate <a href="project-log.php"> Project Log</a> is
     the best way to keep this information up-to-date.<br>
     The due diligence process for new contributions takes, on average, four to
     six calendar weeks to complete. Thus we recommend limiting large and
     third-party contributions to the beginning of a release cycle rather than
     waiting to the end.</li>
   <li><b>Changing eclipse.org content.</b><br>
     The eclipse.org site has various news and announcement pages, as well as
     pages that describe the projects and top-level PMCs. To request an
     announcement or news or changes to these pages, send email to the <a href="mailto:emo@eclipse.org">EMO</a>.</li>
   <li><b>Add a new Committer.</b><br>
     After the Committer has been voted in using the top-level PMC's voting
     process, follow the <a href="/legal/newcommitter.html">New
     Committer Process</a>.</li>
   <li><b>Active Progress.</b><br>
     Project are expected to continue to be active: in development, in releases,
     in newsgroup and mailing list responses, and in the community more
     generally. Projects that become inactive will be reviewed and probably <a href="archived-phase.php">archived</a>.
   </li>
   <li><b>Use project name correctly.<br>
     </b>Every public use of the project name - in a web page, a presentation, a
     press release, an article, etc. - must follow the <a href="project-naming-policy.php">project
     naming guidelines</a>:
     <ul>
       <li>The first use of the project name uses the entire descriptive name
         and may include the optional nickname. For
         example, &quot;The Eclipse Component Assembly
         Project (Buckminister)&quot;. Subsequent references to the project may use the
         nickname, e.g., &quot;Buckminister&quot;.</li>
       <li>If the project is in <a href="proposal-phase.php">the Proposal Phase</a>
         or the <a href="validation-phase.php">Validation Phase</a>, that fact
         must be mentioned early in the document. For example, &quot;The proposed
         Eclipse Phoenix project ...&quot; or &quot;The Buckminister project,
         being incubated at Eclipse, is releasing version 0.2 of their framework
         for early alpha feedback from the community.&quot;</li>
     </ul>
   </li>
   <li><b>Use brand graphics and watermarks correctly.<br>
     </b>Projects in proposal and validation/incubation stages must use the
     appropriate <a href="/projects/gazoo.php">Eclipse-branded graphics</a> (i.e.,
     the Eclipse Proposal graphic and the Eclipse Incubation graphic respectively) on
     their webpage and communications. Projects in the proposal phase must use the
     proposal watermark on their web
     pages.</li>
   <li><b>Follow the press guidelines.<br>
     </b>Projects must follow the <a href="/org/press-release/pressguidelines.htm">Eclipse
     Foundation press guidelines</a> in the preparation, wording, and
     dissemination of press releases.</li>
 </ul>
 <p>The less frequent are:</p>
 <ul>
   <li><b>Remove a Committer.</b><br>
     After the Committer has been removed using the top-level PMC's process, send
     email to the <a href="mailto:emo@eclipse.org">EMO</a> with: the name of the
     project and hosting top-level project, the full name and email address of
     the Committer, and the list of CVS packages to which commit accesses will be
     removed.</li>
   <li><b>Change a Committer's access.</b><br>
     The logical combination of Add and Remove accomplished via email by the
     top-level PMC to the <a href="mailto:webmaster@eclipse.org">Eclipse
     sysadmins</a>. Soon there will be a work request tracking system instead of
     emails, but for now emails will suffice.</li>
   <li><b>Change access rights on download server.</b><br>
     Send email to the <a href="mailto:webmaster@eclipse.org">Eclipse sysadmins</a>
     with the names of the Committers to be added/removed to/from the download
     server.</li>
   <li><b>Change root CVS components.</b><br>
     Send email to the <a href="mailto:webmaster@eclipse.org">Eclipse sysadmins</a>
     with the list of component changes and the list of Committers for the
     components.</li>
   <li><b>Marking stale CVS components.</b><br>
     As the projects evolve, some CVS modules become stale and cause confusion to
     new comers when they are browsing the repositories. These modules cannot be
     deleted from the repository, because they contain history and they have been
     part of a build at one point.<br>
     In order to limit confusion and not lose history, the HEAD of stale modules
     should be replaced by a README file describing the status of the project.
     This file should also contain when the development has been stopped, against
     which version of eclipse it was working, and the CVS tag with the last
     working copy of the code.</li>
   <li><b>Changing Bugzilla components, milestones, targets, owners, etc.<br>
     </b>Send email to the Eclipse sysadmins with detailed instructions. When
     adding components, be sure to include: component name, component
     description, initial owner. For more details, see <a href="https://dev.eclipse.org/committers/help/howdoi.php">the
     Committer Self Service page</a>.</li>
   <li><b>Add new newsgroup.</b><br>
     Most projects have a single newsgroup, but in the exceptional case where an
     additional newsgroup is required, send email to the <a href="mailto:webmaster@eclipse.org">Eclipse
     sysadmins</a> with the newsgroup name in format eclipse.[top-level
     project].[shortname] and the newsgroup description.</li>
   <li><b>Add new mailing list.</b><br>
     <a href="https://dev.eclipse.org/mailman/listinfo/">Mailing lists</a> are
     resources used by committers to facilitate group communication. Normally, a
     single mailing list is created for a project; however, projects with several
     components can have several mailing lists. The main project mailing list is
     normally called projectname-dev, and component lists are called projectname-component.
     To add an additional mailing list, see <a href="https://dev.eclipse.org/committers/help/howdoi.php">the
     Committer Self-Service page</a> and then send email to the <a href="Eclipse%20sysadmins">Eclipse
     sysadmins</a> with the mailing list name, the long description (<a href="http://dev.eclipse.org/mailman/%20listinfo/platform-dev">see
     example</a>) and the short description (<a href="/mail/">see
     example</a>).</li>
   <li><b>Changing a mailing list.</b><br>
     A project can ask the <a href="Eclipse%20sysadmins">Eclipse
     sysadmins</a>  for mailing list changes (filters, digests, the sort of thing
     that mailman can do), or the project can ask the <a href="Eclipse%20sysadmins">Eclipse
     sysadmins</a>  to provide the project lead with self-service access to the
     list.</li>
   <li><b>Removing a newsgroup or mailing list.<br>
     </b>Send email to the <a href="mailto:webmaster@eclipse.org">Eclipse
     sysadmins</a>.</li>
   <li><b>Other.</b><br>
     The <a href="https://dev.eclipse.org/committers/">Committer self-service
     page</a> provides infrastructure reports, password changes, etc.</li>
 </ul>
 <h3>Schedule</h3>
 <p>There are many things that make Eclipse great. One is that there has been a
 strong emphasis on <a href="eclipse-quality.php">quality</a>; another is the
 equally strong emphasis on predictability. Even more important than having a
 schedule is having an honest schedule, so while projects should do their best
 not to change the schedule, they should work even harder to ensure that the
 schedule in an honest one. This is especially critical for Eclipse projects
 because the projects release extensible frameworks that other Eclipse members -
 individuals and ecosystem companies - build products and tools on top of. Those
 members make plans based on the Eclipse plans and thus changing the Eclipse
 plans can materially affect a large number of downstream players.</p>
 <p>The best scheduling algorithm for this kind of &quot;bottom of the dependency
 pile&quot; development is to under-promise and over-deliver. Promise less and
 promise it later than the team thinks it can be delivered, then deliver more and
 deliver earlier. This is especially important in open-source because the project
 wants to allow enough time for the community to provide lots of good feedback -
 feedback that will result in a really great framework and outstanding exemplary
 tools.</p>
 <h3>Release Review</h3>
 <p>Major releases continue to go through <a href="release-review.php">Release
 Reviews</a>. A major release is defined as a change in N or M of the N.M.P
 release numbering.</p>
 <ul>
   <li>A side note about release numbering: the Eclipse standard for release
     numbers is that the major number (N) changes upon breaking changes to the APIs,
     the minor number (M) changes when
     the APIs are the same but there is substantial new function, and the
     incremental number (P) changes
     for fix packs. Fix packs are API compatible, i.e., no change to the APIs.<br>
     The major number (N) may also change for significant new features without
     having breaking API changes. For example, if framework Foo versions 4.0,
     4.1, 4.2, and 4.3 has been available for a couple years, the latest release
     might have enough new significant features to justify version 5.0 even
     though the API compatibility would indicate version 4.4.</li>
   <li>A clarification of the interpretation of the Eclipse Development Process.
     The Process has a loop-back from the Release Review to the
     Validation/Incubation Phase (see figure 2 in the document). We have revised
     that loop-back to return to the Implementation/Mature Phase, i.e., baring
     any regression in openness, transparency, and process conformance, once a
     project has reached the Implementation/Mature Phase, it remains there.</li>
 </ul>

 <hr>
 <p><sup>1</sup>  This will be implemented by the end of 4Q2005.<br>
 <sup>2</sup> The threshold for &quot;major&quot; is somewhere less than 100
 LOC.</p>
 </div>
 </div>
 <?php
 	# Paste your HTML content between the EOHTML markers!
 	$html = ob_get_contents();
 	ob_end_clean();

 	# Generate the web page
 	$App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);
 ?>
	<?php require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); $App = new App(); $Nav = new Nav(); $Menu = new Menu(); include($App->getProjectCommon()); # All on the same line to unclutter the user's desktop'

	$pageTitle = "Implementation Phase";
	$pageKeywords = "development process";
	$pageAuthor = "Bjorn Freeman-Benson Nov 20/05";

	ob_start();
	?>
	<div id="maincontent">
	<div id="midcolumn">

	<h1>Implementation Phase</h1>
	<p><i>version 030 - December 16, 2005</i></p>
	<p><a href="index.php">[This is one page of the larger document.]</a></p>
	<h2>Implementation (Mature) Phase</h2>
	<p>The project has demonstrated process, community, and technology and is now a
	mature member of the Eclipse Community. </p>
	<p>During the Implementation Phase, the project and project leadership maintain the
	project's infrastructure and continue to participate in the Eclipse Community
	using these, and other, mechanisms. The more frequent are:</p>
	<ul>
	<li><b>Status Reports.</b><br>
	All projects are required to report their status quarterly, if not more
	often. See the <a href="project-status-infrastructure.php">Project Status
	Reporting documentation</a> for more details.
	</li>
	<li><b>Milestone Releases.</b> Interim milestone and release candidate
	releases will be named n.nMn (e.g., 3.3M4) or n.nRCn (e.g., 4.1RC2). The n.n
	release numbering is reserved for the final Reviewed release. Additionally,
	all nightly, integration, milestone, release candidate, and final releases
	will be available via a download link found on the project's home page.</li>
	<li><b>Use the Correct Servers.</b> The eclipse.org infrastructure is solid
	and capable, but it is also capable of being brought to its knees by poor
	file placement. Projects will follow these guidelines:
	<ul>
	<li>Do not use viewcvs links in any web pages. Use normal links instead.
	Your project's web pages are stored in CVS and can be committed via CVS,
	but the links need to be normal links to reduce server load and enable
	load sharing.</li>
	<li>Do not place downloads or large files on the dev.eclipse.org
	machine (the web pages or the CVS).  Use the download.eclipse.org
	machine for all downloads - these machines are load balanced, mirrored,
	and have a separate bandwidth allotment.
	<ul>
	<li>Large files that change often should be placed on download
	servers.</li>
	<li>Files larger than 5Mbs should be placed on the download servers.</li>
	<li>All zip and gzip files should be placed on the download servers.</li>
	</ul>
	</li>
	</ul>
	</li>
	<li><b>Release Reviews.</b><br>
	Each major release (where <i>major</i> is defined as any release whose N or
	M version number changes in the N.M.P version number) must go through a <a href="release-review.php">Release
	Review</a>. Please schedule enough time to complete the Review and any
	potential remedial actions so as not to impact the project's release
	schedule.</li>
	<li><b>Continue encouraging the three communities.</b><br>
	As the project has completed its Validation Phase, this should already be
	happening, but I include it here for completeness. Continue
	to use the public mailing lists, respond in the newsgroups, write articles,
	staff code camps, triage the bugzilla, attend the Eclipse community events (<a href="http://www.eclipsecon.org/">EclipseCon</a>,
	<a href="/org/foundation/council.php">Council meetings</a>, ...) and so on.</li>
	<li>
	<p align="left" style="border-style: dotted; border-width: 2; padding-left: 5; padding-right: 5; padding-top: 2; padding-bottom: 2"><b>Following the Eclipse IP Policy.<br>
	</b>The <a href="/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf"> Eclipse IP Policy</a> requires
	<a href="/legal/committerguidelines.php"> certain due
	diligence and record keeping</a>.
	Small contributions in the form of bugzilla patches and the like can be
	committed directly to the code base (after the appropriate contributor
	information is recorded). Medium<sup>2</sup>, large, and all third-party (non-EPL
	licensed) contributions require the <a href="/legal/ContributionQuestionnairePart1-v1.0.htm"> Code Contribution
	Questionnaire</a> and
	additional record keeping (also see the <a href="/legal/EclipseLegalProcessPoster-v1.2.4.pdf">descriptive process flowchart poster</a>). Maintaining a current and accurate <a href="project-log.php"> Project Log</a> is
	the best way to keep this information up-to-date.<br>
	The due diligence process for new contributions takes, on average, four to
	six calendar weeks to complete. Thus we recommend limiting large and
	third-party contributions to the beginning of a release cycle rather than
	waiting to the end.</li>
	<li><b>Changing eclipse.org content.</b><br>
	The eclipse.org site has various news and announcement pages, as well as
	pages that describe the projects and top-level PMCs. To request an
	announcement or news or changes to these pages, send email to the <a href="mailto:emo@eclipse.org">EMO</a>.</li>
	<li><b>Add a new Committer.</b><br>
	After the Committer has been voted in using the top-level PMC's voting
	process, follow the <a href="/legal/newcommitter.html">New
	Committer Process</a>.</li>
	<li><b>Active Progress.</b><br>
	Project are expected to continue to be active: in development, in releases,
	in newsgroup and mailing list responses, and in the community more
	generally. Projects that become inactive will be reviewed and probably <a href="archived-phase.php">archived</a>.
	</li>
	<li><b>Use project name correctly.<br>
	</b>Every public use of the project name - in a web page, a presentation, a
	press release, an article, etc. - must follow the <a href="project-naming-policy.php">project
	naming guidelines</a>:
	<ul>
	<li>The first use of the project name uses the entire descriptive name
	and may include the optional nickname. For
	example, "The Eclipse Component Assembly
	Project (Buckminister)". Subsequent references to the project may use the
	nickname, e.g., "Buckminister".</li>
	<li>If the project is in <a href="proposal-phase.php">the Proposal Phase</a>
	or the <a href="validation-phase.php">Validation Phase</a>, that fact
	must be mentioned early in the document. For example, "The proposed
	Eclipse Phoenix project ..." or "The Buckminister project,
	being incubated at Eclipse, is releasing version 0.2 of their framework
	for early alpha feedback from the community."</li>
	</ul>
	</li>
	<li><b>Use brand graphics and watermarks correctly.<br>
	</b>Projects in proposal and validation/incubation stages must use the
	appropriate <a href="/projects/gazoo.php">Eclipse-branded graphics</a> (i.e.,
	the Eclipse Proposal graphic and the Eclipse Incubation graphic respectively) on
	their webpage and communications. Projects in the proposal phase must use the
	proposal watermark on their web
	pages.</li>
	<li><b>Follow the press guidelines.<br>
	</b>Projects must follow the <a href="/org/press-release/pressguidelines.htm">Eclipse
	Foundation press guidelines</a> in the preparation, wording, and
	dissemination of press releases.</li>
	</ul>
	<p>The less frequent are:</p>
	<ul>
	<li><b>Remove a Committer.</b><br>
	After the Committer has been removed using the top-level PMC's process, send
	email to the <a href="mailto:emo@eclipse.org">EMO</a> with: the name of the
	project and hosting top-level project, the full name and email address of
	the Committer, and the list of CVS packages to which commit accesses will be
	removed.</li>
	<li><b>Change a Committer's access.</b><br>
	The logical combination of Add and Remove accomplished via email by the
	top-level PMC to the <a href="mailto:webmaster@eclipse.org">Eclipse
	sysadmins</a>. Soon there will be a work request tracking system instead of
	emails, but for now emails will suffice.</li>
	<li><b>Change access rights on download server.</b><br>
	Send email to the <a href="mailto:webmaster@eclipse.org">Eclipse sysadmins</a>
	with the names of the Committers to be added/removed to/from the download
	server.</li>
	<li><b>Change root CVS components.</b><br>
	Send email to the <a href="mailto:webmaster@eclipse.org">Eclipse sysadmins</a>
	with the list of component changes and the list of Committers for the
	components.</li>
	<li><b>Marking stale CVS components.</b><br>
	As the projects evolve, some CVS modules become stale and cause confusion to
	new comers when they are browsing the repositories. These modules cannot be
	deleted from the repository, because they contain history and they have been
	part of a build at one point.<br>
	In order to limit confusion and not lose history, the HEAD of stale modules
	should be replaced by a README file describing the status of the project.
	This file should also contain when the development has been stopped, against
	which version of eclipse it was working, and the CVS tag with the last
	working copy of the code.</li>
	<li><b>Changing Bugzilla components, milestones, targets, owners, etc.<br>
	</b>Send email to the Eclipse sysadmins with detailed instructions. When
	adding components, be sure to include: component name, component
	description, initial owner. For more details, see <a href="https://dev.eclipse.org/committers/help/howdoi.php">the
	Committer Self Service page</a>.</li>
	<li><b>Add new newsgroup.</b><br>
	Most projects have a single newsgroup, but in the exceptional case where an
	additional newsgroup is required, send email to the <a href="mailto:webmaster@eclipse.org">Eclipse
	sysadmins</a> with the newsgroup name in format eclipse.[top-level
	project].[shortname] and the newsgroup description.</li>
	<li><b>Add new mailing list.</b><br>
	<a href="https://dev.eclipse.org/mailman/listinfo/">Mailing lists</a> are
	resources used by committers to facilitate group communication. Normally, a
	single mailing list is created for a project; however, projects with several
	components can have several mailing lists. The main project mailing list is
	normally called projectname-dev, and component lists are called projectname-component.
	To add an additional mailing list, see <a href="https://dev.eclipse.org/committers/help/howdoi.php">the
	Committer Self-Service page</a> and then send email to the <a href="Eclipse%20sysadmins">Eclipse
	sysadmins</a> with the mailing list name, the long description (<a href="http://dev.eclipse.org/mailman/%20listinfo/platform-dev">see
	example</a>) and the short description (<a href="/mail/">see
	example</a>).</li>
	<li><b>Changing a mailing list.</b><br>
	A project can ask the <a href="Eclipse%20sysadmins">Eclipse
	sysadmins</a> for mailing list changes (filters, digests, the sort of thing
	that mailman can do), or the project can ask the <a href="Eclipse%20sysadmins">Eclipse
	sysadmins</a> to provide the project lead with self-service access to the
	list.</li>
	<li><b>Removing a newsgroup or mailing list.<br>
	</b>Send email to the <a href="mailto:webmaster@eclipse.org">Eclipse
	sysadmins</a>.</li>
	<li><b>Other.</b><br>
	The <a href="https://dev.eclipse.org/committers/">Committer self-service
	page</a> provides infrastructure reports, password changes, etc.</li>
	</ul>
	<h3>Schedule</h3>
	<p>There are many things that make Eclipse great. One is that there has been a
	strong emphasis on <a href="eclipse-quality.php">quality</a>; another is the
	equally strong emphasis on predictability. Even more important than having a
	schedule is having an honest schedule, so while projects should do their best
	not to change the schedule, they should work even harder to ensure that the
	schedule in an honest one. This is especially critical for Eclipse projects
	because the projects release extensible frameworks that other Eclipse members -
	individuals and ecosystem companies - build products and tools on top of. Those
	members make plans based on the Eclipse plans and thus changing the Eclipse
	plans can materially affect a large number of downstream players.</p>
	<p>The best scheduling algorithm for this kind of "bottom of the dependency
	pile" development is to under-promise and over-deliver. Promise less and
	promise it later than the team thinks it can be delivered, then deliver more and
	deliver earlier. This is especially important in open-source because the project
	wants to allow enough time for the community to provide lots of good feedback -
	feedback that will result in a really great framework and outstanding exemplary
	tools.</p>
	<h3>Release Review</h3>
	<p>Major releases continue to go through <a href="release-review.php">Release
	Reviews</a>. A major release is defined as a change in N or M of the N.M.P
	release numbering.</p>
	<ul>
	<li>A side note about release numbering: the Eclipse standard for release
	numbers is that the major number (N) changes upon breaking changes to the APIs,
	the minor number (M) changes when
	the APIs are the same but there is substantial new function, and the
	incremental number (P) changes
	for fix packs. Fix packs are API compatible, i.e., no change to the APIs.<br>
	The major number (N) may also change for significant new features without
	having breaking API changes. For example, if framework Foo versions 4.0,
	4.1, 4.2, and 4.3 has been available for a couple years, the latest release
	might have enough new significant features to justify version 5.0 even
	though the API compatibility would indicate version 4.4.</li>
	<li>A clarification of the interpretation of the Eclipse Development Process.
	The Process has a loop-back from the Release Review to the
	Validation/Incubation Phase (see figure 2 in the document). We have revised
	that loop-back to return to the Implementation/Mature Phase, i.e., baring
	any regression in openness, transparency, and process conformance, once a
	project has reached the Implementation/Mature Phase, it remains there.</li>
	</ul>

	<hr>
	<p><sup>1</sup> This will be implemented by the end of 4Q2005.<br>
	<sup>2</sup> The threshold for "major" is somewhere less than 100
	LOC.</p>
	</div>
	</div>
	<?php
	# Paste your HTML content between the EOHTML markers!
	$html = ob_get_contents();
	ob_end_clean();

	# Generate the web page
	$App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);
	?>