incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Incubator Wiki] Update of "DocumentationPlan" by RobertBurrellDonkin
Date Mon, 28 Aug 2006 15:27:18 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Incubator Wiki" for change notification.

The following page has been changed by RobertBurrellDonkin:
http://wiki.apache.org/incubator/DocumentationPlan

The comment on the change is:
Marked more content as added to document

------------------------------------------------------------------------------
  
   * [http://incubator.apache.org/guides/releasemanagement.html Release Management Guide]
is really just an outline. Shape is fine (including TODOs) but content required. Project templates
needed. Review http://wiki.apache.org/general/ReleaseGuides and add useful content. Review
release management content in policy: move any content which is not policy into guide (VOTE
required), link to policy from guide. Review http://jakarta.apache.org/commons/releases/ and
extract anything useful.
      * Best practices - source and binary distributions should unpack to directories with
different names. Use whatever-src for the source distribution (more convenient for those who
have the source checked out). (./)
-     * Add link from foundation release FAQ to best practices in incubator documentation
+     * Add link from foundation release FAQ to best practices in incubator documentation
(./)
      * Best practices - Build instructions should give supported version numbers for build
tools (for example, maven and ant)  (./)
      * Copyright - link to legal documentation: 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 and
documentation source. When in doubt, add a header. (./)
      * Best practices - LICENSE and NOTICE files in jars so that they can be distributed
by maven
-     * Add how to create a specification complient MANIFEST http://jakarta.apache.org/commons/releases/prepare.html#checkjarmanifest
+     * Add how to create a specification complient MANIFEST http://jakarta.apache.org/commons/releases/prepare.html#checkjarmanifest
(./)
      * Extract advice on release process from http://jakarta.apache.org/commons/releases/
      * Checks (source distribution):
         * Ensure that source distribution builds according to the instructions contained
(./)
@@ -33, +33 @@

           * ASF policy on dependencies (./)
           * Appropriate license and notice files (where applicable) (./)
      * License for javadocs. This is a little controversial. Adding LICENSE and copyright
information to javadocs is a little bit of a PITA. Some legal systems require explicit licenses
so it may be worth the effort. (./)
-     * [VOTE] and [RESULT][VOTE] convention for tally email. 
+     * [VOTE] and [RESULT][VOTE] convention for tally email. (./)
      * Voting on release candidates: pros and cons. Different processes: struts, tomcat,
httpd vote to bless the same artifact. This is high ceremony and slow but reliable. Problem
with voting on a release candidate is that it is not the artifact that will be shipped. Disadvantage
of this approach is that if the candidate is not acceptable then it means either increasing
the version number or risking the release into the wild (through repository) of a jar of unacceptable
quality with the same version number.
  
  

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


Mime
View raw message