incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From c..@apache.org
Subject svn commit: r608294 - in /incubator/public/trunk: site-author/guides/releasemanagement.xml site-publish/guides/releasemanagement.html
Date Thu, 03 Jan 2008 00:34:08 GMT
Author: clr
Date: Wed Jan  2 16:34:03 2008
New Revision: 608294

URL: http://svn.apache.org/viewvc?rev=608294&view=rev
Log:
Improving release management

Modified:
    incubator/public/trunk/site-author/guides/releasemanagement.xml
    incubator/public/trunk/site-publish/guides/releasemanagement.html

Modified: incubator/public/trunk/site-author/guides/releasemanagement.xml
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-author/guides/releasemanagement.xml?rev=608294&r1=608293&r2=608294&view=diff
==============================================================================
--- incubator/public/trunk/site-author/guides/releasemanagement.xml (original)
+++ incubator/public/trunk/site-author/guides/releasemanagement.xml Wed Jan  2 16:34:03 2008
@@ -45,12 +45,12 @@
 		</p>
 		<ul>
 	          <li>Publishing software has legal consequences. </li>
-	          <li>Most users interact with a project only through it's releases. 
+	          <li>Most users interact with a project only through its releases. 
 	          They are a public face of the project and are often the first chance 
 	          to make a good impression.</li>
         </ul>
         <p>
-Releases at Apache involve more ceremony than many other processes. Poor quality releases
impact
+Releases at Apache involve more ceremony than many other processes. Poor quality releases
reflect badly
 not only on the project but also the foundation as a whole. 
         </p>
 		</section>
@@ -61,7 +61,7 @@
             <section name='document-usage'><title>Usage</title>
             <p><strong>NOTE</strong> beta quality TODO: Improve PROSE,
check content</p>
             <p>
-        Apache release policy is minimal (though it's principles have some subtle consequences).

+        Apache release policy is minimal (though its principles have some subtle consequences).

         However, most projects have a lot more ceremony,
         rules and traditions to ensure high quality releases. These often evolve
         over time. Often projects realise too late that these need to be documented.
@@ -69,12 +69,12 @@
         Podlings can short circuit this process by starting out with written 
         release documentation. It is strongly recommended that Podlings invest
         time looking at the best practices recommended in this document. By selection
-        and modification sections of this document can be used to quickly and easily 
+        and modification, sections of this document can be used to quickly and easily 
         bootstrap a release guide.
             </p><p>
-        The minimum that Podlings need to demonstrate is that understand this policy in practice.
+        The minimum that Podlings need to demonstrate is to understand this policy in practice.
         In practice, Podlings should expect to be held to a higher standard. Apache projects
-        care about creating high quality releases. Releases are approved by an IPMC VOTE.
In order 
+        care about creating high quality releases. Releases are approved by an Incubator
PMC VOTE. In order 
         to achieve positive votes, qualities higher than just this minimum are usually required.
         The actual practical level tends to vary as each voter applies their own subjective
criteria.
             </p><p>
@@ -117,11 +117,11 @@
     		<p>
 The minimal formal requirements for an official ASF release are (contrary to rumor) minimal.
 A successful binding VOTE by a project means that the artifact is an official ASF release.
-Release approved by project must comply with the current ASF release policies.
+Releases approved by a podling must comply with the current ASF release policies.
 Those with binding votes must check that the release complies with these policies.
     		</p>
     		<p>
- In practice, most project adopt more ceremony than this minimum for a number of important
reasons. 
+ In practice, most projects adopt more ceremony than this minimum for a number of important
reasons. 
  			</p>
  			<p>
 ASF releases are often widely distributed and long lived. This document is not normative.
@@ -162,13 +162,13 @@
 </p>
         <p>
 Most projects find it difficult to issue quality releases without appointing a 
-<a href='glossay-release-manager'>release manager</a>. Typically,
+<a href='glossary-release-manager'>release manager</a>. Typically,
 release managers are elected by lazy consensus. Nominating oneself is not
 usually consider a <em>faux pas</em>.
 In the early stages of a release, they should take responsibility for organizations,
 in the middle stages of a release, for deciding which code will be included in the release,
 in the late stages for marshaling the VOTEs required for formal approval
-then finally for <a href='#glossay-cutting-release'>cutting the release</a>.
+then finally for <a href='#glossary-cutting-release'>cutting the release</a>.
 TODO: maybe be better in a time line
         </p>
        -->
@@ -177,7 +177,7 @@
     <section id='release-distribution'><title>Distributing Releases</title>
       <p>
       Once a release has been approved by the 
-      <a href='/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29'>Incubator
PMC (IPMC)</a>,
+      <a href='/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29'>Incubator
PMC</a>,
       it needs to be uploaded to the servers for wider distribution. A description of this
process and the policy
       governing it follows.
       </p>
@@ -202,7 +202,7 @@
         </li>
         <li>
         Infrastructure insists that releases are mirrored, permissions are correct and that
-        <a href='http://www.apache.org/dev/release-signing.html#keys-policy'>signatures+sums</a>

+        <a href='http://www.apache.org/dev/release-signing.html#keys-policy'>signatures+checksums</a>

         are uploaded for every artifact. 
         </li>
         </ul>
@@ -218,8 +218,11 @@
       <section id='understanding-distribution'><title>Understanding Release Distribution</title>
         <section id='understanding-upload'><title>Upload</title>
           <p>
-          The distribution upload location (<code>www.apache.org/dist</code>)
is the
+          The distribution upload location (<code>www.apache.org/dist</code>)
for all Apache projects is the
           <code>/www/www.apache.org/dist</code> directory on <code>people.apache.org</code>.
+          Each project (including the incubator) owns a directory inside the
+          dist directory. Podlings own a directory inside the incubator
+          directory.
           Release artifacts should be copied into this position in the normal way.
           </p>
         </section>
@@ -235,6 +238,10 @@
           In particular, a <a href='http://www.apache.org/dev/release-download-pages.html'>script</a>

           must be used to direct the download to an appropriate URL. The artifacts 
           are downloaded from machines outside Apache control so users must verify them.
+          While the release artifacts (gzipped tar files and zip jar files are
+          the most common artifacts) are mirrored, the checksums and
+          signature files (.asc and .md5 files) are <strong>never</strong>
+          mirrored.
           </p>
         </section>
         <section id='understanding-archiving'><title>Archiving</title>
@@ -258,7 +265,7 @@
             <p>
         One group is created by infrastructure for each top level project. All releases 
         by that project should be owned by that group. This group should have read
-        and write permissions. This ensures that each project can manage it's own releases.

+        and write permissions. This ensures that each project can manage its own releases.

         The world should have only read only permissions to avoid accidental modification.
         In short <code>-rw-rw-r--</code>.
             </p><p>
@@ -279,14 +286,14 @@
         > chgrp -R incubator *
             </source>
             <p>
-        If a podling graduates to a top level project then a new group will be created. 
+        When a podling graduates to a top level project, a new group will be created. 
         New releases will then use that group (as well as being located in a top level 
         subdirectory of <code>dist</code> rather than <code>dist/incubator</code>).
-        If a podling graduates as a subproject then the group of it's new parent project
+        If a podling graduates as a subproject then the group of its new parent project
         will then be used.
             </p>
           </section>
-          <section id='distribution-sums-sigs'><title>Sums And Signatures</title>
+          <section id='distribution-checksums-sigs'><title>Sums And Signatures</title>
             <p>
         Start by reading the <a href='http://www.apache.org/dev/release-signing.html'>guide</a>.
             </p><p>
@@ -313,7 +320,7 @@
         <a href='http://www.apache.org/dev/release-signing.html#apache-wot'>linked</a>

         to the Apache <a href='http://www.apache.org/dev/release-signing.html#web-of-trust'>web
of trust</a>. 
            </p><p>
-        Always upload the sums and signatures at the same time as the artifact.
+        Always upload the checksums and signatures at the same time as the artifact.
         This will ensure no false alarms from the infrastructure team. 
            </p>
           </section>
@@ -323,7 +330,7 @@
         guarantee that the modified artifact will be correctly archived or mirrored but
         a change to an existing artifact is the signature of an attack. 
             </p><p>
-        This applies only to release artifacts. It's expected that README's, NOTES and so
on 
+        This applies only to release artifacts. It's expected that README's, NOTES, KEYS,
and so on 
         may be updated.
             </p>
           </section>
@@ -334,17 +341,17 @@
           <li>Directory is <code>www.apache.org/dist/<em>podling</em></code></li>
           <li>Group is <code>incubator</code></li>
           <li>Permissions are group writable and world read-only</li>
-          <li>All artifacts have matching sums and signatures</li>
+          <li>All artifacts have matching checksums and signatures</li>
           <li>Old releases archived</li>
         </ul>
       </section>
       <section id='distribution-best-practice'><title>Best Practice</title>
         <section id='distribution-layout'><title>Layout</title>
           <p>
-            A podling is free to choose a suitable layout for it's released
+            A podling is free to choose a suitable layout for its released
             artifacts within <code>www.apache.org/dist/incubator/<em>podling</em></code>.
             It is recommended that standard layouts (commonly used by other projects) 
-            are studied and that the layout adopted is documented in the podling's 
+            be studied and that the layout adopted is documented in the podling's 
             release documentation. The descriptions which follow can be used as a 
             useful basis for this documentation
           </p><p>
@@ -354,7 +361,7 @@
           </p>
           <section id='distribution-layout-plain'><title>Plain Artifacts</title>
             <p>
-          All artifacts, sums and signatures should be placed in
+          All artifacts, checksums and signatures should be placed in
           <code>www.apache.org/dist/incubator/<em>podling</em></code>.
No release
           documentation is placed within the distribution directory.
             </p>
@@ -368,7 +375,7 @@
             As is traditional in some communities, some like to add notices 
             (such as <code>RELEASE_NOTES</code>, <code>README</code>

             and <code>CHANGES</code>) for each release. Note that from publicity
-            perspective it may be effective to include this information on the download page.
+            perspective it may be effective to include this information on the download page
as well as in the release itself.
             </p><p>
             The HTTPD runs with fancy indexing enabled. So, creating <code>HEADER.html</code>
and
             <code>FOOTER.html</code> documents allows the text of the index page
to be customised.
@@ -489,7 +496,7 @@
           </p><p>
           It is recommended that the download page is used to remind users that they
           need to verify releases and to give instructions on how they can do this.
-          Links provided to sums and signatures need to refer to the originals on
+          Links provided to checksums and signatures need to refer to the originals on
           <code>www.apache.org</code> and not the copies on the mirrors. More
           information can be found in the 
           <a href='http://www.apache.org/dev/release-signing.html'>signing guide</a>.
@@ -501,9 +508,9 @@
           See <a href='#signing'>signing best practice</a>.
           </p>
           <p>
-          Each podling should maintain it's own 
+          Each podling should maintain its own 
           <a href='http://www.apache.org/dev/release-signing.html#keys-policy'>KEYS</a>

-          file in the root it's subdirectory. All committers for the podling are encouraged

+          file in the root its subdirectory. All committers for the podling are encouraged

           to add their keys to their file.
           </p>
         </section>
@@ -1036,10 +1043,12 @@
         	TODO: svn is flexible. branches and tags with svn are not the same as with cvs.
         	</p>
         	<p>
-All releases should be built from a tag. It is occasionally necessary to rebuild
-releases many years later.
+All releases should be identified with a tag. It is occasionally necessary to rebuild
+releases many years later, and having a tag easily allows this to be done.
 Tagging is cheap and easy when using subversion.
-So, every release and candidate should be tagged. 
+So, every release should be tagged. Releases should be built from a tag, 
+or built from a stable branch (not trunk). If not built from a tag, the
+approved release candidate should be tagged.
         	</p>
         	<p>
 It is useful to adopt a consistent naming convention for tagging releases.
@@ -1091,8 +1100,8 @@
         	<p>
 It is important to review all library dependencies as part of the release process
 for compliance. Apache policy changes from time-to-time. A list should be 
-compiled of the project's dependencies, those shipped as binary libraries 
-and those shipped as source document together with the licenses for
+compiled of the project's dependencies, including those shipped as binary libraries 
+and those shipped as source together with the licenses for
 those dependencies. These lists should be checked against the latest policy documents.
         	</p>
         	<p>
@@ -1120,9 +1129,9 @@
         </section>
         <section id='best-practice-incubator-release-vote'><title>Incubator Release
Vote</title>
             <p>
-All releases by podlings must be approved by the TODO: link IPMC. The conventional process
-is for the podling to flow the usual Apache process (including TODO: link release vote)
-and then call for a IPMC VOTE on the TODO: link general incubator list.
+All releases by podlings must be approved by the TODO: link Incubator PMC. The conventional
process
+is for the podling to follow the usual Apache process (including TODO: link release vote)
+and then call for a Incubator PMC VOTE on the TODO: link general incubator list.
             </p>
             <p>
 The release manager should post the call for the VOTE. 
@@ -1362,7 +1371,7 @@
             </p>
         	<p>
 Release notes are a vital to for communication between an open source project 
-and it's users. They are often the first documentation a user will read. First
+and its users. They are often the first documentation a user will read. First
 impressions matter. Their content will often serve as the basis for TODO: link
 announcements and other TODO: link grassroots publicity.
         	</p>
@@ -1667,7 +1676,7 @@
 			</p>
 			<p>
 Any source which does not have a license header must be considered suspect 
-and it's provenance checked. There are several classes of source which do not require
+and its provenance checked. There are several classes of source which do not require
 license headers. It is useful to adopt a policy of documentation in this case perhaps
 by including a short header if the file is generated (say) or by creating a README 
 in the directory containing license information. This makes code auditing much easier.
@@ -1784,7 +1793,7 @@
 			</p>
 			<p>
 Be careful to check the voters against the appropriate list. Binding votes are cast by people
on the 
-appropriate committee. The list of <a href='#glossary-ipmc'>IPMC</a>ers is 
+appropriate committee. The list of <a href='#glossary-ipmc'>Incubator PMC</a>ers
is 
 <a href='http://incubator.apache.org/whoweare.html'>available</a> TODO: link
online. Note that 
 sometimes the online lists are out of date. TODO: link to foundation site.
 			</p>
@@ -1909,7 +1918,7 @@
          <section id='glossary-ccla'><title>Contributor License Agreement - Corporate</title>
             <p>
  A Corporate Contributor License Agreement (CCLA) is a contract between a corporation
- and Apache granting Apache rights to code contributed by it's employees. Some legal
+ and Apache granting Apache rights to code contributed by its employees. Some legal
  jurisdications do not allow software developers rights to code created even in their own
  time on their own machines. This applies to most US developers. A CCLA protected Apache
  and .
@@ -2026,7 +2035,7 @@
 An application that store manages issues reported in Apache products. TODO: links
         	</p>
         </section>
-        <section id='glossary-ipmc'><title>Incubator Project Management Committee
(IPMC)</title>
+        <section id='glossary-ipmc'><title>Incubator Project Management Committee
(Incubator PMC)</title>
             <p>
  The committee charged by the <a href='http://www.apache.org/foundation/board/'>board</a>

  with the management of the Apache Incubator Project.
@@ -2039,10 +2048,10 @@
 <a href='#glossary-pmc'>PMC</a>
                 </li>
                 <li>
- <a href='http://incubator.apache.org/whoweare.html'>Who Are The IPMC members?</a>
+ <a href='http://incubator.apache.org/whoweare.html'>Who Are The Incubator PMC members?</a>
                 </li>
                 <li>
-  <a href='http://incubator.apache.org/guides/pmc.html'>Guide For IPMC members</a>
+  <a href='http://incubator.apache.org/guides/pmc.html'>Guide For Incubator PMC members</a>
                 </li>
             </ul>
         </section>

Modified: incubator/public/trunk/site-publish/guides/releasemanagement.html
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-publish/guides/releasemanagement.html?rev=608294&r1=608293&r2=608294&view=diff
==============================================================================
--- incubator/public/trunk/site-publish/guides/releasemanagement.html (original)
+++ incubator/public/trunk/site-publish/guides/releasemanagement.html Wed Jan  2 16:34:03
2008
@@ -177,7 +177,7 @@
 Permissions
  </a>
 </li>
-<li><a href='#distribution-sums-sigs'>
+<li><a href='#distribution-checksums-sigs'>
 Sums And Signatures
  </a>
 </li>
@@ -598,7 +598,7 @@
  </a>
 </li>
 <li><a href='#glossary-ipmc'>
-Incubator Project Management Committee (IPMC)
+Incubator Project Management Committee (Incubator PMC)
  </a>
 </li>
 <li><a href='#glossary-pmc'>
@@ -641,12 +641,12 @@
 		</p>
 <ul>
 	          <li>Publishing software has legal consequences. </li>
-	          <li>Most users interact with a project only through it's releases. 
+	          <li>Most users interact with a project only through its releases. 
 	          They are a public face of the project and are often the first chance 
 	          to make a good impression.</li>
         </ul>
 <p>
-Releases at Apache involve more ceremony than many other processes. Poor quality releases
impact
+Releases at Apache involve more ceremony than many other processes. Poor quality releases
reflect badly
 not only on the project but also the foundation as a whole. 
         </p>
 </div>
@@ -663,7 +663,7 @@
 <div class="section-content">
 <p><strong>NOTE</strong> beta quality TODO: Improve PROSE, check content</p>
 <p>
-        Apache release policy is minimal (though it's principles have some subtle consequences).

+        Apache release policy is minimal (though its principles have some subtle consequences).

         However, most projects have a lot more ceremony,
         rules and traditions to ensure high quality releases. These often evolve
         over time. Often projects realise too late that these need to be documented.
@@ -672,13 +672,13 @@
         Podlings can short circuit this process by starting out with written 
         release documentation. It is strongly recommended that Podlings invest
         time looking at the best practices recommended in this document. By selection
-        and modification sections of this document can be used to quickly and easily 
+        and modification, sections of this document can be used to quickly and easily 
         bootstrap a release guide.
             </p>
 <p>
-        The minimum that Podlings need to demonstrate is that understand this policy in practice.
+        The minimum that Podlings need to demonstrate is to understand this policy in practice.
         In practice, Podlings should expect to be held to a higher standard. Apache projects
-        care about creating high quality releases. Releases are approved by an IPMC VOTE.
In order 
+        care about creating high quality releases. Releases are approved by an Incubator
PMC VOTE. In order 
         to achieve positive votes, qualities higher than just this minimum are usually required.
         The actual practical level tends to vary as each voter applies their own subjective
criteria.
             </p>
@@ -729,7 +729,7 @@
 <div class="section-content">
 <p>
       Once a release has been approved by the 
-      <a href="/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29">Incubator
PMC (IPMC)</a>,
+      <a href="/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29">Incubator
PMC</a>,
       it needs to be uploaded to the servers for wider distribution. A description of this
process and the policy
       governing it follows.
       </p>
@@ -749,7 +749,7 @@
         </li>
         <li>
         Infrastructure insists that releases are mirrored, permissions are correct and that
-        <a href="http://www.apache.org/dev/release-signing.html#keys-policy">signatures+sums</a>

+        <a href="http://www.apache.org/dev/release-signing.html#keys-policy">signatures+checksums</a>

         are uploaded for every artifact. 
         </li>
         </ul>
@@ -771,8 +771,11 @@
 </h4>
 <div class="section-content">
 <p>
-          The distribution upload location (<code>www.apache.org/dist</code>)
is the
+          The distribution upload location (<code>www.apache.org/dist</code>)
for all Apache projects is the
           <code>/www/www.apache.org/dist</code> directory on <code>people.apache.org</code>.
+          Each project (including the incubator) owns a directory inside the
+          dist directory. Podlings own a directory inside the incubator
+          directory.
           Release artifacts should be copied into this position in the normal way.
           </p>
 </div>
@@ -791,6 +794,10 @@
           In particular, a <a href="http://www.apache.org/dev/release-download-pages.html">script</a>

           must be used to direct the download to an appropriate URL. The artifacts 
           are downloaded from machines outside Apache control so users must verify them.
+          While the release artifacts (gzipped tar files and zip jar files are
+          the most common artifacts) are mirrored, the checksums and
+          signature files (.asc and .md5 files) are <strong>never</strong>
+          mirrored.
           </p>
 </div>
 <h4>
@@ -825,7 +832,7 @@
 <p>
         One group is created by infrastructure for each top level project. All releases 
         by that project should be owned by that group. This group should have read
-        and write permissions. This ensures that each project can manage it's own releases.

+        and write permissions. This ensures that each project can manage its own releases.

         The world should have only read only permissions to avoid accidental modification.
         In short <code>-rw-rw-r--</code>.
             </p>
@@ -848,15 +855,15 @@
             </code>
 </div>
 <p>
-        If a podling graduates to a top level project then a new group will be created. 
+        When a podling graduates to a top level project, a new group will be created. 
         New releases will then use that group (as well as being located in a top level 
         subdirectory of <code>dist</code> rather than <code>dist/incubator</code>).
-        If a podling graduates as a subproject then the group of it's new parent project
+        If a podling graduates as a subproject then the group of its new parent project
         will then be used.
             </p>
 </div>
 <h5> 
-   <a name="distribution-sums-sigs">Sums And Signatures</a> 
+   <a name="distribution-checksums-sigs">Sums And Signatures</a> 
 </h5> 
 <div class="section-content">
 <p>
@@ -889,7 +896,7 @@
         to the Apache <a href="http://www.apache.org/dev/release-signing.html#web-of-trust">web
of trust</a>. 
            </p>
 <p>
-        Always upload the sums and signatures at the same time as the artifact.
+        Always upload the checksums and signatures at the same time as the artifact.
         This will ensure no false alarms from the infrastructure team. 
            </p>
 </div>
@@ -903,7 +910,7 @@
         a change to an existing artifact is the signature of an attack. 
             </p>
 <p>
-        This applies only to release artifacts. It's expected that README's, NOTES and so
on 
+        This applies only to release artifacts. It's expected that README's, NOTES, KEYS,
and so on 
         may be updated.
             </p>
 </div>
@@ -917,7 +924,7 @@
           <li>Directory is <code>www.apache.org/dist/<em>podling</em></code></li>
           <li>Group is <code>incubator</code></li>
           <li>Permissions are group writable and world read-only</li>
-          <li>All artifacts have matching sums and signatures</li>
+          <li>All artifacts have matching checksums and signatures</li>
           <li>Old releases archived</li>
         </ul>
 </div>
@@ -930,10 +937,10 @@
 </h4>
 <div class="section-content">
 <p>
-            A podling is free to choose a suitable layout for it's released
+            A podling is free to choose a suitable layout for its released
             artifacts within <code>www.apache.org/dist/incubator/<em>podling</em></code>.
             It is recommended that standard layouts (commonly used by other projects) 
-            are studied and that the layout adopted is documented in the podling's 
+            be studied and that the layout adopted is documented in the podling's 
             release documentation. The descriptions which follow can be used as a 
             useful basis for this documentation
           </p>
@@ -947,7 +954,7 @@
 </h5> 
 <div class="section-content">
 <p>
-          All artifacts, sums and signatures should be placed in
+          All artifacts, checksums and signatures should be placed in
           <code>www.apache.org/dist/incubator/<em>podling</em></code>.
No release
           documentation is placed within the distribution directory.
             </p>
@@ -965,7 +972,7 @@
             As is traditional in some communities, some like to add notices 
             (such as <code>RELEASE_NOTES</code>, <code>README</code>

             and <code>CHANGES</code>) for each release. Note that from publicity
-            perspective it may be effective to include this information on the download page.
+            perspective it may be effective to include this information on the download page
as well as in the release itself.
             </p>
 <p>
             The HTTPD runs with fancy indexing enabled. So, creating <code>HEADER.html</code>
and
@@ -1107,7 +1114,7 @@
 <p>
           It is recommended that the download page is used to remind users that they
           need to verify releases and to give instructions on how they can do this.
-          Links provided to sums and signatures need to refer to the originals on
+          Links provided to checksums and signatures need to refer to the originals on
           <code>www.apache.org</code> and not the copies on the mirrors. More
           information can be found in the 
           <a href="http://www.apache.org/dev/release-signing.html">signing guide</a>.
@@ -1122,9 +1129,9 @@
           See <a href="#signing">signing best practice</a>.
           </p>
 <p>
-          Each podling should maintain it's own 
+          Each podling should maintain its own 
           <a href="http://www.apache.org/dev/release-signing.html#keys-policy">KEYS</a>

-          file in the root it's subdirectory. All committers for the podling are encouraged

+          file in the root its subdirectory. All committers for the podling are encouraged

           to add their keys to their file.
           </p>
 </div>
@@ -1740,10 +1747,12 @@
         	TODO: svn is flexible. branches and tags with svn are not the same as with cvs.
         	</p>
 <p>
-All releases should be built from a tag. It is occasionally necessary to rebuild
-releases many years later.
+All releases should be identified with a tag. It is occasionally necessary to rebuild
+releases many years later, and having a tag easily allows this to be done.
 Tagging is cheap and easy when using subversion.
-So, every release and candidate should be tagged. 
+So, every release should be tagged. Releases should be built from a tag, 
+or built from a stable branch (not trunk). If not built from a tag, the
+approved release candidate should be tagged.
         	</p>
 <p>
 It is useful to adopt a consistent naming convention for tagging releases.
@@ -1806,8 +1815,8 @@
 <p>
 It is important to review all library dependencies as part of the release process
 for compliance. Apache policy changes from time-to-time. A list should be 
-compiled of the project's dependencies, those shipped as binary libraries 
-and those shipped as source document together with the licenses for
+compiled of the project's dependencies, including those shipped as binary libraries 
+and those shipped as source together with the licenses for
 those dependencies. These lists should be checked against the latest policy documents.
         	</p>
 <p>
@@ -1841,9 +1850,9 @@
 </h3>
 <div class="section-content">
 <p>
-All releases by podlings must be approved by the TODO: link IPMC. The conventional process
-is for the podling to flow the usual Apache process (including TODO: link release vote)
-and then call for a IPMC VOTE on the TODO: link general incubator list.
+All releases by podlings must be approved by the TODO: link Incubator PMC. The conventional
process
+is for the podling to follow the usual Apache process (including TODO: link release vote)
+and then call for a Incubator PMC VOTE on the TODO: link general incubator list.
             </p>
 <p>
 The release manager should post the call for the VOTE. 
@@ -2126,7 +2135,7 @@
             </p>
 <p>
 Release notes are a vital to for communication between an open source project 
-and it's users. They are often the first documentation a user will read. First
+and its users. They are often the first documentation a user will read. First
 impressions matter. Their content will often serve as the basis for TODO: link
 announcements and other TODO: link grassroots publicity.
         	</p>
@@ -2471,7 +2480,7 @@
 			</p>
 <p>
 Any source which does not have a license header must be considered suspect 
-and it's provenance checked. There are several classes of source which do not require
+and its provenance checked. There are several classes of source which do not require
 license headers. It is useful to adopt a policy of documentation in this case perhaps
 by including a short header if the file is generated (say) or by creating a README 
 in the directory containing license information. This makes code auditing much easier.
@@ -2600,7 +2609,7 @@
 			</p>
 <p>
 Be careful to check the voters against the appropriate list. Binding votes are cast by people
on the 
-appropriate committee. The list of <a href="#glossary-ipmc">IPMC</a>ers is 
+appropriate committee. The list of <a href="#glossary-ipmc">Incubator PMC</a>ers
is 
 <a href="http://incubator.apache.org/whoweare.html">available</a> TODO: link
online. Note that 
 sometimes the online lists are out of date. TODO: link to foundation site.
 			</p>
@@ -2752,7 +2761,7 @@
 <div class="section-content">
 <p>
  A Corporate Contributor License Agreement (CCLA) is a contract between a corporation
- and Apache granting Apache rights to code contributed by it's employees. Some legal
+ and Apache granting Apache rights to code contributed by its employees. Some legal
  jurisdications do not allow software developers rights to code created even in their own
  time on their own machines. This applies to most US developers. A CCLA protected Apache
  and .
@@ -2918,7 +2927,7 @@
         	</p>
 </div>
 <h3>
-   <a name="glossary-ipmc">Incubator Project Management Committee (IPMC)</a>
+   <a name="glossary-ipmc">Incubator Project Management Committee (Incubator PMC)</a>
 </h3>
 <div class="section-content">
 <p>
@@ -2933,10 +2942,10 @@
 <a href="#glossary-pmc">PMC</a>
                 </li>
                 <li>
- <a href="http://incubator.apache.org/whoweare.html">Who Are The IPMC members?</a>
+ <a href="http://incubator.apache.org/whoweare.html">Who Are The Incubator PMC members?</a>
                 </li>
                 <li>
-  <a href="http://incubator.apache.org/guides/pmc.html">Guide For IPMC members</a>
+  <a href="http://incubator.apache.org/guides/pmc.html">Guide For Incubator PMC members</a>
                 </li>
             </ul>
 </div>



---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org
For additional commands, e-mail: cvs-help@incubator.apache.org


Mime
View raw message