incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rdon...@apache.org
Subject svn commit: r476805 - in /incubator/public/trunk: site-author/guides/releasemanagement.xml site-publish/guides/releasemanagement.html
Date Sun, 19 Nov 2006 12:00:50 GMT
Author: rdonkin
Date: Sun Nov 19 04:00:49 2006
New Revision: 476805

URL: http://svn.apache.org/viewvc?view=rev&rev=476805
Log:
More content

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?view=diff&rev=476805&r1=476804&r2=476805
==============================================================================
--- incubator/public/trunk/site-author/guides/releasemanagement.xml (original)
+++ incubator/public/trunk/site-author/guides/releasemanagement.xml Sun Nov 19 04:00:49 2006
@@ -106,7 +106,26 @@
     		</p>
     		<p>
 it is simple but subtle (it's rare for components to create complient releases first time).
-
+Releases are important from a legal and organisational perspective. To create a release 
+official, it needs to be authorized by the management committee charged with 
+oversight by the board. 
+			</p><p>
+TODO: think about this section. Releases are important from a legal perspective. Open
+source release managers may expose themselves to significant legal liabiiity
+for the content of the releaes. For official Apache releases conducted
+with due process, the liability is reduced since the release manager is
+acting for Apache. 
+    		</p><p>
+ The board expects a project management committe to exercise oversight to
+ ensure that the release complies with current policy and that the legal risk
+ to Apache is minimized. This means that members of the project management
+ committee have a duty to audit the release before signing it off. 
+    		</p><p>
+ TODO: link to legal and policy audit notes. Luckily, it's possible to automate many 
+ of the common checks. 
+    		</p><p>
+ TODO: this content probably makes more sense in a PPMC/PMC document.
+ Consider linking.
     		</p>
     	</section>
         <p>
@@ -442,10 +461,12 @@
 			</p><p>
 Though utilities for all major compression formats are available for all major platforms,
 not all platforms support all major compression formats by default. 
-It is therefore convenient for users to ship each type of distribution in more than one
-compressed format. Ship one of tar.gz, bz or bz2 for UNIX and linux (but note 
+Users find it convenient to download the distribution compressed in a familiar
+format that is easy to decompress on their platform.
+It is therefore recommended that each type of distribution is shipped in a variety of
+compressed formats. Ship at least one of tar.gz, bz or bz2 for UNIX and linux (but note 
 <a href='notes-on-compression-formats'>this</a>). 
-Ship zip for windows.
+Ship zip for windows. 
 			</p><p>
 Some formats are strongly associated with particular platforms. 
 Even when the uncompressed contents have no functional differences,
@@ -800,6 +821,12 @@
         	</p>
         </section>
         <section id='release-notes'><title>Release Notes</title>
+        	<p>
+Release notes are a vital tool for communication between an open source project 
+and it's 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 pubicity.
+        	</p>
             <p>
 The release notes should be in a common and easily read format (plain text is best).
 The release notes should easily located and so should be positioned in the base directory.
@@ -857,6 +884,22 @@
 Remember that a user may have received the software indirectly. So, include
 some brief details about the project and an url.
             </p>
+            <p>
+Release notes are important TODO: glossary guerrilla advertising for a project.
+They should provide: 
+            </p>
+            <ul>
+            	<li>an introduction for those who don't know the project in 
+detail</li>
+				<li>briefly state the aims of the project</li>
+				<li>briefly indicate the project's roadmap and how this release fits into it</li>
+				<li>list ways to get involved with the project</li>
+				<li>describe how to raise issues</li>
+			</ul>
+			<p>
+This may be included by reference to the main documentation 
+but (for the benefit of those that don't read document) should be mentioned.
+			</p>
         </section>
         <section id='note-compatibility-checkers'><title>Compatibility Checkers</title>
 			<p>
@@ -898,6 +941,27 @@
 TODO: links to dev pages
 batch signing scripts in committers
         	</p>
+        	<p>
+TODO: consider moving content into foundation docs
+        	</p>
+        	<p>
+OpenPGP compatible signatures must be generated to accumpiany releases.
+Public key encryption is a deep and wide subject. However, the
+knowledge required to safely create signatures for Apache releases can be
+learnt in a short time. TODO: link to foundation docs
+        	</p><p>
+ What can be sometimes confusing is that though a signature is required, 
+ connection to the web of trust is only strongly encouraged not required. 
+ 			</p><p>
+ A signature from a key which is well 
+ connected to the Apache web of trust gives greater security than a signature
+ that is not. 
+ 			</p><p>
+ However, the essential use of signatures at Apache is to allow
+ release managers themselves to check whether an artifact is identical 
+ to the release they created. All that is required in this case is that the 
+ release managers knows whether a signature is their own.
+        	</p>   	
         </section>
         <section id='note-on-multiple-products'><title>On Mutiple Products</title>
         	<p>

Modified: incubator/public/trunk/site-publish/guides/releasemanagement.html
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-publish/guides/releasemanagement.html?view=diff&rev=476805&r1=476804&r2=476805
==============================================================================
--- incubator/public/trunk/site-publish/guides/releasemanagement.html (original)
+++ incubator/public/trunk/site-publish/guides/releasemanagement.html Sun Nov 19 04:00:49
2006
@@ -196,7 +196,30 @@
     		</p>
 <p>
 it is simple but subtle (it's rare for components to create complient releases first time).
-
+Releases are important from a legal and organisational perspective. To create a release 
+official, it needs to be authorized by the management committee charged with 
+oversight by the board. 
+			</p>
+<p>
+TODO: think about this section. Releases are important from a legal perspective. Open
+source release managers may expose themselves to significant legal liabiiity
+for the content of the releaes. For official Apache releases conducted
+with due process, the liability is reduced since the release manager is
+acting for Apache. 
+    		</p>
+<p>
+ The board expects a project management committe to exercise oversight to
+ ensure that the release complies with current policy and that the legal risk
+ to Apache is minimized. This means that members of the project management
+ committee have a duty to audit the release before signing it off. 
+    		</p>
+<p>
+ TODO: link to legal and policy audit notes. Luckily, it's possible to automate many 
+ of the common checks. 
+    		</p>
+<p>
+ TODO: this content probably makes more sense in a PPMC/PMC document.
+ Consider linking.
     		</p>
 </div>
 <p>
@@ -590,10 +613,12 @@
 <p>
 Though utilities for all major compression formats are available for all major platforms,
 not all platforms support all major compression formats by default. 
-It is therefore convenient for users to ship each type of distribution in more than one
-compressed format. Ship one of tar.gz, bz or bz2 for UNIX and linux (but note 
+Users find it convenient to download the distribution compressed in a familiar
+format that is easy to decompress on their platform.
+It is therefore recommended that each type of distribution is shipped in a variety of
+compressed formats. Ship at least one of tar.gz, bz or bz2 for UNIX and linux (but note 
 <a href="notes-on-compression-formats">this</a>). 
-Ship zip for windows.
+Ship zip for windows. 
 			</p>
 <p>
 Some formats are strongly associated with particular platforms. 
@@ -1009,6 +1034,12 @@
 </h3>
 <div class="section-content">
 <p>
+Release notes are a vital tool for communication between an open source project 
+and it's 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 pubicity.
+        	</p>
+<p>
 The release notes should be in a common and easily read format (plain text is best).
 The release notes should easily located and so should be positioned in the base directory.
             </p>
@@ -1065,6 +1096,22 @@
 Remember that a user may have received the software indirectly. So, include
 some brief details about the project and an url.
             </p>
+<p>
+Release notes are important TODO: glossary guerrilla advertising for a project.
+They should provide: 
+            </p>
+<ul>
+            	<li>an introduction for those who don't know the project in 
+detail</li>
+				<li>briefly state the aims of the project</li>
+				<li>briefly indicate the project's roadmap and how this release fits into it</li>
+				<li>list ways to get involved with the project</li>
+				<li>describe how to raise issues</li>
+			</ul>
+<p>
+This may be included by reference to the main documentation 
+but (for the benefit of those that don't read document) should be mentioned.
+			</p>
 </div>
 <h3>
    <a name="note-compatibility-checkers">Compatibility Checkers</a>
@@ -1114,6 +1161,30 @@
 <p>
 TODO: links to dev pages
 batch signing scripts in committers
+        	</p>
+<p>
+TODO: consider moving content into foundation docs
+        	</p>
+<p>
+OpenPGP compatible signatures must be generated to accumpiany releases.
+Public key encryption is a deep and wide subject. However, the
+knowledge required to safely create signatures for Apache releases can be
+learnt in a short time. TODO: link to foundation docs
+        	</p>
+<p>
+ What can be sometimes confusing is that though a signature is required, 
+ connection to the web of trust is only strongly encouraged not required. 
+ 			</p>
+<p>
+ A signature from a key which is well 
+ connected to the Apache web of trust gives greater security than a signature
+ that is not. 
+ 			</p>
+<p>
+ However, the essential use of signatures at Apache is to allow
+ release managers themselves to check whether an artifact is identical 
+ to the release they created. All that is required in this case is that the 
+ release managers knows whether a signature is their own.
         	</p>
 </div>
 <h3>



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


Mime
View raw message