incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rdon...@apache.org
Subject svn commit: r607462 - /incubator/public/trunk/site-author/guides/releasemanagement.xml
Date Sat, 29 Dec 2007 18:56:43 GMT
Author: rdonkin
Date: Sat Dec 29 10:56:43 2007
New Revision: 607462

URL: http://svn.apache.org/viewvc?rev=607462&view=rev
Log:
Initial notes on Incubator release distribution.

Modified:
    incubator/public/trunk/site-author/guides/releasemanagement.xml

Modified: incubator/public/trunk/site-author/guides/releasemanagement.xml
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-author/guides/releasemanagement.xml?rev=607462&r1=607461&r2=607462&view=diff
==============================================================================
--- incubator/public/trunk/site-author/guides/releasemanagement.xml (original)
+++ incubator/public/trunk/site-author/guides/releasemanagement.xml Sat Dec 29 10:56:43 2007
@@ -143,6 +143,88 @@
         </p>
        -->
     </section>
+    <!--
+    <section id='distribution'>
+        <p>
+        Incubator releases <a href='TODO'>should</a> be <a href='TODO'>distributed</a>
through 
+        <code>www.apache.org/dist/incubator</code>.
+        </p><p>
+        policy is really pretty simple. the incubator insists that artifacts
+go under w.a.o/dist/incubator/uima. infrastructure insists that
+releases are mirrored, permissions are correct and that
+signatures+sums are uploaded for every artifact. the rest is up to the
+community to decide.
+        </p><p>
+most projects have a lot more ceremony, rules and traditions. these
+often evolve over time and it is common for projects to release too
+late that they need to be documented. podlings should be able to short
+circuit this process by taking a look at the documented best practices
+and picking out the ones they like. these can form the basis of a
+release management document for the podling. it's easier to modify and
+add new practices than to start from nothing.
+        <p></p>
+        Documenting release management processes is important and often neglected. 
+        
+        </p><p>
+        A podling is free to choose a suitable layout. However, it is recommended that the
standard layouts
+        are studied. A podling should document it's layout (feel to start with the
+        prose in this document or from the Apache guides).
+        </p>   <p>
+        HTTPD tricks - HEADER.html FOOTER.html
+        </p><p>
+        Permissions: world read, group and owner read and write. EXAMPLE
+        One group is created by infrastructure for each top level project. All releases by
that project
+        should be owned by that group. That ensures that each project has the permissions
required
+        to manage it's own releases without active involvement by infrastructure.
+        </p><p>
+        All podling releases is an Incubator project release and so the artifacts need to
be owned by the
+        incubator group. TODO example.
+        If a podling graduates as a top level project then a new grop will be created. Then
new releases should
+        use that group (as well as being located in a top level subdirectory of dist rather
than dist/incubator).
+        If a podlng graduates as a subproject then the releases will be contained in a subdirectory
of that project's
+        top level dist directory and will use that project's group. TODO example.
+        </p><p>
+        Please check the permissions
+        TODO add to check list.
+        </p>
+        <p>
+        One a release artifact has been uploaded, it must never be modified. If a change
is required then
+        a new release should be created with a new release number. 
+        </p><p>
+        This applies only to release artifacts. It's usual that README's, NOTES and so on
are updated with 
+        each release.
+        </p>
+        <section id='archiving'>
+            <p>
+            Releases are autoarchived. When an artifact is uploaded, it will be sync'd to
the archives. 
+            When an artifact is deleted from live distribution, it will not be deleted from
the archives.
+            </p>
+        </section>
+        <section id='mirroring'>
+        Two choices for podlings. Either use the generic mirror script or create a custom
one. 
+        Pros and cons: generic unbranded, weaker links to keys etc; custom one requires effort
+        TODO: example
+        one consequence of using the mirroring system is that downloads cannot be 
+        monitored directly by using <a href='TODO: link'>stats</a> from Apache
download hits. 
+        It is possible to use google analytics to gain a reasonable estimate. TODO example.
+        </section>
+        <p>
+        KEYS TODO: 
+        signatures, checksums TODO:
+        scanner: upload these immediately
+        </p><p>
+        .htaccess fles are often used to redirect live urls for archived releases. For performance
reasons, 
+        top level .htaccess files are preferred. So edit the .htaccess in the root incubator
directory 
+        Redirect Permanent /src url
+        TODO: example
+        however, since people should not be using these URLs (they bypass the mirroring)
it is appropriate 
+        (and saves effort) not to offer redirects.
+        </p><p>
+        Eclipse: see http://mail-archives.apache.org/mod_mbox/incubator-general/200711.mbox/%3c474F3221.3040800@schor.com%3e
+        </p>
+       
+    </section> 
+     -->
     <section id='check-list'><title>Check List</title>
         <p>
 <strong>Note</strong> this is not intended to replace an understanding of the
release process.



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


Mime
View raw message