incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rdon...@apache.org
Subject svn commit: r607757 - in /incubator/public/trunk: site-author/guides/releasemanagement.xml site-publish/guides/releasemanagement.html
Date Mon, 31 Dec 2007 17:18:17 GMT
Author: rdonkin
Date: Mon Dec 31 09:18:14 2007
New Revision: 607757

URL: http://svn.apache.org/viewvc?rev=607757&view=rev
Log:
First draft (partial) of release distribution documentation.

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=607757&r1=607756&r2=607757&view=diff
==============================================================================
--- incubator/public/trunk/site-author/guides/releasemanagement.xml (original)
+++ incubator/public/trunk/site-author/guides/releasemanagement.xml Mon Dec 31 09:18:14 2007
@@ -53,10 +53,36 @@
 not only on the project but also the foundation as a whole. 
         </p>
 		</section>
-		<section name='apache-releases'><title>Organization</title>
+		<section name='organisation'><title>Organization</title>
 			<p>
 			TODO: describe organization of this document.
 			</p>
+            <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).

+        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.
+            </p><p>
+        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 
+        bootstrap a release guide.
+            </p><p>
+        The minimum that Podlings need to demonstrate is that 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 
+        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>
+        This document is descriptive not normative. It describes best practices. Policy is
defined
+        elsewhere. Podlings are free to accept or reject any of the recommendations. Enquiries
may 
+        be expected about novel or unusual practices. Best practice evolves. New ideas may
be patched
+        in. 
+            </p>
+            </section>
 		</section>
         <section id='help'><title>Help Wanted!</title>
     <p>
@@ -75,6 +101,9 @@
         <p>
         TODO: links to project management books.
         </p>
+        <ul>
+          <li>Apache <a href='http://www.apache.org/dev/#releases'>Release Management</a></li>
+        </ul>
     </section>
     </section>
     <section id='guidelines'><title>Guidelines</title>
@@ -143,63 +172,205 @@
         </p>
        -->
     </section>
-    <!--
-    <section id='distribution'>
+    
+    <section id='release-distribution'><title>Distributing Releases</title>
+    
+      <section id='distribution-policy-overview'><title>Policy Overview</title>
         <p>
-        Incubator releases <a href='TODO'>should</a> be <a href='TODO'>distributed</a>
through 
-        <code>www.apache.org/dist/incubator</code>.
-        </p><p>
-        policy is really pretty simple. the incubator insists that artifacts
-go under w.a.o/dist/incubator/uima. infrastructure insists that
-releases are mirrored, permissions are correct and that
-signatures+sums are uploaded for every artifact. the rest is up to the
-community to decide.
-        </p><p>
-most projects have a lot more ceremony, rules and traditions. these
-often evolve over time and it is common for projects to release too
-late that they need to be documented. podlings should be able to short
-circuit this process by taking a look at the documented best practices
-and picking out the ones they like. these can form the basis of a
-release management document for the podling. it's easier to modify and
-add new practices than to start from nothing.
-        <p></p>
-        Documenting release management processes is important and often neglected. 
-        
-        </p><p>
-        A podling is free to choose a suitable layout. However, it is recommended that the
standard layouts
-        are studied. A podling should document it's layout (feel to start with the
-        prose in this document or from the Apache guides).
-        </p>   <p>
-        HTTPD tricks - HEADER.html FOOTER.html
-        </p><p>
-        Permissions: world read, group and owner read and write. EXAMPLE
-        One group is created by infrastructure for each top level project. All releases by
that project
-        should be owned by that group. That ensures that each project has the permissions
required
-        to manage it's own releases without active involvement by infrastructure.
-        </p><p>
-        All podling releases is an Incubator project release and so the artifacts need to
be owned by the
-        incubator group. TODO example.
-        If a podling graduates as a top level project then a new grop will be created. Then
new releases should
-        use that group (as well as being located in a top level subdirectory of dist rather
than dist/incubator).
-        If a podlng graduates as a subproject then the releases will be contained in a subdirectory
of that project's
-        top level dist directory and will use that project's group. TODO example.
-        </p><p>
-        Please check the permissions
-        TODO add to check list.
+        Distribution policy is simple:
         </p>
+        <ul>
+        <li>
+        The Incubator 
+        <a href='/incubation/Incubation_Policy.html#Releases'>insists</a> 
+        that artifacts for <em>podling</em> are contained within
+        <code>www.apache.org/dist/incubator/podling</code>. 
+        </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>

+        are uploaded for every artifact. 
+        </li>
+        </ul>
         <p>
-        One a release artifact has been uploaded, it must never be modified. If a change
is required then
-        a new release should be created with a new release number. 
-        </p><p>
-        This applies only to release artifacts. It's usual that README's, NOTES and so on
are updated with 
-        each release.
+        The rest is up to the community to decide and that's quite a lot. 
+        Documenting the release management processes is important and often neglected. 
+        It is 
+        <a href='#document-usage'>strongly
+        recommended</a> that the rest of this section is used as the basis for a written
release
+        guide for the podling. 
         </p>
-        <section id='archiving'>
+      </section>
+      <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
+          <code>/www/www.apache.org/dist</code> directory on <code>people.apache.org</code>.
+          Release artifacts should be copied into this position in the normal way.
+          </p>
+        </section>
+        <section id='understanding-mirroring'><title>Mirroring</title>
+        </section>
+        <section id='understanding-archiving'><title>Archiving</title>
+          <p>
+          All Apache releases form an important part of the history of a project.
+          They are therefore archived with the aim of preserving them indefinitely
+          for future reference. 
+          </p><p>
+          All artifacts within <code>www.apache.org/dist</code> will be automatically
+          archived. When a new artifact is uploaded, it will be sync'd to the archive.
+          When an artifacts is deleted from live distribution, it will
+          remain in the archives. See 
+          <a href='http://www.apache.org/dev/release.html#how-to-archive'>how to archive</a>.
+          </p>
+        </section>
+        <section id='understanding-security'><title>Security</title>
+          <section id='distribution-permissions'><title>Permissions</title>
+            <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.

+        The world should have only read only permissions to avoid accidental modification.
+        In short <code>-rw-rw-r--</code>.
+            </p><p>
+        Each podling release is a release of the Incubator project. So, all files should

+        be:
+            </p>
+            <ul>
+        <li>owned by the <code>incubator</code> group</li>
+        <li>be group writable</li>
+        <li>be read only for the world</li>
+            </ul>
             <p>
-            Releases are autoarchived. When an artifact is uploaded, it will be sync'd to
the archives. 
-            When an artifact is deleted from live distribution, it will not be deleted from
the archives.
+        To do this from the top level:
             </p>
+            <source>
+        > chmod -R o-wx *
+        > chmod -R g+rw *
+        > chgrp -R incubator *
+            </source>
+            <p>
+        If a podling graduates to a top level project then 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
+        will then be used.
+            </p>
+          </section>
+          <section id='distribution-sums-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>
+        Sums are a convenient and simple way for users to verify releases.
+        Signatures play a critical role in ensuring security for releases. 
+            </p><p>
+        If a release is signed by a key that is strongly connected to the 
+        <a href='http://www.apache.org/dev/release-signing.html#web-of-trust'>Apache
web of trust</a>
+        then it can be <a href='http://www.apache.org/dev/release-signing.html#web-of-trust'>verified</a>

+        that a file has not been modified (by anyone without access to
+        the corresponding private key). It is crucial that new release managers
+        ensure:
+          </p>
+          <ul>
+            <li>that the code signing private key is 
+        <a href='http://www.apache.org/dev/release-signing.html#private-key-protection'>kept
safe</a>.</li>
+            <li>that the <a href='http://www.apache.org/dev/release-signing.html#keys-policy'><code>KEYS</code></a>

+            file contains the public key</li>
+         </ul>
+           <p>
+        It is important that the key is linked to the Apache web of trust by attending a
+        <a href='http://www.apache.org/dev/new-committers-guide.html#pgp'>face-to-face
keysigning</a>.
+           </p>
+          </section>
+          <section id='distribution-modifications'><title>Modifications</title>
+            <p>
+        Once an artifact has been uploaded, it must never be modified. Not only is there
no
+        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 usual that README's, NOTES and so on

+        are updated with each release.
+            </p>
+          </section>
+        </section>
+      </section>
+      <section id='distribution-check-list'>
+        <ul>
+          <li>Check group is <code>incubator</code></li>
+          <li>Check permissions are group writable and world read-only</li>
+          <li>Check all artifacts have matching sums and signatures</li>
+          <li>Archive old releases</li>
+        </ul>
+      </section>
+      <section id='distribution-best-practice'><title>Best Practice</title>
+        <section id='distribution-layout'><title>Layout</title>
+        </section>
+        <section id='distribution-release-documentation'><title>Release Documentation</title>
+        </section>
+        <section id='archiving-old-releases'><title>Archiving Old Releases</title>
+          <p>
+          Old releases should be archived 
+          (<a href='http://www.apache.org/dev/release.html#how-to-archive'>by deletion</a>)

+          <a href='http://www.apache.org/dev/release.html#when-to-archive'>promptly</a>.

+          For podlings, typically all old releases should be archived when a new one
+          becomes available.
+          </p>
+          <p>
+          <code>.htaccess</code> files are sometimes used to redirect live urls
to archived releases.
+          Direct links to distributions on <code>www.apache.org</code> bypass
the mirroring.
+          They should therefore be discouraged. It is therefore best to save the effort and
not
+          offer redirects for archived (mirrored) releases.
+          </p><p> 
+          If a redirect is used then for performance reasons, then a <code>.htaccess</code>
in the root 
+          incubator directory should be used.
+          </p>
+        </section>
+        <section id='distribution-mirroring'><title>Mirroring Scripts</title>
+          <p>
+          It is important that users verify releases. Apache has no control 
+          over the integrity of releases on mirrors.  
+          </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
+          <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>.
+          </p>
+        </section>
+        <section id='distribution-signing'><title>Signatures</title>
+          <p>
+          Understand the <a href='http://www.apache.org/dev/release-signing.html'>guide</a>.
+          See <a href='#signing'>signing best practice</a>.
+          </p>
         </section>
+        <section id='distribution-defects'><title>Dealing With A Defect</title>
+          <p>
+        Once an artifact has been uploaded, it must never be modified. No matter how 
+        serious a defect is discovered, the right action is to roll a new
+        one with a new number. 
+          </p><p>
+        Very serious defects may necessitate the withdrawl of a release. This should be done
+        by: 
+          </p>
+          <ol>
+          <li><a href='http://www.apache.org/dev/release-publishing.html#archive'>Archiving</a>
the
+          release (so that it is no accessible from <code>www.apache.org/dist</code>)</li>
+          <li>Posting a suitable announcement (to the same lists that received the
original)</li>
+          <li>Adding a suitable notice to the download page</li>
+          </ol>
+        </section>
+      </section>
+      
+<!--
+        </p><p>
+        A podling is free to choose a suitable layout. However, it is recommended that the
standard layouts
+        are studied. A podling should document it's layout (feel to start with the
+        prose in this document or from the Apache guides).
+        </p>   <p>
+        HTTPD tricks - HEADER.html FOOTER.html
+
+        
         <section id='mirroring'>
         Two choices for podlings. Either use the generic mirror script or create a custom
one. 
         Pros and cons: generic unbranded, weaker links to keys etc; custom one requires effort
@@ -213,12 +384,7 @@
         signatures, checksums TODO:
         scanner: upload these immediately
         </p><p>
-        .htaccess fles are often used to redirect live urls for archived releases. For performance
reasons, 
-        top level .htaccess files are preferred. So edit the .htaccess in the root incubator
directory 
-        Redirect Permanent /src url
-        TODO: example
-        however, since people should not be using these URLs (they bypass the mirroring)
it is appropriate 
-        (and saves effort) not to offer redirects.
+
         </p><p>
         Eclipse: see http://mail-archives.apache.org/mod_mbox/incubator-general/200711.mbox/%3c474F3221.3040800@schor.com%3e
         </p>
@@ -233,11 +399,17 @@
        </p><p>
        The best approach is to check in the documentation for a release into subversion.
It can then 
        be checked out a directory in the website.
+       </p><p>
+       Generally, checking generated documentation into source control is often considered
bad practice.
+       As a method for fixing the documentation for a particular release.
+       </p><p>
+       It is possible to use the subversion URL directly. Checking out into the website space
is 
+       better from the perspective of server load and mirroring.
        </p>
-       
        </section>
+       -->
     </section> 
-     -->
+    
     <section id='check-list'><title>Check List</title>
         <p>
 <strong>Note</strong> this is not intended to replace an understanding of the
release process.

Modified: incubator/public/trunk/site-publish/guides/releasemanagement.html
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-publish/guides/releasemanagement.html?rev=607757&r1=607756&r2=607757&view=diff
==============================================================================
--- incubator/public/trunk/site-publish/guides/releasemanagement.html (original)
+++ incubator/public/trunk/site-publish/guides/releasemanagement.html Mon Dec 31 09:18:14
2007
@@ -152,6 +152,38 @@
 <p>
 			TODO: describe organization of this document.
 			</p>
+<h4>
+   Usage
+</h4>
+<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).

+        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.
+            </p>
+<p>
+        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 
+        bootstrap a release guide.
+            </p>
+<p>
+        The minimum that Podlings need to demonstrate is that 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 
+        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>
+        This document is descriptive not normative. It describes best practices. Policy is
defined
+        elsewhere. Podlings are free to accept or reject any of the recommendations. Enquiries
may 
+        be expected about novel or unusual practices. Best practice evolves. New ideas may
be patched
+        in. 
+            </p>
+</div>
 </div>
 <h3>
    <a name="help">Help Wanted!</a>
@@ -176,12 +208,266 @@
 <p>
         TODO: links to project management books.
         </p>
+<ul>
+          <li>Apache <a href="http://www.apache.org/dev/#releases">Release Management</a></li>
+        </ul>
 </div>
 </div>
            <h2><img src="/images/redarrow.gif" />
    <a name="guidelines">Guidelines</a>
 </h2>
 <div class="section-content">
+</div>
+           <h2><img src="/images/redarrow.gif" />
+   <a name="release-distribution">Distributing Releases</a>
+</h2>
+<div class="section-content">
+<h3>
+   <a name="distribution-policy-overview">Policy Overview</a>
+</h3>
+<div class="section-content">
+<p>
+        Distribution policy is simple:
+        </p>
+<ul>
+        <li>
+        The Incubator 
+        <a href="/incubation/Incubation_Policy.html#Releases">insists</a> 
+        that artifacts for <em>podling</em> are contained within
+        <code>www.apache.org/dist/incubator/podling</code>. 
+        </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>

+        are uploaded for every artifact. 
+        </li>
+        </ul>
+<p>
+        The rest is up to the community to decide and that's quite a lot. 
+        Documenting the release management processes is important and often neglected. 
+        It is 
+        <a href="#document-usage">strongly
+        recommended</a> that the rest of this section is used as the basis for a written
release
+        guide for the podling. 
+        </p>
+</div>
+<h3>
+   <a name="understanding-distribution">Understanding Release Distribution</a>
+</h3>
+<div class="section-content">
+<h4>
+   <a name="understanding-upload">Upload</a>
+</h4>
+<div class="section-content">
+<p>
+          The distribution upload location (<code>www.apache.org/dist</code>)
is the
+          <code>/www/www.apache.org/dist</code> directory on <code>people.apache.org</code>.
+          Release artifacts should be copied into this position in the normal way.
+          </p>
+</div>
+<h4>
+   <a name="understanding-mirroring">Mirroring</a>
+</h4>
+<div class="section-content">
+</div>
+<h4>
+   <a name="understanding-archiving">Archiving</a>
+</h4>
+<div class="section-content">
+<p>
+          All Apache releases form an important part of the history of a project.
+          They are therefore archived with the aim of preserving them indefinitely
+          for future reference. 
+          </p>
+<p>
+          All artifacts within <code>www.apache.org/dist</code> will be automatically
+          archived. When a new artifact is uploaded, it will be sync'd to the archive.
+          When an artifacts is deleted from live distribution, it will
+          remain in the archives. See 
+          <a href="http://www.apache.org/dev/release.html#how-to-archive">how to archive</a>.
+          </p>
+</div>
+<h4>
+   <a name="understanding-security">Security</a>
+</h4>
+<div class="section-content">
+<h5> 
+   <a name="distribution-permissions">Permissions</a> 
+</h5> 
+<div class="section-content">
+<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.

+        The world should have only read only permissions to avoid accidental modification.
+        In short <code>-rw-rw-r--</code>.
+            </p>
+<p>
+        Each podling release is a release of the Incubator project. So, all files should

+        be:
+            </p>
+<ul>
+        <li>owned by the <code>incubator</code> group</li>
+        <li>be group writable</li>
+        <li>be read only for the world</li>
+            </ul>
+<p>
+        To do this from the top level:
+            </p>
+<div class="source"><code>
+        &gt; chmod -R o-wx *
+        &gt; chmod -R g+rw *
+        &gt; chgrp -R incubator *
+            </code>
+</div>
+<p>
+        If a podling graduates to a top level project then 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
+        will then be used.
+            </p>
+</div>
+<h5> 
+   <a name="distribution-sums-sigs">Sums And Signatures</a> 
+</h5> 
+<div class="section-content">
+<p>
+        Start by reading the <a href="http://www.apache.org/dev/release-signing.html">guide</a>.
+            </p>
+<p>
+        Sums are a convenient and simple way for users to verify releases.
+        Signatures play a critical role in ensuring security for releases. 
+            </p>
+<p>
+        If a release is signed by a key that is strongly connected to the 
+        <a href="http://www.apache.org/dev/release-signing.html#web-of-trust">Apache
web of trust</a>
+        then it can be <a href="http://www.apache.org/dev/release-signing.html#web-of-trust">verified</a>

+        that a file has not been modified (by anyone without access to
+        the corresponding private key). It is crucial that new release managers
+        ensure:
+          </p>
+<ul>
+            <li>that the code signing private key is 
+        <a href="http://www.apache.org/dev/release-signing.html#private-key-protection">kept
safe</a>.</li>
+            <li>that the <a href="http://www.apache.org/dev/release-signing.html#keys-policy"><code>KEYS</code></a>

+            file contains the public key</li>
+         </ul>
+<p>
+        It is important that the key is linked to the Apache web of trust by attending a
+        <a href="http://www.apache.org/dev/new-committers-guide.html#pgp">face-to-face
keysigning</a>.
+           </p>
+</div>
+<h5> 
+   <a name="distribution-modifications">Modifications</a> 
+</h5> 
+<div class="section-content">
+<p>
+        Once an artifact has been uploaded, it must never be modified. Not only is there
no
+        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 usual that README's, NOTES and so on

+        are updated with each release.
+            </p>
+</div>
+</div>
+</div>
+<h3>
+   <a name="distribution-check-list">distribution-check-list</a>
+</h3>
+<div class="section-content">
+<ul>
+          <li>Check group is <code>incubator</code></li>
+          <li>Check permissions are group writable and world read-only</li>
+          <li>Check all artifacts have matching sums and signatures</li>
+          <li>Archive old releases</li>
+        </ul>
+</div>
+<h3>
+   <a name="distribution-best-practice">Best Practice</a>
+</h3>
+<div class="section-content">
+<h4>
+   <a name="distribution-layout">Layout</a>
+</h4>
+<div class="section-content">
+</div>
+<h4>
+   <a name="distribution-release-documentation">Release Documentation</a>
+</h4>
+<div class="section-content">
+</div>
+<h4>
+   <a name="archiving-old-releases">Archiving Old Releases</a>
+</h4>
+<div class="section-content">
+<p>
+          Old releases should be archived 
+          (<a href="http://www.apache.org/dev/release.html#how-to-archive">by deletion</a>)

+          <a href="http://www.apache.org/dev/release.html#when-to-archive">promptly</a>.

+          For podlings, typically all old releases should be archived when a new one
+          becomes available.
+          </p>
+<p>
+          <code>.htaccess</code> files are sometimes used to redirect live urls
to archived releases.
+          Direct links to distributions on <code>www.apache.org</code> bypass
the mirroring.
+          They should therefore be discouraged. It is therefore best to save the effort and
not
+          offer redirects for archived (mirrored) releases.
+          </p>
+<p> 
+          If a redirect is used then for performance reasons, then a <code>.htaccess</code>
in the root 
+          incubator directory should be used.
+          </p>
+</div>
+<h4>
+   <a name="distribution-mirroring">Mirroring Scripts</a>
+</h4>
+<div class="section-content">
+<p>
+          It is important that users verify releases. Apache has no control 
+          over the integrity of releases on mirrors.  
+          </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
+          <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>.
+          </p>
+</div>
+<h4>
+   <a name="distribution-signing">Signatures</a>
+</h4>
+<div class="section-content">
+<p>
+          Understand the <a href="http://www.apache.org/dev/release-signing.html">guide</a>.
+          See <a href="#signing">signing best practice</a>.
+          </p>
+</div>
+<h4>
+   <a name="distribution-defects">Dealing With A Defect</a>
+</h4>
+<div class="section-content">
+<p>
+        Once an artifact has been uploaded, it must never be modified. No matter how 
+        serious a defect is discovered, the right action is to roll a new
+        one with a new number. 
+          </p>
+<p>
+        Very serious defects may necessitate the withdrawl of a release. This should be done
+        by: 
+          </p>
+<ol>
+          <li><a href="http://www.apache.org/dev/release-publishing.html#archive">Archiving</a>
the
+          release (so that it is no accessible from <code>www.apache.org/dist</code>)</li>
+          <li>Posting a suitable announcement (to the same lists that received the
original)</li>
+          <li>Adding a suitable notice to the download page</li>
+          </ol>
+</div>
+</div>
 </div>
            <h2><img src="/images/redarrow.gif" />
    <a name="check-list">Check List</a>



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


Mime
View raw message