dev_process/release-review.php - gerrit/www.eclipse.org/projects - Git at Google

 <?php
 	include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");

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

 	include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-after-definitions.php");
 ?>
     <div id="maincontent">
 	<div id="midcolumn">

 <h1>Release Review</h1>
 <p><i>version 018 - August 7, 2005</i></p>
 <p><a href="index.php">[This is one page of the larger document.]</a></p>
 <h2>Release Review</h2>

 <p> The Release Review is conducted before each major release to verify that the key goals of the release have been accomplished and to verify that all intellectual property rights issues have been
 resolved. For Eclipse projects with typical six week milestones, a plausible time for a release review is one to two weeks into the final six week period, i.e., four or five weeks before the release is scheduled to go live.<br>
 <br>
 The Release Review is attended by the EMO, the project leadership, and members of the Eclipse community.
 The Release Review process is described on the <a href="review-mechanisms.php">Review
 Mechanisms page</a>. The remainder of this page discusses the Review's content.<br>
 <br>
 The Release Review is the final review of the project, process, release and most
 importantly, the IP issues, against the characteristics that help ensure
 <a href="eclipse-quality.php"> Eclipse Quality</a>. In this context, Eclipse Quality means extensible frameworks and
 exemplary tools developed in an open, inclusive, and predictable process involving the entire community. We use this definition so that members of the Eclipse community and ecosystem can rely on and use the frameworks and tools in their work and their businesses, including direct use and use as building blocks of commercial products.</p>

       <p>
       A Release Review is a fairly comprehensive process. We anticipate that
       gathering the material for the review and preparing the slide is a
       non-trivial effort, but we believe that the introspection offered by this
       exercise is useful for the project and that the results are very useful
       for the community.&nbsp; </p>
       <p>The items to be covered in the Review include the following. The slide
       deck will probably average one or two slides on each of these bullets. (Note the use of the
       word &quot;summarize&quot; throughout this agenda. Judgment must be used
       to determine how much to include in each of these bullet items. At the
       project's request, the EMO will help determine the appropriate level of
       information.) </p>
 <blockquote><span style="background-color: #FFFFCC">Note that during the Release Review, the project leadership will personally
 assert/guarantee the veracity of the statements. The standard is especially high
   for the IP Issues because the project leadership are the ones who know whether the
   <a href="/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf"> IP
 Policy</a> has been followed rigorously or not. An obvious consequence of this is
 that the verbal report and written documents of the Release Review should not make statements
 that the project leadership cannot back up with facts.</span> </blockquote>
       <ul>
         <li>
           <b>Features.</b> Summarize the major features of this release as well
           as any other features that have generated significant discussion
           amongst the community during the development cycle. Compare the
           features against the Roadmap to understand the project's conformance
           or divergence (note: compare against the Project Plan section as the
           forward looking sections apply to the next release). References to existing New &amp; Noteworthy
           documentation is a useful addition to this summary.
           <ul>
             <li>
               <i><b><font color="#0080C0">Reason:</font></b> </i>The community will use this release and the
               ecosystem will build products on top of this release, and both
               need to know what features were included or excluded.
             </li>
           </ul>
         </li>
         <li>
           <b>Non-Code Aspects.</b> Summarize the state of the non-code aspects
           of the release including: user documentation, localization/externalization, examples,
           tutorials, articles, and so on. Have the existing artifacts been
           updated? Are there new artifacts? Have the obsolete ones been retired
           or at least marked as pertaining only to older material?
           <ul>
             <li>
               <i><b><font color="#0080C0">Reason:</font></b></i> The non-code aspects are essential for the
               wide-spread adoption of the release.</li>
           </ul>
         </li>
         <li>
           <b>APIs.</b> Certify that the APIs in this release are <i><a href="eclipse-quality.php">Eclipse
           Quality</a></i>. The project's Architecture Council representative will
           personally certify that the requirements for quality have been met
           and/or discuss any deficiences.
           <ul>
             <li>
               <i><b><font color="#0080C0">Reason:</font></b></i> Eclipse members build commercial tools on top of
               the extensible frameworks and thus the quality of the APIs is
               extremely important.</li>
           </ul>
         </li>
         <li><b>Tool Usability. </b>Summarize the usability of the tools.
           Usability in this sense is about using the tools to solve development
           problems, not the more academic sense of UI evaluation/testing.
           <ul>
             <li>
               <i><b><font color="#0080C0">Reason:</font></b></i>  Without usable
               tools, the project will not attract the user community necessary
               to enable the ecosystem.&nbsp;</li>
           </ul>
         </li>
         <li>
           <b>Architectural Issues.</b> Summarize the architectural quality of
           the release. Discuss the <i>intrinsic nature of being extensible</i>
           embodied by this project. Discuss issues such as unresolved overlap with other
           projects, unpaid &quot;merge debt&quot; from incorporating various
           components, and so on.
           <ul>
             <li><font color="#0080C0"><b>
               <i>Reason: </i></b></font>Eclipse members build commercial tools
               on top of the extensible frameworks and thus the quality of the
               architecture is important.</li>
           </ul>
         </li>
         <li>
           <b>End-of-Life.</b> Summarize the features (APIs and any significant
           user features)
           from previous releases that are being end-of-life'd in this release.
           End of life includes both deprecation and actual removal.
           <ul>
             <li>
               <i><b><font color="#0080C0">Reason:</font></b></i> The community builds products that rely on
               features and so they need to know when these features are
               changing.</li>
           </ul>
         </li>
         <li>
           <b>Bugzilla.</b> Summarize the bugzilla situation. How many bug
           records (defects and enhancements) have been
           opened/closed/deferred/new, etc? How many P1, P2, ..., bug records are
           outstanding?
           <ul>
             <li>
               <i><b><font color="#0080C0">Reason:</font></b></i> Summaries of the bugzilla records offer a glimpse
               into the project productivity. They also offer an estimate of the
               outstanding risk. And the summary is used to alert the community
               to known issues.</li>
           </ul>
         </li>
         <li>
           <b>Standards.</b> Summarize the standards compliance of this release.
           If the features are based on defined, pending, or ad-hoc standards,
           what is the state of those standards and what is the state of the
           support for those standards in this release.
           <ul>
             <li>
               <i><b><font color="#0080C0">Reason: </font></b></i>Eclipse is about building frameworks and tools
               based on standards, so we need to make sure that we are conforming
               to the appropriate standards.</li>
           </ul>
         </li>
         <li>
           <b>Schedule.</b> Discuss the initial schedule and any changes to the
           schedule over the course of the release, i.e., what the project team
           achieved. Discuss whether milestones were met or slipped.
           <ul>
             <li>
               <i><b><font color="#0080C0">Reason:</font></b></i> The community relies on consistent schedules from
               Eclipse so that projects and products can plan for the correct
               dependencies.</li>
           </ul>
         </li>
         <li>
           <b>Process.</b> Summarize the project's conformance to the <a href="/org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf">Eclipse
           Development Process</a> and to <a href="index.php">these guidelines</a>.
           Has this release been developed using open,
           transparent, permeable, and inclusive processes?&nbsp; Has this release followed
           its charter principles?&nbsp; Consider the use of bugzilla, the
           mailing lists, the newsgroups, conference calls, committer
           elections/removals, etc.
           <ul>
             <li>
               <i><b><font color="#0080C0">Reason:</font></b></i> It is important for Eclipse projects to build a
               community around the project, not just deliver code for a project.
               This review item is about the process of building the community.</li>
           </ul>
         </li>
         <li><b>Communities.</b> Summarize the project's development of its three
           communities. Consider the interactions on bugzilla, the
           mailing lists, the newsgroups, public conference calls, blogs, PR
           activities, code camps, conference tutorials, coordinating with other
           Eclipse projects and other open source projects (Apache, ObjectWeb,
           etc), ...
           <ul>
             <li>
               <i><b><font color="#0080C0">Reason:</font></b></i> It is important for Eclipse projects to build a
               community around the project, not just deliver code for a project.
               This review item is about the success of building a community.</li>
           </ul>
         </li>
         <li>
           <b>IP Issues.</b> As per the <a href="/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf">Eclipse
           IP Policy</a>, these steps must be done:
           <ol>
             <li>The project leadership verifies that:
               <ul>
                 <li>... that the about files and use licenses are in place as
                   per the <a href="/legal/guidetolegaldoc.php">Guidelines to
                   Legal Documentation</a>.</li>
                 <li>... all contributions (code, documentation, images,
               etc) has been committed by individuals who are either
               Members of the Foundation, or have signed the appropriate
               Committer Agreement. In either case, these are individuals who have
               signed, and are abiding by, the Eclipse IP Policy. (see below)</li>
                 <li>... that all
               significant contributions have been reviewed by the Foundation's
               legal staff. (see below)</li>
                 <li>... that all non-committer code contributions, including third-party libraries, have
               been documented in the release and reviewed by the Foundation's legal
               staff (see below)</li>
                 <li>... that all contribution questionnaires have been completed
                   (see below)</li>
                 <li>... the &quot;provider&quot; field of each plug-in is set to
               &quot;eclipse.org&quot;</li>
                 <li>... the &quot;copyright&quot; field of each plug-in is set to
               the copyright owner.</li>
               </ul>
             </li>
             <li>The PMC provides a <a href="project-log.php"> Project Log</a> that enumerates:
               <ol type="a">
                 <li>every piece of third party software including information on
                   the license</li>
                 <li>every major contribution</li>
                   <li>the name of every contributor including
                   non-committer contributions via bug fixes with bug #'s</li>
                   <li>the About files which contain any non-standard terms
                     (e.g., a reference to a license other than the EPL, etc)</li>
               </ol>
             </li>
             <li>The EMO will validate for (a) and (b) that contribution questionnaires
               have been properly submitted and EMO approvals have been
               completed.</li>
             <li>The Project Log is part of the Release Review documentation. It
               can be included in the slides or as a separate document.</li>
           </ol>
         </li>
         <li><b>IP Issues (II).</b> The EMO explicitly asks during the Release
           Review if any Member would like to assert that this release infringes
           their IP rights. If so, the EMO and the project will follow the
           Eclipse IP Policy in discussions with that Member.
           <ul>
             <li>
               <i><b><font color="#0080C0">Reason:</font></b></i> One of the important benefits that the Eclipse
               Foundation provides for its members is the consistent application
               of the <a href="/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf">Eclipse
               IP Policy</a> which helps ensure (but does not guarantee) that the
               framework and tools are useable in commercial products.&nbsp;</li>
           </ul>
         </li>
         <li>
           <b>Project Plan.</b> If there is a Project Plan (full or even a draft)
           for the next release, the final issue to cover in the Release Review
           is the unveiling of the new plan.
         </li>
         <li>
           <b>Release Review Version. </b>The slides should include reference to
           the version of this document the Review is based on.
           <ul>
             <li>
               <i><b><font color="#0080C0">Reason:</font></b></i>  The guidelines
               are continually evolving and a reader in the future will want to
               know what version of the guidelines were in place when the Release
               Review was completed.&nbsp;</li>
           </ul>
         </li>
       </ul>
       <p>Example slide decks can be found in the <a href="/projects/previous-release-reviews.php">Release
       Review archives</a>. </p>
       <p>
       After the public Release Review, the EMO (and, if appropriate, the parent
       PMC) consider the community feedback and announce the result: </p>
       <ul>
         <li>
           Pass - the review is acceptable and the release should proceed
         </li>
         <li>
           Postpone -&nbsp;issues have arisen that must be solved before the
           release proceeds
         </li>
         <li>
           Pass w/ Notes - the release has some issues that need to be addressed,
           but they can be addressed with release notes and/or documentation
         </li>
         <li>
           Pass w/ Issues - the release has some issues, but they can be
           addressed in a future release as agreed to in the review
         </li>
         <li>
           Fail - there are significant problems with the release and/or the
           project.
         </li>
       </ul>
 <p>After a successful Release Review, the project continues in the <a href="implementation-phase.php">Implementation
 Phase</a>.</p>

 <?php
 	include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
 ?>
	<?php
	include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-before-definitions.php");

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

	include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-after-definitions.php");
	?>
	<div id="maincontent">
	<div id="midcolumn">

	<h1>Release Review</h1>
	<p><i>version 018 - August 7, 2005</i></p>
	<p><a href="index.php">[This is one page of the larger document.]</a></p>
	<h2>Release Review</h2>

	<p> The Release Review is conducted before each major release to verify that the key goals of the release have been accomplished and to verify that all intellectual property rights issues have been
	resolved. For Eclipse projects with typical six week milestones, a plausible time for a release review is one to two weeks into the final six week period, i.e., four or five weeks before the release is scheduled to go live.<br>
	<br>
	The Release Review is attended by the EMO, the project leadership, and members of the Eclipse community.
	The Release Review process is described on the <a href="review-mechanisms.php">Review
	Mechanisms page</a>. The remainder of this page discusses the Review's content.<br>
	<br>
	The Release Review is the final review of the project, process, release and most
	importantly, the IP issues, against the characteristics that help ensure
	<a href="eclipse-quality.php"> Eclipse Quality</a>. In this context, Eclipse Quality means extensible frameworks and
	exemplary tools developed in an open, inclusive, and predictable process involving the entire community. We use this definition so that members of the Eclipse community and ecosystem can rely on and use the frameworks and tools in their work and their businesses, including direct use and use as building blocks of commercial products.</p>

	<p>
	A Release Review is a fairly comprehensive process. We anticipate that
	gathering the material for the review and preparing the slide is a
	non-trivial effort, but we believe that the introspection offered by this
	exercise is useful for the project and that the results are very useful
	for the community.  </p>
	<p>The items to be covered in the Review include the following. The slide
	deck will probably average one or two slides on each of these bullets. (Note the use of the
	word "summarize" throughout this agenda. Judgment must be used
	to determine how much to include in each of these bullet items. At the
	project's request, the EMO will help determine the appropriate level of
	information.) </p>
	<blockquote><span style="background-color: #FFFFCC">Note that during the Release Review, the project leadership will personally
	assert/guarantee the veracity of the statements. The standard is especially high
	for the IP Issues because the project leadership are the ones who know whether the
	<a href="/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf"> IP
	Policy</a> has been followed rigorously or not. An obvious consequence of this is
	that the verbal report and written documents of the Release Review should not make statements
	that the project leadership cannot back up with facts.</span> </blockquote>
	<ul>
	<li>
	<b>Features.</b> Summarize the major features of this release as well
	as any other features that have generated significant discussion
	amongst the community during the development cycle. Compare the
	features against the Roadmap to understand the project's conformance
	or divergence (note: compare against the Project Plan section as the
	forward looking sections apply to the next release). References to existing New & Noteworthy
	documentation is a useful addition to this summary.
	<ul>
	<li>
	<i><b><font color="#0080C0">Reason:</font></b> </i>The community will use this release and the
	ecosystem will build products on top of this release, and both
	need to know what features were included or excluded.
	</li>
	</ul>
	</li>
	<li>
	<b>Non-Code Aspects.</b> Summarize the state of the non-code aspects
	of the release including: user documentation, localization/externalization, examples,
	tutorials, articles, and so on. Have the existing artifacts been
	updated? Are there new artifacts? Have the obsolete ones been retired
	or at least marked as pertaining only to older material?
	<ul>
	<li>
	<i><b><font color="#0080C0">Reason:</font></b></i> The non-code aspects are essential for the
	wide-spread adoption of the release.</li>
	</ul>
	</li>
	<li>
	<b>APIs.</b> Certify that the APIs in this release are <i><a href="eclipse-quality.php">Eclipse
	Quality</a></i>. The project's Architecture Council representative will
	personally certify that the requirements for quality have been met
	and/or discuss any deficiences.
	<ul>
	<li>
	<i><b><font color="#0080C0">Reason:</font></b></i> Eclipse members build commercial tools on top of
	the extensible frameworks and thus the quality of the APIs is
	extremely important.</li>
	</ul>
	</li>
	<li><b>Tool Usability. </b>Summarize the usability of the tools.
	Usability in this sense is about using the tools to solve development
	problems, not the more academic sense of UI evaluation/testing.
	<ul>
	<li>
	<i><b><font color="#0080C0">Reason:</font></b></i> Without usable
	tools, the project will not attract the user community necessary
	to enable the ecosystem. </li>
	</ul>
	</li>
	<li>
	<b>Architectural Issues.</b> Summarize the architectural quality of
	the release. Discuss the <i>intrinsic nature of being extensible</i>
	embodied by this project. Discuss issues such as unresolved overlap with other
	projects, unpaid "merge debt" from incorporating various
	components, and so on.
	<ul>
	<li><font color="#0080C0"><b>
	<i>Reason: </i></b></font>Eclipse members build commercial tools
	on top of the extensible frameworks and thus the quality of the
	architecture is important.</li>
	</ul>
	</li>
	<li>
	<b>End-of-Life.</b> Summarize the features (APIs and any significant
	user features)
	from previous releases that are being end-of-life'd in this release.
	End of life includes both deprecation and actual removal.
	<ul>
	<li>
	<i><b><font color="#0080C0">Reason:</font></b></i> The community builds products that rely on
	features and so they need to know when these features are
	changing.</li>
	</ul>
	</li>
	<li>
	<b>Bugzilla.</b> Summarize the bugzilla situation. How many bug
	records (defects and enhancements) have been
	opened/closed/deferred/new, etc? How many P1, P2, ..., bug records are
	outstanding?
	<ul>
	<li>
	<i><b><font color="#0080C0">Reason:</font></b></i> Summaries of the bugzilla records offer a glimpse
	into the project productivity. They also offer an estimate of the
	outstanding risk. And the summary is used to alert the community
	to known issues.</li>
	</ul>
	</li>
	<li>
	<b>Standards.</b> Summarize the standards compliance of this release.
	If the features are based on defined, pending, or ad-hoc standards,
	what is the state of those standards and what is the state of the
	support for those standards in this release.
	<ul>
	<li>
	<i><b><font color="#0080C0">Reason: </font></b></i>Eclipse is about building frameworks and tools
	based on standards, so we need to make sure that we are conforming
	to the appropriate standards.</li>
	</ul>
	</li>
	<li>
	<b>Schedule.</b> Discuss the initial schedule and any changes to the
	schedule over the course of the release, i.e., what the project team
	achieved. Discuss whether milestones were met or slipped.
	<ul>
	<li>
	<i><b><font color="#0080C0">Reason:</font></b></i> The community relies on consistent schedules from
	Eclipse so that projects and products can plan for the correct
	dependencies.</li>
	</ul>
	</li>
	<li>
	<b>Process.</b> Summarize the project's conformance to the <a href="/org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf">Eclipse
	Development Process</a> and to <a href="index.php">these guidelines</a>.
	Has this release been developed using open,
	transparent, permeable, and inclusive processes?  Has this release followed
	its charter principles?  Consider the use of bugzilla, the
	mailing lists, the newsgroups, conference calls, committer
	elections/removals, etc.
	<ul>
	<li>
	<i><b><font color="#0080C0">Reason:</font></b></i> It is important for Eclipse projects to build a
	community around the project, not just deliver code for a project.
	This review item is about the process of building the community.</li>
	</ul>
	</li>
	<li><b>Communities.</b> Summarize the project's development of its three
	communities. Consider the interactions on bugzilla, the
	mailing lists, the newsgroups, public conference calls, blogs, PR
	activities, code camps, conference tutorials, coordinating with other
	Eclipse projects and other open source projects (Apache, ObjectWeb,
	etc), ...
	<ul>
	<li>
	<i><b><font color="#0080C0">Reason:</font></b></i> It is important for Eclipse projects to build a
	community around the project, not just deliver code for a project.
	This review item is about the success of building a community.</li>
	</ul>
	</li>
	<li>
	<b>IP Issues.</b> As per the <a href="/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf">Eclipse
	IP Policy</a>, these steps must be done:
	<ol>
	<li>The project leadership verifies that:
	<ul>
	<li>... that the about files and use licenses are in place as
	per the <a href="/legal/guidetolegaldoc.php">Guidelines to
	Legal Documentation</a>.</li>
	<li>... all contributions (code, documentation, images,
	etc) has been committed by individuals who are either
	Members of the Foundation, or have signed the appropriate
	Committer Agreement. In either case, these are individuals who have
	signed, and are abiding by, the Eclipse IP Policy. (see below)</li>
	<li>... that all
	significant contributions have been reviewed by the Foundation's
	legal staff. (see below)</li>
	<li>... that all non-committer code contributions, including third-party libraries, have
	been documented in the release and reviewed by the Foundation's legal
	staff (see below)</li>
	<li>... that all contribution questionnaires have been completed
	(see below)</li>
	<li>... the "provider" field of each plug-in is set to
	"eclipse.org"</li>
	<li>... the "copyright" field of each plug-in is set to
	the copyright owner.</li>
	</ul>
	</li>
	<li>The PMC provides a <a href="project-log.php"> Project Log</a> that enumerates:
	<ol type="a">
	<li>every piece of third party software including information on
	the license</li>
	<li>every major contribution</li>
	<li>the name of every contributor including
	non-committer contributions via bug fixes with bug #'s</li>
	<li>the About files which contain any non-standard terms
	(e.g., a reference to a license other than the EPL, etc)</li>
	</ol>
	</li>
	<li>The EMO will validate for (a) and (b) that contribution questionnaires
	have been properly submitted and EMO approvals have been
	completed.</li>
	<li>The Project Log is part of the Release Review documentation. It
	can be included in the slides or as a separate document.</li>
	</ol>
	</li>
	<li><b>IP Issues (II).</b> The EMO explicitly asks during the Release
	Review if any Member would like to assert that this release infringes
	their IP rights. If so, the EMO and the project will follow the
	Eclipse IP Policy in discussions with that Member.
	<ul>
	<li>
	<i><b><font color="#0080C0">Reason:</font></b></i> One of the important benefits that the Eclipse
	Foundation provides for its members is the consistent application
	of the <a href="/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf">Eclipse
	IP Policy</a> which helps ensure (but does not guarantee) that the
	framework and tools are useable in commercial products. </li>
	</ul>
	</li>
	<li>
	<b>Project Plan.</b> If there is a Project Plan (full or even a draft)
	for the next release, the final issue to cover in the Release Review
	is the unveiling of the new plan.
	</li>
	<li>
	<b>Release Review Version. </b>The slides should include reference to
	the version of this document the Review is based on.
	<ul>
	<li>
	<i><b><font color="#0080C0">Reason:</font></b></i> The guidelines
	are continually evolving and a reader in the future will want to
	know what version of the guidelines were in place when the Release
	Review was completed. </li>
	</ul>
	</li>
	</ul>
	<p>Example slide decks can be found in the <a href="/projects/previous-release-reviews.php">Release
	Review archives</a>. </p>
	<p>
	After the public Release Review, the EMO (and, if appropriate, the parent
	PMC) consider the community feedback and announce the result: </p>
	<ul>
	<li>
	Pass - the review is acceptable and the release should proceed
	</li>
	<li>
	Postpone - issues have arisen that must be solved before the
	release proceeds
	</li>
	<li>
	Pass w/ Notes - the release has some issues that need to be addressed,
	but they can be addressed with release notes and/or documentation
	</li>
	<li>
	Pass w/ Issues - the release has some issues, but they can be
	addressed in a future release as agreed to in the review
	</li>
	<li>
	Fail - there are significant problems with the release and/or the
	project.
	</li>
	</ul>
	<p>After a successful Release Review, the project continues in the <a href="implementation-phase.php">Implementation
	Phase</a>.</p>

	<?php
	include($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/include-end-of-page.php");
	?>