incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rdon...@apache.org
Subject svn commit: r537647 - in /incubator/public/trunk: site-author/guides/releasemanagement.xml site-publish/guides/releasemanagement.html
Date Sun, 13 May 2007 19:37:18 GMT
Author: rdonkin
Date: Sun May 13 12:37:18 2007
New Revision: 537647

URL: http://svn.apache.org/viewvc?view=rev&rev=537647
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=537647&r1=537646&r2=537647
==============================================================================
--- incubator/public/trunk/site-author/guides/releasemanagement.xml (original)
+++ incubator/public/trunk/site-author/guides/releasemanagement.xml Sun May 13 12:37:18 2007
@@ -78,6 +78,7 @@
     </section>
     </section>
     <section id='guidelines'><title>Guidelines</title>
+        <!-- 
     	<p>
   TODO: may need to think about this title. The idea is to try to clearly separate guidelines
   about release processes and procedures from rules and guidelines.
@@ -93,53 +94,8 @@
  In practice, most project adopt more ceremony than this minimum for a number of important
reasons. 
  			</p>
  			<p>
- ASF releases are often widely distributed and long lived. Expect to be publicly held to
account 
- for a substandard release for a long time to come. 
-    		</p>
-			<p>
-As a project matures and its reputation grows, the consequences of a poor quality release
increase.
-It is therefore typical for mature projects to use release candidates, beta, alphas and so
on. 
-This ceremony is usually not necessary for neonate projects but may need to be adopted in
time.
-			</p>
-			<p>
-			TODO: release models - describe process models for more complex projects.
-			</p>
-    	</section>
-    	<section id='picies'><title>ASF Release Policy</title>
-    		<p>
-Policy is set by the board and by board committees (legal, infra, prc). 
-    		</p>
-    		<p>
-it is simple but subtle (it's rare for components to create compliant releases first time).
-Releases are important from a legal and organizational 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 liability
-for the content of the releases. 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 committee 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>
-It is strong recommended that a project creates it's own release guidelines. The actual 
-<a href='#rules'>minimum</a> required by the ASF is reasonable small but subtle.
However,
-the traditional standards for ASF releases are quite high. 
-        </p>
-                <p>
-This document is not normative. It should not be seen as a recipe for definitive ASF releases.
It is
+ASF releases are often widely distributed and long lived. This document is not normative.
+It should not be seen as a recipe for definitive ASF releases. It is
 strongly recommended that podlings create their own release guidelines. Hopefully the incubator
documentation
 may help to shorten the process of creating good release guidelines for the podling by providing

 options, highlighting issues and providing templates.
@@ -185,6 +141,7 @@
 then finally for <a href='#glossay-cutting-release'>cutting the release</a>.
 TODO: maybe be better in a time line
         </p>
+       -->
     </section>
     <section id='check-list'><title>Check List</title>
         <p>
@@ -245,14 +202,94 @@
     </section>
     <section id='rules'><title>Rules</title>
         <p>
-        TODO release votes by pmc, legal rules (licenses of distributed dependencies, source
licenses, LICENSE, NOTICE), 
-        infrastructure rules(signing). Use links so information is maintained 
-        in only one place.
+Every incubator release is also an Apache release. So Apache policy must be followed. 
+Incubator policy is additional and builds on these rules. 
+        </p><p>
+Release managers for podlings
+need to read the <a href='http://www.apache.org/dev/index.html#releases'>release</a>
+and <a href='http://www.apache.org/legal'>legal</a>
+documentation on the main <a href='http://www.apache.org'>Apache site</a>. 
+        </p>
+        <p>
+A few important topics are discussed below. These are a supplement and not a substitute 
+for the Apache documentation.
+        </p>
+        <section id='signing'><title>Signing</title>
+         <p>
+ The release manager need to create a
+ <a href='http://www.apache.org/dev/release-signing.html#sign-release'>signature</a>
+ for every artifact released. It only takes a little time to create a key and the process
+ is reasonably straight forward.
         </p>
-        <section id='naming'>Naming<title></title>
+        <p>
+However, it is recommended that enough time is taken to gain a basic understanding of the

+pubic key crytography.
+Read the <a href='http://www.apache.org/dev/release-signing.html'>Apache Signing Guide</a>
+and at least some of the background material linked from it.
+            </p>
+            <p>
+ See:
+            </p>
+            <ul>
+                <li>
+<a href='http://www.apache.org/dev/release-signing.html'>Apache Signing Guide</a>
+                </li>
+            </ul>
+        </section>
+        <section id='naming'><title>Naming</title>
+            <p>
+Apache releases should contain the full name of the project responsible for the release.
This ensures that
+trademark law can be used against others issuing artifacts with the same name. 
+             </p>
+             <p>
+For example, one good name for product bar Apache Foo Project would be <code>apache-foo-bar</code>.
+            </p>
+            <p>
+Once a podling graduations, it should adopt this naming convention. 
+Whilst in the incubator, practice is a little different.
+The release name should contain the podling name and may contain apache. 
+Incubator policy insists that it must also contain <code>incubating</code> (though
small variations 
+for the sake of readability are usually acceptable). 
+            </p>
+             <p>
+For example, for podling foo, both <code>apache-foo-incubating</code> and 
+<code>foo-incubating</code> would be acceptable names. 
+            </p>
             <p>
-            TODO: incubator rules
+ See also:
             </p>
+            <ul>
+                <li>
+ <a href='/incubator/Incubator_Policy.html'>Incubator Policy</a>
+                </li>
+                <li>
+ <a href='branding.html'>Incubator Branding Guide</a>
+                </li>
+            </ul>
+        </section>
+        <section id='release-legal-audit'><title>License Audit</title>
+            <p>
+Incubator policy <a href='/incubation/Incubation_Policy.html#Releases'>requires</a>
that 
+all incoming code is fully signed off before any release. This simply reinforces the Apache

+requirements: all code must have appropriate licenses. 
+Potential liability for releasedcode is greater than for unrelesed coee.
+So, it is of particular importance that this is true of all released code. 
+            </p>
+            <p>
+ The process of preparing a release should include an audit of the code to ensure
+ that all files have appropriate headers and that all dependencies complies with
+ <a href='http://www.apache.org/legal/3party.html'>Apache policy</a>. 
+ The release build also needs to be check
+ to ensure that the LICENSE and NOTICE files are included in every released artifact.
+            </p>
+            <p>
+ See:
+            </p>
+            <ul>
+                <li><a href='http://www.apache.org/legal/src-headers.html'>Header
for source files</a></li>
+                <li><a href='http://www.apache.org/legal/3party.html'>Policy
for dependencies</a></li>
+                <li><a href='http://www.apache.org/dev/release.html'>Release
policy and FAQ</a></li>
+           </ul>
         </section>
     </section>
     <section id='release-guidelines'><title>Release Guidelines</title>
@@ -263,12 +300,21 @@
 these guidelines but they have not been blessed as policy.
     	</p>
     	<p>
-Guidelines change much more frequently than policy. Release managers should flow the appropriate
-lists (TODO: create list of useful mailing lists).
+Guidelines change much more frequently than policy. Release managers should follow the appropriate
+lists. Subscribe to:
     	</p>
+        <ul>
+            <li><em>legal-discuss</em> for matters related to licensing</li>
+            <li><em>repository</em> for matters related to the maven repositories</li>
+            <li><em>infrastructure-issues</em> for matters related to </li>
+        </ul>
     </section>
     <section id='best-practice'><title>Best Practice</title>
     	<section id='best-practice-preparation'><title>Preparation</title>
+            <p>
+Preparation is the key to quality. The <a href='#glossary-release-manager'>release
manager</a>
+will need to organise and coordinate this but need not execute all.
+            </p>
 			<ul>
 				<li>Analyze <a href='#best-practice-prepare-documentation'>bugs</a></li>
 				<li>Check <a href='#best-practice-prepare-documentation'>documentation</a></li>
@@ -782,6 +828,16 @@
         </section>
     </section>
     <section id='notes'><title>Notes</title>
+        <section id='notes-on-licenses'><title>License Issues</title> 
+            <p>
+            TODO: content
+            It is important that the right legal contracts are in place for all source code
at Apache
+and that the right process has been followed. For the majority of the time, this
+is easy: committers create original works which are licensed by Apache under
+a CLA or CCLA
+TODO: complete content
+            </p>
+        </section>
         <section id='notes-disclaimer'><title>The Incubator Disclaimer</title>
             <p>
             TODO: the incubator requires that users are informed that the by
@@ -1446,6 +1502,38 @@
         </section>
     </section>
     <section id='glossary'><title>Glossary</title>
+        <section id='glossary-cla'><title>Contributor License Agreement</title>
+            <p>
+ A Contributor License Agreement (CLA) is a contract between a contributor
+ and Apache granting Apache rights to code contributed. Every committer
+ must have a signed CLA on file.
+            </p>
+            <p>
+See
+            </p>
+            <ul>
+                <li>
+<a href='http://www.apache.org/foundation/licenses/cla.txt'>CLA text</a>
+                </li>
+            </ul>
+         </section>
+         <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
+ 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 .
+            </p>
+            <p>
+See
+            </p>
+            <ul>
+                <li>
+<a href='http://www.apache.org/foundation/licenses/cla-corporate.txt'>CCLA text</a>
+                </li>
+            </ul>
+         </section>
         <section id='glossary-artifact'><title>Distributed Artifact</title>
         	<p>
 A file that is actually shipped.
@@ -1516,14 +1604,13 @@
         </section>
         <section id='glossary-source-distribution'><title>Source Distribution</title>
             <p>
-            TODO: (include link to infra documentation)
+A source release is a simple export from the repository.
             </p>
         </section>
         <section id='glossary-binary-distribution'><title>Binary Distribution</title>
             <p>
-            TODO: (include link to infra documentation)
-            binary distributions include all types which are not source. 
-            one canonical source distribution, many binary distributions.
+Binary distributions are all which are not plain source exports
+There is on one canonical source distribution but there may be several binary distributions.
             </p>
         </section>
         <section id='glossary-cutting-release'><title>Cutting The Release</title>

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=537647&r1=537646&r2=537647
==============================================================================
--- incubator/public/trunk/site-publish/guides/releasemanagement.html (original)
+++ incubator/public/trunk/site-publish/guides/releasemanagement.html Sun May 13 12:37:18
2007
@@ -179,123 +179,6 @@
    <a name="guidelines">Guidelines</a>
 </h2>
 <div class="section-content">
-<p>
-  TODO: may need to think about this title. The idea is to try to clearly separate guidelines
-  about release processes and procedures from rules and guidelines.
-    	</p>
-<h3>
-   <a name="process">Release Process</a>
-</h3>
-<div class="section-content">
-<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.
-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. 
- 			</p>
-<p>
- ASF releases are often widely distributed and long lived. Expect to be publicly held to
account 
- for a substandard release for a long time to come. 
-    		</p>
-<p>
-As a project matures and its reputation grows, the consequences of a poor quality release
increase.
-It is therefore typical for mature projects to use release candidates, beta, alphas and so
on. 
-This ceremony is usually not necessary for neonate projects but may need to be adopted in
time.
-			</p>
-<p>
-			TODO: release models - describe process models for more complex projects.
-			</p>
-</div>
-<h3>
-   <a name="picies">ASF Release Policy</a>
-</h3>
-<div class="section-content">
-<p>
-Policy is set by the board and by board committees (legal, infra, prc). 
-    		</p>
-<p>
-it is simple but subtle (it's rare for components to create compliant releases first time).
-Releases are important from a legal and organizational 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 liability
-for the content of the releases. 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 committee 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>
-It is strong recommended that a project creates it's own release guidelines. The actual 
-<a href="#rules">minimum</a> required by the ASF is reasonable small but subtle.
However,
-the traditional standards for ASF releases are quite high. 
-        </p>
-<p>
-This document is not normative. It should not be seen as a recipe for definitive ASF releases.
It is
-strongly recommended that podlings create their own release guidelines. Hopefully the incubator
documentation
-may help to shorten the process of creating good release guidelines for the podling by providing

-options, highlighting issues and providing templates.
-        </p>
-<p>
-There is great variety amongst existing Apache project. Diversity is good. 
-        </p>
-<p>
-There is inevitably a conflict between the excellent advice to release often and the documentation
-required to create good releases.
-        </p>
-<ul>
-            <li>
-        ASF releases are high visibility and long lived. A release manager may find that
a 
-        poor quality release may be held up as an example for years to come.
-            </li>
-            <li>
-        TODO: legal consequences
-            </li>
-        </ul>
-<p>
-A podling should have a release guide. A good starting point (once this document has been
read)
-is release guides for existing projects:
-        </p>
-<ul>
-        	<li><a href="http://httpd.apache.org/dev/release.html">HTTPD</a></li>
-        	<li><a href="http://jakarta.apache.org/commons">Jakarta Commons</a></li>
-        	<li><a href="http://struts.apache.org/releases.html">Struts</a></li>
-        </ul>
-<p>Please also check the <a href="http://www.apache.org/dev/release.html">Apache
Release guidelines</a>
- in particular the <a href="http://www.apache.org/dev/release.html#license">license
requirements</a>.
- Also you might find it useful to read some of the
- <a href="http://wiki.apache.org/general/ReleaseGuides">release guides</a> from
other projects.
-</p>
-<p>
-Most projects find it difficult to issue quality releases without appointing a 
-<a href="glossay-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>.
-TODO: maybe be better in a time line
-        </p>
 </div>
            <h2><img src="/images/redarrow.gif" />
    <a name="check-list">Check List</a>
@@ -362,17 +245,104 @@
 </h2>
 <div class="section-content">
 <p>
-        TODO release votes by pmc, legal rules (licenses of distributed dependencies, source
licenses, LICENSE, NOTICE), 
-        infrastructure rules(signing). Use links so information is maintained 
-        in only one place.
+Every incubator release is also an Apache release. So Apache policy must be followed. 
+Incubator policy is additional and builds on these rules. 
+        </p>
+<p>
+Release managers for podlings
+need to read the <a href="http://www.apache.org/dev/index.html#releases">release</a>
+and <a href="http://www.apache.org/legal">legal</a>
+documentation on the main <a href="http://www.apache.org">Apache site</a>. 
+        </p>
+<p>
+A few topics are discussed below. These are a supplement and not a substitute 
+for the Apache documentation.
         </p>
 <h3>
-   <a name="naming"></a>
+   <a name="signing">Signing</a>
 </h3>
 <div class="section-content">
 <p>
-            TODO: incubator rules
+ The release manager need to create a
+ <a href="http://www.apache.org/dev/release-signing.html#sign-release">signature</a>
+ for every artifact released. It only takes a little time to create a key and the process
+ is reasonably straight forward.
+        </p>
+<p>
+However, it is recommended that enough time is taken to gain a basic understanding of the

+pubic key crytography.
+Read the <a href="http://www.apache.org/dev/release-signing.html">Apache Signing Guide</a>
+and at least some of the background material linked from it.
+            </p>
+<p>
+ See:
             </p>
+<ul>
+                <li>
+<a href="http://www.apache.org/dev/release-signing.html">Apache Signing Guide</a>
+                </li>
+            </ul>
+</div>
+<h3>
+   <a name="naming">Naming</a>
+</h3>
+<div class="section-content">
+<p>
+Apache releases should contain the full name of the project responsible for the release.
This ensures that
+trademark law can be used against others issuing artifacts with the same name. 
+             </p>
+<p>
+For example, one good name for product bar Apache Foo Project would be <code>apache-foo-bar</code>.
+            </p>
+<p>
+Once a podling graduations, it should adopt this naming convention. 
+Whilst in the incubator, practice is a little different.
+The release name should contain the podling name and may contain apache. 
+Incubator policy insists that it must also contain <code>incubating</code> (though
small variations 
+for the sake of readability are usually acceptable). 
+            </p>
+<p>
+For example, for podling foo, both <code>apache-foo-incubating</code> and 
+<code>foo-incubating</code> would be acceptable names. 
+            </p>
+<p>
+ See also:
+            </p>
+<ul>
+                <li>
+ <a href="/incubator/Incubator_Policy.html">Incubator Policy</a>
+                </li>
+                <li>
+ <a href="branding.html">Incubator Branding Guide</a>
+                </li>
+            </ul>
+</div>
+<h3>
+   <a name="release-legal-audit">License Audit</a>
+</h3>
+<div class="section-content">
+<p>
+Incubator policy <a href="/incubation/Incubation_Policy.html#Releases">requires</a>
that 
+all incoming code is fully signed off before any release. This simply reinforces the Apache

+requirements: all code must have appropriate licenses. 
+Potential liability for releasedcode is greater than for unrelesed coee.
+So, it is of particular importance that this is true of all released code. 
+            </p>
+<p>
+ The process of preparing a release should include an audit of the code to ensure
+ that all files have appropriate headers and that all dependencies complies with
+ <a href="http://www.apache.org/legal/3party.html">Apache policy</a>. 
+ The release build also needs to be check
+ to ensure that the LICENSE and NOTICE files are included in every released artifact.
+            </p>
+<p>
+ See:
+            </p>
+<ul>
+                <li><a href="http://www.apache.org/legal/src-headers.html">Header
for source files</a></li>
+                <li><a href="http://www.apache.org/legal/3party.html">Policy
for dependencies</a></li>
+                <li><a href="http://www.apache.org/dev/release.html">Release
policy and FAQ</a></li>
+           </ul>
 </div>
 </div>
            <h2><img src="/images/redarrow.gif" />
@@ -386,9 +356,14 @@
 these guidelines but they have not been blessed as policy.
     	</p>
 <p>
-Guidelines change much more frequently than policy. Release managers should flow the appropriate
-lists (TODO: create list of useful mailing lists).
+Guidelines change much more frequently than policy. Release managers should follow the appropriate
+lists. Subscribe to:
     	</p>
+<ul>
+            <li><em>legal-discuss</em> for matters related to licensing</li>
+            <li><em>repository</em> for matters related to the maven repositories</li>
+            <li><em>infrastructure-issues</em> for matters related to </li>
+        </ul>
 </div>
            <h2><img src="/images/redarrow.gif" />
    <a name="best-practice">Best Practice</a>
@@ -999,6 +974,19 @@
 </h2>
 <div class="section-content">
 <h3>
+   <a name="notes-on-licenses">License Issues</a>
+</h3>
+<div class="section-content">
+<p>
+            TODO: content
+            It is important that the right legal contracts are in place for all source code
at Apache
+and that the right process has been followed. For the majority of the time, this
+is easy: committers create original works which are licensed by Apache under
+a CLA or CCLA
+TODO: complete content
+            </p>
+</div>
+<h3>
    <a name="notes-disclaimer">The Incubator Disclaimer</a>
 </h3>
 <div class="section-content">
@@ -1760,6 +1748,44 @@
    <a name="glossary">Glossary</a>
 </h2>
 <div class="section-content">
+<h3>
+   <a name="glossary-cla">Contributor License Agreement</a>
+</h3>
+<div class="section-content">
+<p>
+ A Contributor License Agreement (CLA) is a contract between a contributor
+ and Apache granting Apache rights to code contributed. Every committer
+ must have a signed CLA on file.
+            </p>
+<p>
+See
+            </p>
+<ul>
+                <li>
+<a href="http://www.apache.org/foundation/licenses/cla.txt">CLA text</a>
+                </li>
+            </ul>
+</div>
+<h3>
+   <a name="glossary-ccla">Contributor License Agreement - Corporate</a>
+</h3>
+<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
+ 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 .
+            </p>
+<p>
+See
+            </p>
+<ul>
+                <li>
+<a href="http://www.apache.org/foundation/licenses/cla-corporate.txt">CCLA text</a>
+                </li>
+            </ul>
+</div>
 <h3>
    <a name="glossary-artifact">Distributed Artifact</a>
 </h3>



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


Mime
View raw message