incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rdon...@apache.org
Subject svn commit: r534131 - in /incubator/public/trunk: site-author/guides/releasemanagement.xml site-author/projects/wicket.xml site-publish/guides/releasemanagement.html site-publish/projects/wicket.html
Date Tue, 01 May 2007 15:50:37 GMT
Author: rdonkin
Date: Tue May  1 08:50:37 2007
New Revision: 534131

URL: http://svn.apache.org/viewvc?view=rev&rev=534131
Log:
Spieling fixs. https://issues.apache.org/jira/browse/INCUBATOR-61. Contributed by Martijn Dashorst.

Modified:
    incubator/public/trunk/site-author/guides/releasemanagement.xml
    incubator/public/trunk/site-author/projects/wicket.xml
    incubator/public/trunk/site-publish/guides/releasemanagement.html
    incubator/public/trunk/site-publish/projects/wicket.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=534131&r1=534130&r2=534131
==============================================================================
--- incubator/public/trunk/site-author/guides/releasemanagement.xml (original)
+++ incubator/public/trunk/site-author/guides/releasemanagement.xml Tue May  1 08:50:37 2007
@@ -35,7 +35,7 @@
 It contains advice on best practice, links to Apache release management 
 <a href='http://www.apache.org/dev/index.html#releases'>policy and practice</a> 
 with commentary and discusses incubation release management  
-<a href='/incubation/Incubation_Policy.html#Releases'>policy</a>. 
+<a href='/incubation/Incubation_Picy.html#Releases'>policy</a>. 
             </p>
         </section>
         <section name='apache-releases'><title>Apache Releases</title>
@@ -53,9 +53,9 @@
 not only on the project but also the foundation as a whole. 
         </p>
 		</section>
-		<section name='apache-releases'><title>Organisation</title>
+		<section name='apache-releases'><title>Organization</title>
 			<p>
-			TODO: describe organisation of this document.
+			TODO: describe organization of this document.
 			</p>
 		</section>
         <section id='help'><title>Help Wanted!</title>
@@ -93,7 +93,7 @@
  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 publically held to account 
+ 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>
@@ -105,23 +105,23 @@
 			TODO: release models - describe process models for more complex projects.
 			</p>
     	</section>
-    	<section id='policies'><title>ASF Release Policy</title>
+    	<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 complient releases first time).
-Releases are important from a legal and organisational perspective. To create a release 
+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 liabiiity
-for the content of the releaes. For official Apache releases conducted
+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 committe to exercise oversight to
+ 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. 
@@ -179,9 +179,9 @@
 <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 organisations,
+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 marshalling the VOTEs required for formal approval
+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>
@@ -207,7 +207,7 @@
                     </li>
                     <li>Check copyright notices:
                     	<ul>
-	                    	<li>Licences missing from source files</li>
+	                    	<li>Licenses missing from source files</li>
 	                    	<li>Source files with other licenses which are not mentioned in LICENSE</li>
 	                    	<li>Check current policy on headers that all comply</li>
                     	</ul>
@@ -259,39 +259,39 @@
     	<p>
 In addition to policy, the infrastructure, public relations and legal teams also
 document <a href='#glossary-guidelines'>guidelines</a> for projects.
-There are almost certainly good reasons why a project should follow
+There are almost certainly good reasons why a project should flow
 these guidelines but they have not been blessed as policy.
     	</p>
     	<p>
-Guidelines change much more frequently than policy. Release managers should follow the appropriate
+Guidelines change much more frequently than policy. Release managers should flow the appropriate
 lists (TODO: create list of useful mailing lists).
     	</p>
     </section>
     <section id='best-practice'><title>Best Practice</title>
     	<section id='best-practice-preparation'><title>Preparation</title>
 			<ul>
-				<li>Analyse <a href='#best-practice-prepare-documentation'>bugs</a></li>
+				<li>Analyze <a href='#best-practice-prepare-documentation'>bugs</a></li>
 				<li>Check <a href='#best-practice-prepare-documentation'>documentation</a></li>
 			</ul>
     	</section>
     	<section id='best-practice-bugs'><title>Bugs</title>
     		<p>
-The list of open issues needs to be analysed. The community needs to decide which 
+The list of open issues needs to be analyzed. The community needs to decide which 
 issues could be resolved for this release and how much energy the community
 has to deal with these. Time may also become a factor: some issues which 
 cannot be resolved promptly may need to be postponed.
     		</p>
     		<p>
 Issue tracking system can be used to help this process especially for complex projects 
-with many open issues. Each open issues should be analysed and marked appropriately.
-An accurate view of those bugs which are targetted for the upcoming release helps
+with many open issues. Each open issues should be analyzed and marked appropriately.
+An accurate view of those bugs which are targeted for the upcoming release helps
 to concentrate community effort. Consider asking reporters to donate unit tests.
     		</p>
     	</section>
     	<section id='best-practice-prepare-documentation'><title>Preparing Documentation</title>
     		<p>
 Any documentation that the release contains should be proof-read and spell checked.
-This is obviously something that needs to happen after the content is finalised.
+This is obviously something that needs to happen after the content is finalized.
 So typically, the release manager needs to coordinate the documentation effort.
 A release is a good time to concentrate energy on documentation.
     		</p>
@@ -319,8 +319,8 @@
         </section>
         <section id='best-practice-types'><title>Distribution Types</title>
         	<p>
- TODO: glossay - distribution type: based on the same tagged source built  
- TODO: Common Types of distribtuion
+ TODO: glossary - distribution type: based on the same tagged source built  
+ TODO: Common Types of distribution
  			</p>
  			<p>
  The source distribution is canonical. Every release should create a source distribution.
@@ -334,9 +334,9 @@
         </section>
         <section id='best-practice-downstream'><title>Downstream Packagers</title>
         	<p>
- TODO: glossay - downstream packager: takes an apache release and packages it for a particular platform.
+ TODO: glossary - downstream packager: takes an apache release and packages it for a particular platform.
  TODO: best practice is to work with downstream packagers and link to their packages
- rather than roll own packages. need to add notes that these are not official releases.
+ rather than rl own packages. need to add notes that these are not official releases.
  TODO: link to notes on working with downstream packagers
         	</p>
         	<p>
@@ -367,7 +367,7 @@
         	<p>
 It is strongly recommended that source distributions are included in every release.
 Many packagers (for example, FreeBSD and linux distributions) prefer or demand
-to work from source releases. Archivists prefer source. Many large organisations
+to work from source releases. Archivists prefer source. Many large organizations
 prefer to verify and then build their own versions from source. A source distribution
 is easy to create but helps to reach these audiences.
         	</p>
@@ -397,7 +397,7 @@
 Collecting all this information may seem a little daunting especially for a starting project.
 Not at all agile. One approach may be to ask developers to update documentation
 as they make changes. 
-Another is to use a tool (for example maven) to collect this information automatically.
+Another is to use a to (for example maven) to collect this information automatically.
 A third is for the release manager to collect all the information required
 when the release is made. The disadvantage of this method is that increases
 the work required to create a release.
@@ -413,10 +413,10 @@
  RELEASE_NOTES (TODO:link). Remember to include a description of the project.
  CHANGES (link) these may be contained in a separate document
  (TODO: maven) or included in the RELEASE NOTES. svn log can be used to collect changes.
-  This is a good opertunity to reinforce the need for good commit messages.
+  This is a good opportunity to reinforce the need for good commit messages.
  CHANGES should also include references to bugs fixed (TODO URLS, searches in JIRA or bugzilla).
  Include a description of the build process either in a README or BUILDING document.
- This should include details of the dependencies (both library and tool) required to build and run 
+ This should include details of the dependencies (both library and to) required to build and run 
  the product but may do so by reference
  CHANGES should note any incompatibilities introduced since the last release.
         	</p>
@@ -432,7 +432,7 @@
         	<p>
 TODO: check this TODO: the STATUS document should be checked to ensure that it is up to date
 before release. Incubator releases should do a <a href='#best-practice-audit'>legal audit</a> 
-before releasing. The legal STATUS of the codebase should be clean before it is released.
+before releasing. The legal STATUS of the code base should be clean before it is released.
         	</p>
         </section>
         <section id='best-practice-license'><title>LICENSE and NOTICE</title>
@@ -441,17 +441,17 @@
 which are not Apache Licensed. TODO link to policy. 
         	</p>
         	<p>
-The artifacts and documents to which each subsidary clause applies should be 
+The artifacts and documents to which each subsidiary clause applies should be 
 indicated in the document. This <a href='examples/LICENSE'>LICENSE</a>
-(curtous of <a href='http://httpd.apache.org'>Apache HTTPD</a>) is a
-good example. The Apache License is at the top of document. The explaination
+(courtesy of <a href='http://httpd.apache.org'>Apache HTTPD</a>) is a
+good example. The Apache License is at the top of document. The explanation
 is clear and the files to which the licenses apply are clearly noted.
         	</p>
         </section>
         <section id='best-practice-audit'><title>Legal Audit</title>
         	<p>
  It is of particular importance that released code is clean. 
- It is good practice to check the provinance of any source documents 
+ It is good practice to check the provenance of any source documents 
  which do not have license headers. Check that dependencies (and in particular
  those dependencies that ship in the distribution) comply with Apache policy.
  Legal policy and interpretation changes from time to time so it is worth investing
@@ -499,14 +499,14 @@
             </p>
             <p>
 Compressed archives should unpack into a contained directory (rather than straight 
-into the current directory). The directory into which the release unpacks should follow
+into the current directory). The directory into which the release unpacks should flow
 the standard naming convention. apache-foo.tar.gz should unpack to the apache-foo
 directory.
             </p>
             <p>
 Note (TODO link) that there are known compatibility issues when using certain tar programs. 
-(TODO solaris verses GNU tar)
-It is recommend that project that use Ant or Maven as build tools use these tools to create
+(TODO Saris verses GNU tar)
+It is recommend that project that use Ant or Maven as build tools, use these tools to create
 the archives since these implementations work well across a range of platforms. 
 It is recommended that project which do not use these tools consider shipping the
 *nix distribution as a bz2 archive.
@@ -536,7 +536,7 @@
         	</p>
         	<p>
 TODO: dependencies also include the tools required to build and test the source.
-tool dependencies are often included in BUILDING or README
+to dependencies are often included in BUILDING or README
         	</p>
         	<p>
 TODO: particularly important for languages. language should be approached
@@ -598,7 +598,7 @@
         </section>
         <section id='best-practices-svn'><title>Subversion Best Practices</title>
         	<p>
-        	TODO: svn is flexible. branchs and tags are not the same as svn.
+        	TODO: svn is flexible. branches and tags are not the same as svn.
         	</p>
         	<p>
 All releases should be built from a tag. It is occasionally necessary to rebuild
@@ -616,15 +616,15 @@
         	<p>
 If <code>svn:externals</code> is used, check carefully that a tag is referenced.
 This ensure that all the source for the release is fixed. If the target of a <code>svn:externals</code>
-changes then the release will no longer be complete reproducable.
+changes then the release will no longer be complete reproducible.
         	</p>
         </section>
-        <section id='best-practice-reproducability'><title>Reproducability</title>
+        <section id='best-practice-reproducability'><title>Reproducibility</title>
         	<p>
 It is important that any release can be reproduced from the source at any time in the future. 
-Apache releases have long active lives and are permenantly archived. 
+Apache releases have long active lives and are permanently archived. 
 It is very occasionally necessary (for example, for legal reasons) 
-to alter some small parts of a release or simply to recreate an old release.
+to alter some small parts of a release or simply to recreate an d release.
 Release managers owe it to those who come afterwards to use build processes
 that are reproducible.
 			</p><p>
@@ -670,13 +670,13 @@
         	<p>
 TODO: release managers should ensure that releases are announced.
 TODO: links to release management FAQs
-TODO: consider grassroot sites eg freshmeat.net
+TODO: consider grassroots sites eg freshmeat.net
 TODO: link note on press release 
         	</p>
         	<p>
 Announcements should be signed by the release manager with the key used to sign the 
 release. Note that this may mean creating a plain text signature on the machine used
-to sign the release and then transfering this.
+to sign the release and then transferring this.
         	</p>
         	<p>
 Announcements should be posted from the release manager's 
@@ -686,7 +686,7 @@
         <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 follow the usual Apache process (including TODO: link release vote)
+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.
             </p>
             <p>
@@ -722,11 +722,11 @@
 			<p>
 Those release adopting a system of blessing a candidate will start by creating a
 candidate which will then be promoted by a series of votes until it either fails
-or reachs full release status. In this case the same candidate will
+or reaches full release status. In this case the same candidate will
 be know as a release candidate, an alpha, a beta and then a full release.
         	</p>
         	<p>
- Those projects which reroll candidates will vote on a sample release candidate.
+Those projects which releases candidates will vote on a sample release candidate.
         	</p>
         	<p>
 Only full releases should be place distributed from the main directories. 
@@ -744,7 +744,7 @@
         	<p>
 It is traditional that release managers use their Apache home space to make available
 release candidates. TODO:link to dev instructions on using Apache web space.
-Please remember to delete old releases.
+Please remember to delete d releases.
         	</p>
         </section>
         <section id='signing-releases'><title>Signatures</title>
@@ -753,7 +753,7 @@
         	</p>
         	<p>
  Ensure that the code signing public key is uploaded to a network in good time.
- It may take some days for keys to propergate to all servers in the network.
+ It may take some days for keys to propagate to all servers in the network.
         	</p>
         	<p>
  Novice signers should read the documentation and practice. Consider using an
@@ -762,14 +762,14 @@
         </section>
         <section id='best-practice-maven'><title>Maven</title>
         	<p>
-<a href='http://maven.apache.org'>Apache Maven</a> is a tool used by many podlings.
+<a href='http://maven.apache.org'>Apache Maven</a> is a to used by many podlings.
 TODO: improve preamble
         	</p>
         	<p>
 It is best to use the <code>groupId</code> and <code>artifactId</code> that will
 be used upon graduation. The version should include <code>incubating</code> 
 (or <code>incubator</code>) to ensure that the artifacts created comply with Incubator
-<a href='/incubation/Incubation_Policy.html#Releases'>release policy</a>.
+<a href='/incubation/Incubation_Picy.html#Releases'>release policy</a>.
         	</p>
         	<p>
 For example
@@ -785,7 +785,7 @@
         <section id='notes-disclaimer'><title>The Incubator Disclaimer</title>
             <p>
             TODO: the incubator requires that users are informed that the by
-            including a strandard disclaimer. may be include in README, RELEASE_NOTES
+            including a standard disclaimer. may be include in README, RELEASE_NOTES
             DISCLAIMER. It is recommended that it is not included in NOTICES
             </p>
         </section>
@@ -795,7 +795,7 @@
             </p>
             <p>
 Jars are just another form of binary distribution. If they are likely to be distributed
-(for example, through the Apache Repository) then they must adhere to the same policy
+(for example, through the Apache Repository) then they must adhere to the same picy
 as other binary distributions. In particular, LICENSE and NOTICE files must be distributed.
             </p>
             <p>
@@ -806,13 +806,13 @@
         <section id='jar-manifest'><title>Jar MANIFEST</title>
             <p>
 TODO
-Lots of projects get this wrong and (by default) most tools produce substandard manifests.
+Lots of projects get this wrong and (by default) most tos produce substandard manifests.
 Offer some guidance on values
-TODO: Add how to create a specification complient MANIFEST 
+TODO: Add how to create a specification compliant MANIFEST 
 http://jakarta.apache.org/commons/releases/prepare.html#checkjarmanifest
             </p>
             <p>
-Maven 1 produces a minimal MANIFEST. This should be augemented with the 
+Maven 1 produces a minimal MANIFEST. This should be augmented with the 
 recommended by adding appropriate 
 <a href='http://maven.apache.org/maven-1.x/plugins/jar/properties.html'>properties</a>
 to the <code>project.properties</code> file.
@@ -846,7 +846,7 @@
  			<p>
  The most common system of versioning is based on <code>major.minor.point</code>
  where major, minor and point are all integers. Note that these are not decimals and
- there is no necessessity to raise a major version number (say) if the minor version has
+ there is no necessity to raise a major version number (say) if the minor version has
  reached 9. The exact rules vary and it is recommended that a project agrees and documents
  its own rules. 
 			</p>
@@ -863,7 +863,7 @@
  releases than to create numerous alphas and betas for 1.0. Conventionally, 0.x releases
  are aimed at early adopters only without a strong promise of easy upgrade or backwards
  compatibility. 0.x is a good designation for a product that is not feature complete 
- but whose code is solid for those features which are implemented.
+ but whose code is sid for those features which are implemented.
         	</p>
         </section>
         <section id='notes-numbering-between-releases'><title>Version Numbering Between Releases</title>
@@ -892,7 +892,7 @@
  Every <a href='glossay-artifact'>artifact</a> distributed should have a name that is unique.
  This allows each artifact to the recognized by its name and ensures that different artifacts do not
  overwrite each other. Including <em>apache</em> in the name of the artifact not only gives
- brand recognition but means influence can be excerted over errant downstream repackages 
+ brand recognition but means influence can be exerted over errant downstream repackages 
  by trademark law. If this practice is adopted then the release manager merely has to ensure 
  that each artifact is uniquely named within the set of Apache artifacts. By including the name of 
  the project, each artifact only has to be unique within the artifacts release by the project. When 
@@ -902,7 +902,7 @@
 For each product, each <a href='best-practice-types'>type of distribution</a> should be 
 assigned a consistent and unique name. Conventionally, source distributions use <code>src</code>
 and main binary distributions no prefix. Typically each type of distributions is made available in a number of 
-<a href='best-practice-formats'>compression format</a>. These are conventionally distiguished 
+<a href='best-practice-formats'>compression format</a>. These are conventionally distinguished 
 by the usual file type suffix.
         	</p>
         	<p>
@@ -916,10 +916,10 @@
 The content presented in the RELEASE_NOTES needs to be plain text etc
             </p>
         	<p>
-Release notes are a vital tool for communication between an open source project 
+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
 impressions matter. Their content will often serve as the basis for TODO: link
-announcements and other TODO: link grassroots pubicity.
+announcements and other TODO: link grassroots publicity.
         	</p>
             <p>
 The content may be replicated in many places. Use the content as news on the
@@ -948,14 +948,14 @@
             </p>
             <p>
 The first paragraph of the release notes should introduce the project and the release.
-It is often useful to characterise the release (TODO examples). Spend time thinking
-about the best organisation. Important information should be prominent.
+It is often useful to characterize the release (TODO examples). Spend time thinking
+about the best organization. Important information should be prominent.
             </p>
             <p>
 The exact contents of the release notes varies and it is not unusual for 
 this content to be distributed amongst several documents. This is fine:
 these recommendations should be viewed as pertaining to the mass of
-notes that accumpany the release and do not need to be included 
+notes that accompany the release and do not need to be included 
 in any particular document.
             </p>
             <p>
@@ -1027,7 +1027,7 @@
         	</p>
         	<p>
 Change logs can be created in various ways. Some project ask committers to fill
-in details each time they commit. Other rely on analysing the commit messages
+in details each time they commit. Other rely on analyzing the commit messages
 when the release is prepared. (To do this, go through the logs since the revision
 of the last release. TODO example)
         	</p>
@@ -1045,7 +1045,7 @@
 TODO: consider moving content into foundation docs
         	</p>
         	<p>
-OpenPGP compatible signatures must be generated to accumpiany releases.
+OpenPGP compatible signatures must be generated to accompany 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
@@ -1063,7 +1063,7 @@
  release managers knows whether a signature is their own.
         	</p>   	
         </section>
-        <section id='note-on-multiple-products'><title>On Mutiple Products</title>
+        <section id='note-on-multiple-products'><title>On Multiple Products</title>
         	<p>
 A project may release a number of distinction products created by the same community.
 TODO: differences between products and distributions.
@@ -1083,7 +1083,7 @@
         	</p>
         	<p>
 However, if this template is used by a user to generate output, usually
-this output should be free of license restributions. Most templating languages
+this output should be free of license restrictions. Most templating languages
 allow comments which are not included in the output. If this is allowed
 then the license header should be included in the template as a comment.
 If not then consider adding a NOTE or a README to the directory rather 
@@ -1094,7 +1094,7 @@
         	<p>
 Indicating supported versions for dependencies is 
 <a href='#best-practice-dependencies'>important</a>. The minimum 
-(and - where appropriate - maxiumum)  Java version need to be clearly documented
+(and - where appropriate - maximum)  Java version need to be clearly documented
 in the release. This information should be included in a README or the RELEASE NOTES.
         	</p>
         	<p>
@@ -1106,7 +1106,7 @@
  			</p>
  			<p>
 If the version in the MANIFEST cannot reflect the minimum support version (see below) 
-then it is recommended that the following additional entries are added to MANIFEST.
+then it is recommended that the flowing additional entries are added to MANIFEST.
  			</p>
  			<p>
 The usual reason for need to use a more modern Java version is to support
@@ -1115,13 +1115,13 @@
 			<p>
 The approach which requires the least configuration is to adopt a split compilation
 strategy. The release manager installs two separate Java versions. The build
-script supports optional parameterisation allowing the optional code to be compiled with 
+script supports optional parameterization allowing the optional code to be compiled with 
 a second JSDK. It is recommended that the build scrip includes clear indications
 that a second JSDK has been detected.
  			</p>
  			<p>
 The alternative is to correctly configure a more modern JSDK to compile code
-which will function correctly on an older JRE. This means TODO: javac settings through 
+which will function correctly on another JRE. This means TODO: javac settings through 
 Ant. This is not sufficient. Unfortunately the source also need to be compiled against
 the appropriate version of the Java API. TODO: check where the jar has to be exactly
 placed.
@@ -1129,12 +1129,12 @@
         </section>
         <section id='notes-on-export-regulations'><title>On Export Regulations</title>
         	<p>
-TODO preable TODO link to legal
+TODO preamble TODO link to legal
         	</p>
         </section>
         <section id='notes-on-compression-formats'><title></title>
         TODO: discuss merits tgz, bz, bz2
-        TODO: problems with incompatibilities with older version of some utilities
+        TODO: problems with incompatibilities with different version of some utilities
         </section>
         <section id='notes-on-line-endings'><title>On Line Endings</title>
         	<p>
@@ -1144,7 +1144,7 @@
 for the <code>zip</code> and <code>LF</code> for the <code>tar.gz</code>).
         	</p>
             <p>
-Source distributions can use <code>svn export --native-eols</code>. Binary distributions
+Source distributions can use <code>svn export --native-es</code>. Binary distributions
 build with <a href='http://ant.apace.org'>Ant</a> can use 
 <a href='http://ant.apache.org/manual/CoreTasks/fixcrlf.html'>fixcrlf</a>.
             </p>
@@ -1161,7 +1161,7 @@
         </section>
         <section id='notes-on-signing-jars'><title>On Signing Jars</title>
         	<p>
-Java includes a standard mechanism for signing jars. Apache uses digitial
+Java includes a standard mechanism for signing jars. Apache uses digital
 signatures to protect releases. TODO: reconsider this section.
         	</p>
         	<p>
@@ -1180,11 +1180,11 @@
             All source capable of copyright should contain license header. 
             Easiest way to comply is to ensure that every human readable file has the header. 
             Note that source includes not just the source code compiled into the final product 
-            but also all other resources such as stylesheets, test code and resources, build files 
+            but also all other resources such as style sheets, test code and resources, build files 
             and documentation source. When in doubt, add a header.
             </p>
             <p>
-            TODO: tool
+            TODO: to
             </p>
             <p>
 The issue of licenses on generated documentation is a little controversial. Copyright may not subsist
@@ -1196,33 +1196,33 @@
 TODO: check with legal-discuss then move this content into the legal pages and link with commentary
             </p>
 			<p>
-TODO: link into provinance
+TODO: link into provenance
 			</p>
         </section>
-        <section id='note-privinence'><title>Code Provinance</title>
+        <section id='code-provenance'><title>Code Provenance</title>
 			<p>
 <a href='LINK'>License headers</a> may seem trivial and to some extent that is true. 
-The important issue is code provinence. All code contributions must be tracked and the 
-provinence of the code traceable. 
+The important issue is code provenance. All code contributions must be tracked and the 
+provenance of the code traceable. 
 			</p>
 			<p>
-Commit comments are an important tool. When source
+Commit comments are an important to. When source
 which is not originally created for the project is committed, the message should contain
-details about the provinance of that source. When a patch is applied from an 
+details about the provenance of that source. When a patch is applied from an 
 <a href='#glossary-issue-tracker'>issue tracking system</a>
 system, the issue should be noted in the commit message. 
 			</p>
 			<p>
-Releases are important. Released code is distributed widely. It is important that the provinance
+Releases are important. Released code is distributed widely. It is important that the provenance
 for all released code is known and is appropriate. License headers are a way of documenting 
-provinence. Any source which is created for Apache should have the standard boilerplate text.
+provenance. Any source which is created for Apache should have the standard boilerplate text.
 Other source should have the headers (copyright and license) retained. Before a release,
 source which has not been originally created for (or donated to) Apache should be checked
 against the current Apache policy. 
 			</p>
 			<p>
 Any source which does not have a license header must be considered suspect 
-and it's provinence checked. There are several classes of source which do not require
+and it's 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.
@@ -1254,7 +1254,7 @@
  include a readable copy of the attribution notices contained
  within such NOTICE file, excluding those notices that do not
  pertain to any part of the Derivative Works, in at least one
- of the following places: within a NOTICE text file distributed
+ of the flowing places: within a NOTICE text file distributed
  as part of the Derivative Works; within the Source form or
  documentation, if provided along with the Derivative Works; or,
  within a display generated by the Derivative Works, if and
@@ -1314,7 +1314,7 @@
         	<p>
 When proposing a formal VOTE, it is useful to adopt a conventional form. VOTE threads
 are conventionally prefixed by a [VOTE] subject. This helps everyone recognize that 
-this is a formal decision and to prioritise their reply. Many people filter their emails 
+this is a formal decision and to prioritize their reply. Many people filter their emails 
 into separate <code>VOTE</code> directories by using this prefix.
         	</p>
         	<p>
@@ -1352,8 +1352,8 @@
         	<p>
 When posting replies to a VOTE thread take particular care to change the subject.
 When changing the subject it is conventional to reply to the relevant post and then edit the subject
-adding the new subject followed by <code>[WAS</code> and the old subject.
-For example, old subject <code>Re: Whatever</code> may be edited to 
+adding the new subject flowed by <code>[WAS</code> and the d subject.
+For example, d subject <code>Re: Whatever</code> may be edited to 
 <code>New Foo [WAS  Re:Whatever]</code>. This ensures that the thread linkage between the topics
 is retained but also makes it clear that the post now relates to a new subject.
         	</p>
@@ -1386,7 +1386,7 @@
 unfamiliar with these environments to find difficulties.
         	</p>
         	<p>
-Long VOTE threads are hard to tally. Each opinion needs to be noted and ackowledged.
+Long VOTE threads are hard to tally. Each opinion needs to be noted and acknowledged.
 This allows people to check their votes and easily correct mistakes in the count.
         	</p>
         	<p>
@@ -1397,7 +1397,7 @@
  other subjects. 
         	</p>
         	<p>
- It is usually cleaner to abandone a VOTE thread that goes estray or when the proposal
+ It is usually cleaner to abandon a VOTE thread that goes astray or when the proposal
  needs to be altered - for example, then issues are found in a release candidate. 
  Start a new VOTE thread with the revised proposal (in the case of the example, a new
  release candidate).
@@ -1405,8 +1405,8 @@
         </section>
         <section id='notes-release-candidate-java'><title>On Java Release Candidates</title>
 			<p>
-This section applies to any distribution that contains redistributable artifacts which contain version
-information but in particular binary distributions of Java contain jar files. A complient MANIFEST 
+This section applies to any distribution that contains re-distributable artifacts which contain version
+information but in particular binary distributions of Java contain jar files. A compliant MANIFEST 
 meta data file within each of these files should contain the implementation version.
 These are good reasons to use the release version number as the implementation version.
 This allows the exact version to be determined from just the jar.
@@ -1414,7 +1414,7 @@
 			</p>
 			<p>
 This does mean that release candidates for binary distributions of this type must either
-be rerolled with the version number as the only change or accept that artifacts will not be 
+be rereleased with the version number as the only change or accept that artifacts will not be 
 uniquely named. Uncertainty about exact jar versions has caused nasty dependency
 issues in the past.
 			</p>
@@ -1422,8 +1422,8 @@
         <section id='notes-on-gnu-tar'><title>GNU Tar Known Incompatibilities</title>
         	<p>
 Typically, applications used to create <code>tar.gz</code> files are based on
-GNU tar. Unfortunately, the tar which ships with some versions of Solaris and some
-(older) versions of MacOSX is not always compatible with the output of GNU tar.
+GNU tar. Unfortunately, the tar which ships with some versions of Saris and some
+(der) versions of MacOSX is not always compatible with the output of GNU tar.
         	TODO: check information and expand
         	</p>
         </section>
@@ -1439,7 +1439,7 @@
         <section id='notes-on-binary-only-releases'><title>On Binary Only Releases</title>
         	<p>
 Releases containing only binary distributions are strongly frowned upon. Open source 
-development is characterised by the accessibility of the source. Binary only distributions
+development is characterized by the accessibility of the source. Binary only distributions
 discourage developers from interacting with the source. Every successful Apache
 project needs to recruit new developers to carry the project forward.
         	</p>
@@ -1491,12 +1491,12 @@
         </section>
         <section id='glossary-release-manager'><title>Release Manager</title>
         	<p>
-Committer responsible for sheparding the release. 
+Committer responsible for shepherding the release. 
         	</p>
             <p>
             TODO (include link to infra documentation)
             TODO say something about the technical release manager (who
-            cuts the release) and the social one (who organises it).
+            cuts the release) and the social one (who organizes it).
             </p>
         </section>
         <section id='glossary-release-candidate'><title>Release Candidate</title>
@@ -1528,7 +1528,7 @@
         </section>
         <section id='glossary-cutting-release'><title>Cutting The Release</title>
         	<p>
-The actual execution of the release. Typically consists of building the distribtions
+The actual execution of the release. Typically consists of building the distributions
 from the repository tag.
 TODO: link to infra
         	</p>

Modified: incubator/public/trunk/site-author/projects/wicket.xml
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-author/projects/wicket.xml?view=diff&rev=534131&r1=534130&r2=534131
==============================================================================
--- incubator/public/trunk/site-author/projects/wicket.xml (original)
+++ incubator/public/trunk/site-author/projects/wicket.xml Tue May  1 08:50:37 2007
@@ -197,16 +197,14 @@
 </th>
             </tr>
             <tr>
-              <td>....-..-..
-</td>
+              <td>2006-08-24</td>
               <td>Make sure that the requested project name does not already exist and
 check www.nameprotect.com to be sure that the name is not already
 trademarked for an existing software product.
 </td>
             </tr>
             <tr>
-              <td>....-..-..
-</td>
+              <td>....-..-..</td>
               <td>If request from an existing Apache project to adopt an external
 package, then ask the Apache project for the SVN module and mail
 address names.

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=534131&r1=534130&r2=534131
==============================================================================
--- incubator/public/trunk/site-publish/guides/releasemanagement.html (original)
+++ incubator/public/trunk/site-publish/guides/releasemanagement.html Tue May  1 08:50:37 2007
@@ -119,7 +119,7 @@
 It contains advice on best practice, links to Apache release management 
 <a href="http://www.apache.org/dev/index.html#releases">policy and practice</a> 
 with commentary and discusses incubation release management  
-<a href="/incubation/Incubation_Policy.html#Releases">policy</a>. 
+<a href="/incubation/Incubation_Picy.html#Releases">policy</a>. 
             </p>
 </div>
 <h3>
@@ -141,11 +141,11 @@
         </p>
 </div>
 <h3>
-   Organisation
+   Organization
 </h3>
 <div class="section-content">
 <p>
-			TODO: describe organisation of this document.
+			TODO: describe organization of this document.
 			</p>
 </div>
 <h3>
@@ -195,7 +195,7 @@
  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 publically held to account 
+ 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>
@@ -208,27 +208,27 @@
 			</p>
 </div>
 <h3>
-   <a name="policies">ASF Release Policy</a>
+   <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 complient releases first time).
-Releases are important from a legal and organisational perspective. To create a release 
+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 liabiiity
-for the content of the releaes. For official Apache releases conducted
+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 committe to exercise oversight to
+ 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. 
@@ -288,9 +288,9 @@
 <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 organisations,
+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 marshalling the VOTEs required for formal approval
+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>
@@ -319,7 +319,7 @@
                     </li>
                     <li>Check copyright notices:
                     	<ul>
-	                    	<li>Licences missing from source files</li>
+	                    	<li>Licenses missing from source files</li>
 	                    	<li>Source files with other licenses which are not mentioned in LICENSE</li>
 	                    	<li>Check current policy on headers that all comply</li>
                     	</ul>
@@ -380,11 +380,11 @@
 <p>
 In addition to policy, the infrastructure, public relations and legal teams also
 document <a href="#glossary-guidelines">guidelines</a> for projects.
-There are almost certainly good reasons why a project should follow
+There are almost certainly good reasons why a project should flow
 these guidelines but they have not been blessed as policy.
     	</p>
 <p>
-Guidelines change much more frequently than policy. Release managers should follow the appropriate
+Guidelines change much more frequently than policy. Release managers should flow the appropriate
 lists (TODO: create list of useful mailing lists).
     	</p>
 </div>
@@ -397,7 +397,7 @@
 </h3>
 <div class="section-content">
 <ul>
-				<li>Analyse <a href="#best-practice-prepare-documentation">bugs</a></li>
+				<li>Analyze <a href="#best-practice-prepare-documentation">bugs</a></li>
 				<li>Check <a href="#best-practice-prepare-documentation">documentation</a></li>
 			</ul>
 </div>
@@ -406,15 +406,15 @@
 </h3>
 <div class="section-content">
 <p>
-The list of open issues needs to be analysed. The community needs to decide which 
+The list of open issues needs to be analyzed. The community needs to decide which 
 issues could be resolved for this release and how much energy the community
 has to deal with these. Time may also become a factor: some issues which 
 cannot be resolved promptly may need to be postponed.
     		</p>
 <p>
 Issue tracking system can be used to help this process especially for complex projects 
-with many open issues. Each open issues should be analysed and marked appropriately.
-An accurate view of those bugs which are targetted for the upcoming release helps
+with many open issues. Each open issues should be analyzed and marked appropriately.
+An accurate view of those bugs which are targeted for the upcoming release helps
 to concentrate community effort. Consider asking reporters to donate unit tests.
     		</p>
 </div>
@@ -424,7 +424,7 @@
 <div class="section-content">
 <p>
 Any documentation that the release contains should be proof-read and spell checked.
-This is obviously something that needs to happen after the content is finalised.
+This is obviously something that needs to happen after the content is finalized.
 So typically, the release manager needs to coordinate the documentation effort.
 A release is a good time to concentrate energy on documentation.
     		</p>
@@ -461,8 +461,8 @@
 </h3>
 <div class="section-content">
 <p>
- TODO: glossay - distribution type: based on the same tagged source built  
- TODO: Common Types of distribtuion
+ TODO: glossary - distribution type: based on the same tagged source built  
+ TODO: Common Types of distribution
  			</p>
 <p>
  The source distribution is canonical. Every release should create a source distribution.
@@ -479,9 +479,9 @@
 </h3>
 <div class="section-content">
 <p>
- TODO: glossay - downstream packager: takes an apache release and packages it for a particular platform.
+ TODO: glossary - downstream packager: takes an apache release and packages it for a particular platform.
  TODO: best practice is to work with downstream packagers and link to their packages
- rather than roll own packages. need to add notes that these are not official releases.
+ rather than rl own packages. need to add notes that these are not official releases.
  TODO: link to notes on working with downstream packagers
         	</p>
 <p>
@@ -515,7 +515,7 @@
 <p>
 It is strongly recommended that source distributions are included in every release.
 Many packagers (for example, FreeBSD and linux distributions) prefer or demand
-to work from source releases. Archivists prefer source. Many large organisations
+to work from source releases. Archivists prefer source. Many large organizations
 prefer to verify and then build their own versions from source. A source distribution
 is easy to create but helps to reach these audiences.
         	</p>
@@ -551,7 +551,7 @@
 Collecting all this information may seem a little daunting especially for a starting project.
 Not at all agile. One approach may be to ask developers to update documentation
 as they make changes. 
-Another is to use a tool (for example maven) to collect this information automatically.
+Another is to use a to (for example maven) to collect this information automatically.
 A third is for the release manager to collect all the information required
 when the release is made. The disadvantage of this method is that increases
 the work required to create a release.
@@ -567,10 +567,10 @@
  RELEASE_NOTES (TODO:link). Remember to include a description of the project.
  CHANGES (link) these may be contained in a separate document
  (TODO: maven) or included in the RELEASE NOTES. svn log can be used to collect changes.
-  This is a good opertunity to reinforce the need for good commit messages.
+  This is a good opportunity to reinforce the need for good commit messages.
  CHANGES should also include references to bugs fixed (TODO URLS, searches in JIRA or bugzilla).
  Include a description of the build process either in a README or BUILDING document.
- This should include details of the dependencies (both library and tool) required to build and run 
+ This should include details of the dependencies (both library and to) required to build and run 
  the product but may do so by reference
  CHANGES should note any incompatibilities introduced since the last release.
         	</p>
@@ -589,7 +589,7 @@
 <p>
 TODO: check this TODO: the STATUS document should be checked to ensure that it is up to date
 before release. Incubator releases should do a <a href="#best-practice-audit">legal audit</a> 
-before releasing. The legal STATUS of the codebase should be clean before it is released.
+before releasing. The legal STATUS of the code base should be clean before it is released.
         	</p>
 </div>
 <h3>
@@ -601,10 +601,10 @@
 which are not Apache Licensed. TODO link to policy. 
         	</p>
 <p>
-The artifacts and documents to which each subsidary clause applies should be 
+The artifacts and documents to which each subsidiary clause applies should be 
 indicated in the document. This <a href="examples/LICENSE">LICENSE</a>
-(curtous of <a href="http://httpd.apache.org">Apache HTTPD</a>) is a
-good example. The Apache License is at the top of document. The explaination
+(courtesy of <a href="http://httpd.apache.org">Apache HTTPD</a>) is a
+good example. The Apache License is at the top of document. The explanation
 is clear and the files to which the licenses apply are clearly noted.
         	</p>
 </div>
@@ -614,7 +614,7 @@
 <div class="section-content">
 <p>
  It is of particular importance that released code is clean. 
- It is good practice to check the provinance of any source documents 
+ It is good practice to check the provenance of any source documents 
  which do not have license headers. Check that dependencies (and in particular
  those dependencies that ship in the distribution) comply with Apache policy.
  Legal policy and interpretation changes from time to time so it is worth investing
@@ -667,14 +667,14 @@
             </p>
 <p>
 Compressed archives should unpack into a contained directory (rather than straight 
-into the current directory). The directory into which the release unpacks should follow
+into the current directory). The directory into which the release unpacks should flow
 the standard naming convention. apache-foo.tar.gz should unpack to the apache-foo
 directory.
             </p>
 <p>
 Note (TODO link) that there are known compatibility issues when using certain tar programs. 
-(TODO solaris verses GNU tar)
-It is recommend that project that use Ant or Maven as build tools use these tools to create
+(TODO Saris verses GNU tar)
+It is recommend that project that use Ant or Maven as build tools, use these tools to create
 the archives since these implementations work well across a range of platforms. 
 It is recommended that project which do not use these tools consider shipping the
 *nix distribution as a bz2 archive.
@@ -710,7 +710,7 @@
         	</p>
 <p>
 TODO: dependencies also include the tools required to build and test the source.
-tool dependencies are often included in BUILDING or README
+to dependencies are often included in BUILDING or README
         	</p>
 <p>
 TODO: particularly important for languages. language should be approached
@@ -780,7 +780,7 @@
 </h3>
 <div class="section-content">
 <p>
-        	TODO: svn is flexible. branchs and tags are not the same as svn.
+        	TODO: svn is flexible. branches and tags are not the same as svn.
         	</p>
 <p>
 All releases should be built from a tag. It is occasionally necessary to rebuild
@@ -798,18 +798,18 @@
 <p>
 If <code>svn:externals</code> is used, check carefully that a tag is referenced.
 This ensure that all the source for the release is fixed. If the target of a <code>svn:externals</code>
-changes then the release will no longer be complete reproducable.
+changes then the release will no longer be complete reproducible.
         	</p>
 </div>
 <h3>
-   <a name="best-practice-reproducability">Reproducability</a>
+   <a name="best-practice-reproducability">Reproducibility</a>
 </h3>
 <div class="section-content">
 <p>
 It is important that any release can be reproduced from the source at any time in the future. 
-Apache releases have long active lives and are permenantly archived. 
+Apache releases have long active lives and are permanently archived. 
 It is very occasionally necessary (for example, for legal reasons) 
-to alter some small parts of a release or simply to recreate an old release.
+to alter some small parts of a release or simply to recreate an d release.
 Release managers owe it to those who come afterwards to use build processes
 that are reproducible.
 			</p>
@@ -866,13 +866,13 @@
 <p>
 TODO: release managers should ensure that releases are announced.
 TODO: links to release management FAQs
-TODO: consider grassroot sites eg freshmeat.net
+TODO: consider grassroots sites eg freshmeat.net
 TODO: link note on press release 
         	</p>
 <p>
 Announcements should be signed by the release manager with the key used to sign the 
 release. Note that this may mean creating a plain text signature on the machine used
-to sign the release and then transfering this.
+to sign the release and then transferring this.
         	</p>
 <p>
 Announcements should be posted from the release manager's 
@@ -885,7 +885,7 @@
 <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 follow the usual Apache process (including TODO: link release vote)
+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.
             </p>
 <p>
@@ -927,11 +927,11 @@
 <p>
 Those release adopting a system of blessing a candidate will start by creating a
 candidate which will then be promoted by a series of votes until it either fails
-or reachs full release status. In this case the same candidate will
+or reaches full release status. In this case the same candidate will
 be know as a release candidate, an alpha, a beta and then a full release.
         	</p>
 <p>
- Those projects which reroll candidates will vote on a sample release candidate.
+Those projects which releases candidates will vote on a sample release candidate.
         	</p>
 <p>
 Only full releases should be place distributed from the main directories. 
@@ -949,7 +949,7 @@
 <p>
 It is traditional that release managers use their Apache home space to make available
 release candidates. TODO:link to dev instructions on using Apache web space.
-Please remember to delete old releases.
+Please remember to delete d releases.
         	</p>
 </div>
 <h3>
@@ -961,7 +961,7 @@
         	</p>
 <p>
  Ensure that the code signing public key is uploaded to a network in good time.
- It may take some days for keys to propergate to all servers in the network.
+ It may take some days for keys to propagate to all servers in the network.
         	</p>
 <p>
  Novice signers should read the documentation and practice. Consider using an
@@ -973,14 +973,14 @@
 </h3>
 <div class="section-content">
 <p>
-<a href="http://maven.apache.org">Apache Maven</a> is a tool used by many podlings.
+<a href="http://maven.apache.org">Apache Maven</a> is a to used by many podlings.
 TODO: improve preamble
         	</p>
 <p>
 It is best to use the <code>groupId</code> and <code>artifactId</code> that will
 be used upon graduation. The version should include <code>incubating</code> 
 (or <code>incubator</code>) to ensure that the artifacts created comply with Incubator
-<a href="/incubation/Incubation_Policy.html#Releases">release policy</a>.
+<a href="/incubation/Incubation_Picy.html#Releases">release policy</a>.
         	</p>
 <p>
 For example
@@ -1002,7 +1002,7 @@
 <div class="section-content">
 <p>
             TODO: the incubator requires that users are informed that the by
-            including a strandard disclaimer. may be include in README, RELEASE_NOTES
+            including a standard disclaimer. may be include in README, RELEASE_NOTES
             DISCLAIMER. It is recommended that it is not included in NOTICES
             </p>
 </div>
@@ -1015,7 +1015,7 @@
             </p>
 <p>
 Jars are just another form of binary distribution. If they are likely to be distributed
-(for example, through the Apache Repository) then they must adhere to the same policy
+(for example, through the Apache Repository) then they must adhere to the same picy
 as other binary distributions. In particular, LICENSE and NOTICE files must be distributed.
             </p>
 <p>
@@ -1029,13 +1029,13 @@
 <div class="section-content">
 <p>
 TODO
-Lots of projects get this wrong and (by default) most tools produce substandard manifests.
+Lots of projects get this wrong and (by default) most tos produce substandard manifests.
 Offer some guidance on values
-TODO: Add how to create a specification complient MANIFEST 
+TODO: Add how to create a specification compliant MANIFEST 
 http://jakarta.apache.org/commons/releases/prepare.html#checkjarmanifest
             </p>
 <p>
-Maven 1 produces a minimal MANIFEST. This should be augemented with the 
+Maven 1 produces a minimal MANIFEST. This should be augmented with the 
 recommended by adding appropriate 
 <a href="http://maven.apache.org/maven-1.x/plugins/jar/properties.html">properties</a>
 to the <code>project.properties</code> file.
@@ -1075,7 +1075,7 @@
 <p>
  The most common system of versioning is based on <code>major.minor.point</code>
  where major, minor and point are all integers. Note that these are not decimals and
- there is no necessessity to raise a major version number (say) if the minor version has
+ there is no necessity to raise a major version number (say) if the minor version has
  reached 9. The exact rules vary and it is recommended that a project agrees and documents
  its own rules. 
 			</p>
@@ -1093,7 +1093,7 @@
  releases than to create numerous alphas and betas for 1.0. Conventionally, 0.x releases
  are aimed at early adopters only without a strong promise of easy upgrade or backwards
  compatibility. 0.x is a good designation for a product that is not feature complete 
- but whose code is solid for those features which are implemented.
+ but whose code is sid for those features which are implemented.
         	</p>
 </div>
 <h3>
@@ -1128,7 +1128,7 @@
  Every <a href="glossay-artifact">artifact</a> distributed should have a name that is unique.
  This allows each artifact to the recognized by its name and ensures that different artifacts do not
  overwrite each other. Including <em>apache</em> in the name of the artifact not only gives
- brand recognition but means influence can be excerted over errant downstream repackages 
+ brand recognition but means influence can be exerted over errant downstream repackages 
  by trademark law. If this practice is adopted then the release manager merely has to ensure 
  that each artifact is uniquely named within the set of Apache artifacts. By including the name of 
  the project, each artifact only has to be unique within the artifacts release by the project. When 
@@ -1138,7 +1138,7 @@
 For each product, each <a href="best-practice-types">type of distribution</a> should be 
 assigned a consistent and unique name. Conventionally, source distributions use <code>src</code>
 and main binary distributions no prefix. Typically each type of distributions is made available in a number of 
-<a href="best-practice-formats">compression format</a>. These are conventionally distiguished 
+<a href="best-practice-formats">compression format</a>. These are conventionally distinguished 
 by the usual file type suffix.
         	</p>
 <p>
@@ -1155,10 +1155,10 @@
 The content presented in the RELEASE_NOTES needs to be plain text etc
             </p>
 <p>
-Release notes are a vital tool for communication between an open source project 
+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
 impressions matter. Their content will often serve as the basis for TODO: link
-announcements and other TODO: link grassroots pubicity.
+announcements and other TODO: link grassroots publicity.
         	</p>
 <p>
 The content may be replicated in many places. Use the content as news on the
@@ -1187,14 +1187,14 @@
             </p>
 <p>
 The first paragraph of the release notes should introduce the project and the release.
-It is often useful to characterise the release (TODO examples). Spend time thinking
-about the best organisation. Important information should be prominent.
+It is often useful to characterize the release (TODO examples). Spend time thinking
+about the best organization. Important information should be prominent.
             </p>
 <p>
 The exact contents of the release notes varies and it is not unusual for 
 this content to be distributed amongst several documents. This is fine:
 these recommendations should be viewed as pertaining to the mass of
-notes that accumpany the release and do not need to be included 
+notes that accompany the release and do not need to be included 
 in any particular document.
             </p>
 <p>
@@ -1272,7 +1272,7 @@
         	</p>
 <p>
 Change logs can be created in various ways. Some project ask committers to fill
-in details each time they commit. Other rely on analysing the commit messages
+in details each time they commit. Other rely on analyzing the commit messages
 when the release is prepared. (To do this, go through the logs since the revision
 of the last release. TODO example)
         	</p>
@@ -1293,7 +1293,7 @@
 TODO: consider moving content into foundation docs
         	</p>
 <p>
-OpenPGP compatible signatures must be generated to accumpiany releases.
+OpenPGP compatible signatures must be generated to accompany 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
@@ -1315,7 +1315,7 @@
         	</p>
 </div>
 <h3>
-   <a name="note-on-multiple-products">On Mutiple Products</a>
+   <a name="note-on-multiple-products">On Multiple Products</a>
 </h3>
 <div class="section-content">
 <p>
@@ -1340,7 +1340,7 @@
         	</p>
 <p>
 However, if this template is used by a user to generate output, usually
-this output should be free of license restributions. Most templating languages
+this output should be free of license restrictions. Most templating languages
 allow comments which are not included in the output. If this is allowed
 then the license header should be included in the template as a comment.
 If not then consider adding a NOTE or a README to the directory rather 
@@ -1354,7 +1354,7 @@
 <p>
 Indicating supported versions for dependencies is 
 <a href="#best-practice-dependencies">important</a>. The minimum 
-(and - where appropriate - maxiumum)  Java version need to be clearly documented
+(and - where appropriate - maximum)  Java version need to be clearly documented
 in the release. This information should be included in a README or the RELEASE NOTES.
         	</p>
 <p>
@@ -1366,7 +1366,7 @@
  			</p>
 <p>
 If the version in the MANIFEST cannot reflect the minimum support version (see below) 
-then it is recommended that the following additional entries are added to MANIFEST.
+then it is recommended that the flowing additional entries are added to MANIFEST.
  			</p>
 <p>
 The usual reason for need to use a more modern Java version is to support
@@ -1375,13 +1375,13 @@
 <p>
 The approach which requires the least configuration is to adopt a split compilation
 strategy. The release manager installs two separate Java versions. The build
-script supports optional parameterisation allowing the optional code to be compiled with 
+script supports optional parameterization allowing the optional code to be compiled with 
 a second JSDK. It is recommended that the build scrip includes clear indications
 that a second JSDK has been detected.
  			</p>
 <p>
 The alternative is to correctly configure a more modern JSDK to compile code
-which will function correctly on an older JRE. This means TODO: javac settings through 
+which will function correctly on another JRE. This means TODO: javac settings through 
 Ant. This is not sufficient. Unfortunately the source also need to be compiled against
 the appropriate version of the Java API. TODO: check where the jar has to be exactly
 placed.
@@ -1392,7 +1392,7 @@
 </h3>
 <div class="section-content">
 <p>
-TODO preable TODO link to legal
+TODO preamble TODO link to legal
         	</p>
 </div>
 <h3>
@@ -1411,7 +1411,7 @@
 for the <code>zip</code> and <code>LF</code> for the <code>tar.gz</code>).
         	</p>
 <p>
-Source distributions can use <code>svn export --native-eols</code>. Binary distributions
+Source distributions can use <code>svn export --native-es</code>. Binary distributions
 build with <a href="http://ant.apace.org">Ant</a> can use 
 <a href="http://ant.apache.org/manual/CoreTasks/fixcrlf.html">fixcrlf</a>.
             </p>
@@ -1434,7 +1434,7 @@
 </h3>
 <div class="section-content">
 <p>
-Java includes a standard mechanism for signing jars. Apache uses digitial
+Java includes a standard mechanism for signing jars. Apache uses digital
 signatures to protect releases. TODO: reconsider this section.
         	</p>
 <p>
@@ -1456,11 +1456,11 @@
             All source capable of copyright should contain license header. 
             Easiest way to comply is to ensure that every human readable file has the header. 
             Note that source includes not just the source code compiled into the final product 
-            but also all other resources such as stylesheets, test code and resources, build files 
+            but also all other resources such as style sheets, test code and resources, build files 
             and documentation source. When in doubt, add a header.
             </p>
 <p>
-            TODO: tool
+            TODO: to
             </p>
 <p>
 The issue of licenses on generated documentation is a little controversial. Copyright may not subsist
@@ -1472,36 +1472,36 @@
 TODO: check with legal-discuss then move this content into the legal pages and link with commentary
             </p>
 <p>
-TODO: link into provinance
+TODO: link into provenance
 			</p>
 </div>
 <h3>
-   <a name="note-privinence">Code Provinance</a>
+   <a name="code-provenance">Code Provenance</a>
 </h3>
 <div class="section-content">
 <p>
 <a href="LINK">License headers</a> may seem trivial and to some extent that is true. 
-The important issue is code provinence. All code contributions must be tracked and the 
-provinence of the code traceable. 
+The important issue is code provenance. All code contributions must be tracked and the 
+provenance of the code traceable. 
 			</p>
 <p>
-Commit comments are an important tool. When source
+Commit comments are an important to. When source
 which is not originally created for the project is committed, the message should contain
-details about the provinance of that source. When a patch is applied from an 
+details about the provenance of that source. When a patch is applied from an 
 <a href="#glossary-issue-tracker">issue tracking system</a>
 system, the issue should be noted in the commit message. 
 			</p>
 <p>
-Releases are important. Released code is distributed widely. It is important that the provinance
+Releases are important. Released code is distributed widely. It is important that the provenance
 for all released code is known and is appropriate. License headers are a way of documenting 
-provinence. Any source which is created for Apache should have the standard boilerplate text.
+provenance. Any source which is created for Apache should have the standard boilerplate text.
 Other source should have the headers (copyright and license) retained. Before a release,
 source which has not been originally created for (or donated to) Apache should be checked
 against the current Apache policy. 
 			</p>
 <p>
 Any source which does not have a license header must be considered suspect 
-and it's provinence checked. There are several classes of source which do not require
+and it's 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.
@@ -1542,7 +1542,7 @@
  include a readable copy of the attribution notices contained
  within such NOTICE file, excluding those notices that do not
  pertain to any part of the Derivative Works, in at least one
- of the following places: within a NOTICE text file distributed
+ of the flowing places: within a NOTICE text file distributed
  as part of the Derivative Works; within the Source form or
  documentation, if provided along with the Derivative Works; or,
  within a display generated by the Derivative Works, if and
@@ -1605,7 +1605,7 @@
 <p>
 When proposing a formal VOTE, it is useful to adopt a conventional form. VOTE threads
 are conventionally prefixed by a [VOTE] subject. This helps everyone recognize that 
-this is a formal decision and to prioritise their reply. Many people filter their emails 
+this is a formal decision and to prioritize their reply. Many people filter their emails 
 into separate <code>VOTE</code> directories by using this prefix.
         	</p>
 <p>
@@ -1643,8 +1643,8 @@
 <p>
 When posting replies to a VOTE thread take particular care to change the subject.
 When changing the subject it is conventional to reply to the relevant post and then edit the subject
-adding the new subject followed by <code>[WAS</code> and the old subject.
-For example, old subject <code>Re: Whatever</code> may be edited to 
+adding the new subject flowed by <code>[WAS</code> and the d subject.
+For example, d subject <code>Re: Whatever</code> may be edited to 
 <code>New Foo [WAS  Re:Whatever]</code>. This ensures that the thread linkage between the topics
 is retained but also makes it clear that the post now relates to a new subject.
         	</p>
@@ -1683,7 +1683,7 @@
 unfamiliar with these environments to find difficulties.
         	</p>
 <p>
-Long VOTE threads are hard to tally. Each opinion needs to be noted and ackowledged.
+Long VOTE threads are hard to tally. Each opinion needs to be noted and acknowledged.
 This allows people to check their votes and easily correct mistakes in the count.
         	</p>
 <p>
@@ -1694,7 +1694,7 @@
  other subjects. 
         	</p>
 <p>
- It is usually cleaner to abandone a VOTE thread that goes estray or when the proposal
+ It is usually cleaner to abandon a VOTE thread that goes astray or when the proposal
  needs to be altered - for example, then issues are found in a release candidate. 
  Start a new VOTE thread with the revised proposal (in the case of the example, a new
  release candidate).
@@ -1705,8 +1705,8 @@
 </h3>
 <div class="section-content">
 <p>
-This section applies to any distribution that contains redistributable artifacts which contain version
-information but in particular binary distributions of Java contain jar files. A complient MANIFEST 
+This section applies to any distribution that contains re-distributable artifacts which contain version
+information but in particular binary distributions of Java contain jar files. A compliant MANIFEST 
 meta data file within each of these files should contain the implementation version.
 These are good reasons to use the release version number as the implementation version.
 This allows the exact version to be determined from just the jar.
@@ -1714,7 +1714,7 @@
 			</p>
 <p>
 This does mean that release candidates for binary distributions of this type must either
-be rerolled with the version number as the only change or accept that artifacts will not be 
+be rereleased with the version number as the only change or accept that artifacts will not be 
 uniquely named. Uncertainty about exact jar versions has caused nasty dependency
 issues in the past.
 			</p>
@@ -1725,8 +1725,8 @@
 <div class="section-content">
 <p>
 Typically, applications used to create <code>tar.gz</code> files are based on
-GNU tar. Unfortunately, the tar which ships with some versions of Solaris and some
-(older) versions of MacOSX is not always compatible with the output of GNU tar.
+GNU tar. Unfortunately, the tar which ships with some versions of Saris and some
+(der) versions of MacOSX is not always compatible with the output of GNU tar.
         	TODO: check information and expand
         	</p>
 </div>
@@ -1748,7 +1748,7 @@
 <div class="section-content">
 <p>
 Releases containing only binary distributions are strongly frowned upon. Open source 
-development is characterised by the accessibility of the source. Binary only distributions
+development is characterized by the accessibility of the source. Binary only distributions
 discourage developers from interacting with the source. Every successful Apache
 project needs to recruit new developers to carry the project forward.
         	</p>
@@ -1824,12 +1824,12 @@
 </h3>
 <div class="section-content">
 <p>
-Committer responsible for sheparding the release. 
+Committer responsible for shepherding the release. 
         	</p>
 <p>
             TODO (include link to infra documentation)
             TODO say something about the technical release manager (who
-            cuts the release) and the social one (who organises it).
+            cuts the release) and the social one (who organizes it).
             </p>
 </div>
 <h3>
@@ -1879,7 +1879,7 @@
 </h3>
 <div class="section-content">
 <p>
-The actual execution of the release. Typically consists of building the distribtions
+The actual execution of the release. Typically consists of building the distributions
 from the repository tag.
 TODO: link to infra
         	</p>

Modified: incubator/public/trunk/site-publish/projects/wicket.html
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-publish/projects/wicket.html?view=diff&rev=534131&r1=534130&r2=534131
==============================================================================
--- incubator/public/trunk/site-publish/projects/wicket.html (original)
+++ incubator/public/trunk/site-publish/projects/wicket.html Tue May  1 08:50:37 2007
@@ -296,16 +296,14 @@
 </th>
             </tr>
             <tr>
-              <td>....-..-..
-</td>
+              <td>2006-08-24</td>
               <td>Make sure that the requested project name does not already exist and
 check www.nameprotect.com to be sure that the name is not already
 trademarked for an existing software product.
 </td>
             </tr>
             <tr>
-              <td>....-..-..
-</td>
+              <td>....-..-..</td>
               <td>If request from an existing Apache project to adopt an external
 package, then ask the Apache project for the SVN module and mail
 address names.



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


Mime
View raw message