incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rdon...@apache.org
Subject svn commit: r607829 - in /incubator/public/trunk: site-author/guides/releasemanagement.xml site-publish/guides/releasemanagement.html
Date Tue, 01 Jan 2008 12:00:27 GMT
Author: rdonkin
Date: Tue Jan  1 04:00:25 2008
New Revision: 607829

URL: http://svn.apache.org/viewvc?rev=607829&view=rev
Log:
Wrote up draft content on mirroring

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=607829&r1=607828&r2=607829&view=diff
==============================================================================
--- incubator/public/trunk/site-author/guides/releasemanagement.xml (original)
+++ incubator/public/trunk/site-author/guides/releasemanagement.xml Tue Jan  1 04:00:25 2008
@@ -211,6 +211,18 @@
           </p>
         </section>
         <section id='understanding-mirroring'><title>Mirroring</title>
+          <p>
+          To avoid excessive use of bandwidth and to increase download speeds,
+          official releases are made available through a 
+          <a href='http://www.apache.org/mirrors/'>global network</a> of 
+          <a href='http://www.apache.org/info/how-to-mirror.html'>volunteer mirrors</a>.
+          Using these mirrors has some notable
+          <a href='http://www.apache.org/dev/mirrors.html'>differences</a> from
unmirrored
+          downloads. 
+          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.
+          </p>
         </section>
         <section id='understanding-archiving'><title>Archiving</title>
           <p>
@@ -268,9 +280,11 @@
         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:
+        (by anyone with access to that web of trust) that a file has not been modified 
+        (by anyone without access to the corresponding private key). This allows the infrastructure
+        team to check that releases have not been tampered with. 
+          </p><p>
+        So, it is crucial that new release managers ensure:
           </p>
           <ul>
             <li>that the code signing private key is 
@@ -279,8 +293,12 @@
             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>.
+        It is important that the key is 
+        <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.
+        This will ensure no false alarms from the infrastructure team. 
            </p>
           </section>
           <section id='distribution-modifications'><title>Modifications</title>
@@ -289,18 +307,19 @@
         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.
+        This applies only to release artifacts. It's expected that README's, NOTES and so
on 
+        may be updated.
             </p>
           </section>
         </section>
       </section>
-      <section id='distribution-check-list'>
+      <section id='distribution-check-list'><title>Distribution Check List</title>
         <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>
+          <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>Old releases archived</li>
         </ul>
       </section>
       <section id='distribution-best-practice'><title>Best Practice</title>
@@ -328,6 +347,26 @@
         </section>
         <section id='distribution-mirroring'><title>Mirroring Scripts</title>
           <p>
+          There are two options:
+          </p>          
+          <ul>
+            <li>Use the 
+            <a href='http://www.apache.org/dev/release-download-pages.html#closer'>generic
mirror script</a></li>
+            <li>Create a <a href='http://www.apache.org/dev/release-download-pages.html#custom'>
+            custom script</a> for <a href='http://incubator.apache.org/uima/downloads.cgi'>example</a>.</li>
+          </ul>
+          <p>
+          The generic script can be used immediately and requires the minimum of setup.
+          Creating a custom script allows control over the look, feel and content of the
+          download page but requires more initial effort.
+          </p><p>
+        A consequence of mirroring downloads is that the number of downloads cannot be 
+        monitored directly by using 
+        <a href='http://people.apache.org/~vgritsenko/stats/index.html'>hits</a>
on the Apache site. 
+        When using a custom script, it may be possible to use a service like
+        <a href='http://www.google.com/analytics/en-GB/index.html'>Google analytics</a>

+        to gain a reasonable estimate. 
+          </p><p>
           It is important that users verify releases. Apache has no control 
           over the integrity of releases on mirrors.  
           </p><p>
@@ -344,6 +383,12 @@
           Understand the <a href='http://www.apache.org/dev/release-signing.html'>guide</a>.
           See <a href='#signing'>signing best practice</a>.
           </p>
+          <p>
+          Each podling should maintain it's 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

+          to add their keys to their file.
+          </p>
         </section>
         <section id='distribution-defects'><title>Dealing With A Defect</title>
           <p>
@@ -370,21 +415,6 @@
         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
-        TODO: example
-        one consequence of using the mirroring system is that downloads cannot be 
-        monitored directly by using <a href='TODO: link'>stats</a> from Apache
download hits. 
-        It is possible to use google analytics to gain a reasonable estimate. TODO example.
-        </section>
-        <p>
-        KEYS TODO: 
-        signatures, checksums TODO:
-        scanner: upload these immediately
-        </p><p>
 
         </p><p>
         Eclipse: see http://mail-archives.apache.org/mod_mbox/incubator-general/200711.mbox/%3c474F3221.3040800@schor.com%3e

Modified: incubator/public/trunk/site-publish/guides/releasemanagement.html
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-publish/guides/releasemanagement.html?rev=607829&r1=607828&r2=607829&view=diff
==============================================================================
--- incubator/public/trunk/site-publish/guides/releasemanagement.html (original)
+++ incubator/public/trunk/site-publish/guides/releasemanagement.html Tue Jan  1 04:00:25
2008
@@ -190,7 +190,7 @@
 </ul>
 </li>
 <li><a href='#distribution-check-list'>
-$subsection.getChild("title").getText()
+Distribution Check List
  </a>
 </li>
 <li><a href='#distribution-best-practice'>
@@ -760,6 +760,18 @@
    <a name="understanding-mirroring">Mirroring</a>
 </h4>
 <div class="section-content">
+<p>
+          To avoid excessive use of bandwidth and to increase download speeds,
+          official releases are made available through a 
+          <a href="http://www.apache.org/mirrors/">global network</a> of 
+          <a href="http://www.apache.org/info/how-to-mirror.html">volunteer mirrors</a>.
+          Using these mirrors has some notable
+          <a href="http://www.apache.org/dev/mirrors.html">differences</a> from
unmirrored
+          downloads. 
+          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.
+          </p>
 </div>
 <h4>
    <a name="understanding-archiving">Archiving</a>
@@ -834,9 +846,12 @@
         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:
+        (by anyone with access to that web of trust) that a file has not been modified 
+        (by anyone without access to the corresponding private key). This allows the infrastructure
+        team to check that releases have not been tampered with. 
+          </p>
+<p>
+        So, it is crucial that new release managers ensure:
           </p>
 <ul>
             <li>that the code signing private key is 
@@ -845,8 +860,13 @@
             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>.
+        It is important that the key is 
+        <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.
+        This will ensure no false alarms from the infrastructure team. 
            </p>
 </div>
 <h5> 
@@ -859,21 +879,22 @@
         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.
+        This applies only to release artifacts. It's expected that README's, NOTES and so
on 
+        may be updated.
             </p>
 </div>
 </div>
 </div>
 <h3>
-   <a name="distribution-check-list">distribution-check-list</a>
+   <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>
+          <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>Old releases archived</li>
         </ul>
 </div>
 <h3>
@@ -917,6 +938,28 @@
 </h4>
 <div class="section-content">
 <p>
+          There are two options:
+          </p>
+<ul>
+            <li>Use the 
+            <a href="http://www.apache.org/dev/release-download-pages.html#closer">generic
mirror script</a></li>
+            <li>Create a <a href="http://www.apache.org/dev/release-download-pages.html#custom">
+            custom script</a> for <a href="http://incubator.apache.org/uima/downloads.cgi">example</a>.</li>
+          </ul>
+<p>
+          The generic script can be used immediately and requires the minimum of setup.
+          Creating a custom script allows control over the look, feel and content of the
+          download page but requires more initial effort.
+          </p>
+<p>
+        A consequence of mirroring downloads is that the number of downloads cannot be 
+        monitored directly by using 
+        <a href="http://people.apache.org/~vgritsenko/stats/index.html">hits</a>
on the Apache site. 
+        When using a custom script, it may be possible to use a service like
+        <a href="http://www.google.com/analytics/en-GB/index.html">Google analytics</a>

+        to gain a reasonable estimate. 
+          </p>
+<p>
           It is important that users verify releases. Apache has no control 
           over the integrity of releases on mirrors.  
           </p>
@@ -936,6 +979,12 @@
 <p>
           Understand the <a href="http://www.apache.org/dev/release-signing.html">guide</a>.
           See <a href="#signing">signing best practice</a>.
+          </p>
+<p>
+          Each podling should maintain it's 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

+          to add their keys to their file.
           </p>
 </div>
 <h4>



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


Mime
View raw message