commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r148840 - /jakarta/commons/current/LICENSE.txt /jakarta/commons/current/charter.html
Date Fri, 28 Jan 2005 02:31:31 GMT
Author: tobrien
Date: Thu Jan 27 18:31:29 2005
New Revision: 148840

Added charter and licenses from locked CVS

Added: jakarta/commons/current/LICENSE.txt
--- (empty file)
+++ jakarta/commons/current/LICENSE.txt	Thu Jan 27 18:31:29 2005
@@ -0,0 +1,202 @@
+                                 Apache License
+                           Version 2.0, January 2004
+   1. Definitions.
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          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
+          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
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      implied, including, without limitation, any warranties or conditions
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+   APPENDIX: How to apply the Apache License to your work.
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+   Copyright [yyyy] [name of copyright owner]
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

Added: jakarta/commons/current/charter.html
--- (empty file)
+++ jakarta/commons/current/charter.html	Thu Jan 27 18:31:29 2005
@@ -0,0 +1,221 @@
+<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
+<title>[PROPOSAL] The Commons</title>
+<h2><font face="Arial"> &quot;The Commons&quot;</font></h2>
+<h3><font face="Arial"><a name="charter">Charter</a></font></h3>
+<p>(0) rationale&nbsp;<br>
+Apache-Java and Jakarta originally hosted product-based subprojects, consisting of one major
deliverable. The Java language however is package-based, and most of these products have many
useful utilities. Some products are beginning to break these out so that they can be used
+independently. A Jakarta subproject to solely create and maintain independent packages is
proposed to accelerate and guide this process.<br>
+(1) scope of the subproject<br>
+The subproject shall create and maintain packages written in the Java language, intended
for use  in server-related development, and designed  to be used independently of any larger
product  or framework. Each package will be managed in the same manner
+as a larger Jakarta product.&nbsp;To further this goal, the subproject shall also host
a workplace for Jakarta committers and a master index of reusable packages related to Jakarta
+<p>(1.5) interaction with other subprojects</p>
+<p>(1.5.1) the sandbox</p>
+<p>The subproject will host a CVS repository available to all Jakarta committers as
a workplace for new packages or other projects. Before release&nbsp;to the public, code
or documentation developed here must be sponsored by a Jakarta&nbsp;subproject. The sponsoring
+subproject(s) will distribute the code or documentation along with the rest of their codebase.</p>
+<p>(1.5.2) the directory</p>
+<p>The subproject will also catalog packages and other resources available to the public
related to other Jakarta subprojects and ASF projects. This will be a
+dynamic catalog, like Bugzilla and Jyve, similar in functionality to <a href=""></a>,
<a href=""></a>, or&nbsp; <a href=""></a>.
New entries may be added by Jakarta committers, developers, and users. Entries by developers
and users will be approved
+by a committer before being made public.&nbsp;&nbsp;</p>
+(2) identify the initial source from which the subproject is to be populated<br>
+The initial packages would be based on existing ASF codebases, including those that provide
services for DataSource/Database Pools, XML Configuration, Message Resources and i18n, JNDI
and Naming, and Testing Suites. The initial committers have agreed to first create and maintain
+a Database Connection Pool package, along with related testing suites and subproject infrastructure.<br>
+(3) identify the initial Jakarta resources to be created&nbsp;
+<p>(3.1) mailing list(s)</p>
+<p>(3.2) CVS repositories</p>
+<p>(3.3) Bugzilla</p>
+<p>program - commons<br>
+components - Web site, Directory, dbcp</p>
+<p>(3.4) Jyve FAQ (when available)</p>
+(4) identify the initial set of committers<br>
+Morgan Delagrange<br>
+Ted Husted<br>
+Conor MacNeill<br>
+Geir Magnusson Jr.<br>
+Costin Manolache&nbsp;<br>
+Remy Maucherat<br>
+Craig R. McClanahan<br>
+Ignacio J. Ortega<br>
+Rodney Waldhoff<br>
+David Weinrich</p>
+<h3><font face="Arial"><a name="guidelines"> Guidelines</a></font></h3>
+  <li><i>is, has, will, shall, must</i> - required.</li>
+  <li><i>may, should, are encouraged </i>- optional but recommended.</li>
+  <li>The primary unit of reuse and release is the package.</li>
+  <li>The package library is not a framework but a collection of&nbsp; components
designed to be used independently.</li>
+  <li>Each package must have a clearly defined purpose, scope, and API -- Do one thing
well, and keep your contracts.</li>
+  <li>Each package is treated as a product in its own right.
+    <ol>
+      <li>Each package has its own status file, release schedule, version number, QA
tests, documentation,&nbsp; mailing list, bug category, and individual JAR.</li>
+      <li>Each package must clearly specify any external dependencies, including any
other Commons packages, and the earliest JDK version required.
+        <ol>
+          <li>External dependencies on optional and third-party codebases should be
+          <li>All necessary dependencies  must be recorded in the MANIFEST.MF file
of the package JAR, in the manner recommended in the JDK 1.3 documentation describing &quot;system
+        </ol>
+      </li>
+      <li>Each package must maintain a list of its active committers in its status
+    </ol>
+  </li>
+  <li>The packages should use a standard scheme for versioning, QA tests, and directory
layouts, and a common format for documentation and Ant build files.&nbsp;</li>
+  <li>The packages should fit within a unified package hierarchy.</li>
+  <li>In general, packages should provide an interface and one or more implementations
of that interface, or implement another interface already in use<i>.</i>
+    <ul>
+      <li>The packages should have boring functional names. Implementations may choose
more &quot;exciting&quot; designations.</li>
+    </ul>
+  </li>
+  <li>Packages are encouraged to either use JavaBeans as core objects, a JavaBean-style
API, or to provide an optional JavaBean wrapper.</li>
+  <li>External configuration files are discouraged, but if required, XML format files
are preferred for configuration options.</li>
+  <li>Each package will be hosted on its own page on the subproject Web site, and will
also be indexed in a master directory.</li>
+  <li>The subproject directory will also provide a distribution mechanism, or catalog
of packages and related resources.</li>
+  <li>The subproject will also host a top-level &quot;general&quot; mailing
list in addition to any lists for specific packages.</li>
+  <li>The subproject will also provide a single JAR of all stable package releases.
It may also provide a second JAR with a subset of only JDK 1.1 compatible releases. A gump
of nightly builds will also be provided.</li>
+  <li>Volunteers become committers to this subproject in the same way they are entered
to any Jakarta subproject. Being a committer in another Jakarta subproject is not a prerequisite.</li>
+  <li>Each committer has karma to all the packages, but committers are required to
add their name to a package's status file before their first commit to that package.</li>
+  <li>The committers shall elect a committee of three committers to provide general
oversight, in the style of the Jakarta PMC.</li>
+  <li>New packages may be proposed to the Jakarta Commons mailing list. To be accepted,
a package proposal must receive a positive super-majority vote of the subproject committers.&nbsp;Proposals
are to identify the
+    rationale for the package, its scope, its interaction with other packages and products,
the Commons resources, if any, to be created, the initial source from which the package is
to be created, and the initial set of committers.
+    <ol>
+      <li>The whole number of positive votes needed for a super majority is calculated
by dividing the total number of active subproject committers by four, multiplying by three,
and rounding to the nearest whole number (&gt;= .5 rounds up).</li>
+    </ol>
+  </li>
+  <li>It is expected that the scope of packages may sometimes overlap.</li>
+  <li>Anyone may propose a new package to the Commons, and list themselves as the initial
committers for the package. The vote on the proposal is then also a vote to enter new committers
to the subproject as needed.&nbsp;</li>
+  <li>A CVS repository will be available to all Jakarta committers as a  workplace
for new packages or other projects.. Before release&nbsp;to the public,
+ code or documentation developed here must be sponsored by Jakarta&nbsp;subproject. The
sponsoring subproject(s) will distribute the code or documentation along with the
+    rest of their codebase.</li>
+  <li>The subproject catalog will also list packages and resources available to the
public related to other Jakarta subprojects and ASF projects.</li>
+  <li>As a Jakarta subproject, the Commons adopts all other guidelines and procedures
of Jakarta and the Apache Software Foundation, as they may be amended from time to time.</li>
+<h4><a name="example">Example Package Proposal</a></h4>
+<h3><font face="Arial">Proposal for Database Connection Pool Package</font></h3>
+<p>(0) rationale<br>
+Many Jakarta products support interaction with a relational database. Creating a new connection
for each user  can be time consuming (often requiring multiple seconds of clock time), in
order to perform a database transaction that might take milliseconds. Opening a connection
per user can be unfeasible in a
+publicly-hosted Internet application where the number of simultaneous users can be be very
large. Accordingly, developers often wish to share a "pool" of open connections between all
of the application's current users. The number of users actually performing a request at any
given time is usually a very small percentage of the total number of active users, and during
request processing is the only time that a database connection is required. The application
itself logs into the DBMS, and a handles any user account issues internally.&nbsp;</p>
+<p>There are several Database Connection Pools already available, both within Jakarta
products and elsewhere. A Commons package would give committers an opportunity to coordinate
their efforts to create and maintain a efficient, feature-rich package
+under the ASF license.&nbsp;</p>
+<p>(1) scope of the package</p>
+<p>The package shall create and maintain a database connection pool package written
in the Java language to be distributed under the ASF license. The package shall be available
as a pseudo-JDBC driver and via a DataSource interface. The package shall
+also support multiple logins to multiple database systems, reclamation of stale or dead connections,
testing for valid connections, PreparedStatement pooling, and other features.</p>
+<p>(1.5) interaction with other packages</p>
+<p>Subclasses of the package should also be able to&nbsp;</p>
+  <ul>
+    <li>be configured via an external file (e.g. Turbine), and</li>
+    <li>expose its status, exceptions, or other events to an external logging system
(e.g. Log4)..</li>
+  </ul>
+<p>(2) identify the initial source for the package</p>
+<p>The initial codebase was contributed by Rodney Waldhorf from a working project and
can be distributed under the Apache license. The source is available as dbpool.jar from &lt;
<a href=""></a>
+<p>(2.1) identify the base name for the package</p>
+<p>(3) identify any Jakarta-Commons resources to be created&nbsp;</p>
+<p>(3.1) mailing list</p>
+<p>Until traffic justifies, the package will use the Jakarta-Commons list for communications.</p>
+<p>(3.2) CVS repositories</p>
+<p>For the time being, the package will use a root branch of the Jakarta-Commons CVS.</p>
+<p>(3.3) Bugzilla</p>
+<p>The package should be listed as a component of under the Jakarta-Commons Bugzilla
+<p>(3.4) Jyve FAQ (when available)</p>
+<p>(4) identify the initial set of committers to be listed in the Status File.&nbsp;</p>
+Morgan Delagrange<br>
+Geir Magnusson Jr.<br>
+Craig R. McClanahan<br>
+Rodney Waldhoff<br>
+David Weinrich</p>
+<h3><font face="Arial"><a name="faq">FAQ</a></font></h3>
+<p><b>What are the actual requirements for a Commons package?</b></p>
+<p>Most of the guidelines are advisory and meant to describe &quot;best practices&quot;.
The hard requirements boil down to &quot;clearly declare your API and dependencies&quot;.
Or, taken from the guidelines:</p>
+<p>&quot;3. Each package <b> must</b> have a clearly defined purpose,
scope, and API -- Do one thing well, and keep your contracts. &quot;</p>
+<p>&quot;4.1. Each package <b> must</b> clearly specify any external
dependencies, including any other Commons packages, and the earliest JDK version required.&quot;</p>
+<p>&quot;4.1.2. All necessary dependencies <b>  must</b> be recorded
in the MANIFEST.MF file of the package JAR, in the manner recommended in the JDK 1.3 documentation
describing 'system extensions'.&quot;</p>
+<p>Of course, the other requirement is that the authors submit a proposal to the Commons
committers for approval.</p>
+<p><b>Why not have a separate CVS tree for each package?</b></p>
+<p>It's possible that we may, but the decision should be deferred until we have more
packages to manage.</p>
+<p>For now, we just ask that a Commons committer enter their name in the Status File
of a package before making their first commit.&nbsp;</p>
+<p><b>Should other Jakarta subprojects move their utility packages to the Commons?</b></p>
+<p>They are welcome to do so. If they would like to experiment with refactoring a package
outside their own CVS tree, they can setup shop in the Commons sandbox. Any Jakarta committer
is entitled to write access to this CVS repository upon request. They
+could then decide to propose the package to the Commons, and thereby become committers to
the Commons, or to move it back to their own CVS, and just list it in the Commons directory
where other developers and users can find it.</p>
+<p><b>What will be listed in the Commons directory?</b></p>
+<p>Any package or other resource that is related to a Jakarta product may be entered
into the directory. This will be a dynamic application, like Bugzilla or Jyve. Users and developers
can complete an online form with their entry, which will be reviewed
+by a Commons committer before public release. Jakarta committers may have a higher level
of access so that their entry goes online without review.</p>
+<p><b>Why not just enroll all the Jakarta committers in the Commons?</b></p>
+<p>If Jakarta adopts an open-door policy for all its subprojects, then of course the
Commons will follow suit.&nbsp;</p>
+<p>We do have an open-door policy for the sandbox CVS (jakarta-commons-sandbox). Any
Jakarta committer is entitled to write access to the sandbox upon request, no vote required,
no questions asked. Just subscribe to jakarta-commons-sandbox, and request
+<h4>Why not just do this within Avalon, or another existing subproject?</h4>
+<p>Avalon is a large subproject that is being refactored. It's possible that the charter
of one of the ensuing pieces may overlap with the Commons.&nbsp;</p>
+<p>The focus of the Commons is squarely and solely on developing packages that can
be reused by multiple products, both within and without Jakarta. To garner the interest of
committers, it is important that the Commons and each of its packages be perceived as an
+independent entity. Since this is a volunteer meritocracy, the perception of committers is
vital. No subproject can succeed without the earnest support of individual committers.</p>
+<p>It is our firm position that the Commons will attract more committers on its own
than if it were aligned with any existing subproject. What "committers will commit to" has
to be the prime consideration. Darwin has been trying to tell us that; it's time we listened.</p>
+<h3><font face="Arial"><a name="resources">Resources</a></font></h3>
+  <li><b>Jakarta Guidelines</b></li>
+  <li>- <a href=""></a></li>
+  <li><b>Code Conventions for the Java Programming Language</b><br>
+    - <a href=""></a></li>
+  <li><b>Javadoc Tool Home Page&nbsp;</b><br>
+    - <a href=""></a>&nbsp;</li>
+  <li><b>Elements of Java Style - 6. Packaging Conventions</b><br>
+    - <a href=""></a></li>
+  <hr>
+  <p><b>From the Elements of Java Style - 6. Packaging Conventions</b></p>
+  <p><i>Rules and Principles only - commentary omitted (<a href="">buy
the book!</a>)</i></p>
+  <p>104. Place types that are commonly used, changed, and released together, or mutually
dependant on each other, into the same package.&nbsp;</p>
+  <ul>
+    <li><i>The Common Reuse Principle</i> - A package consists of classes
you reuse together. If you use one of the classes in the package, you use all of them.&nbsp;</li>
+    <li><i>The Common Closure Principle</i> - A package consists of classes,
all closed against the same kind of changes. A change that affects the package affects all
the classes in that package.&nbsp;</li>
+    <li><i>The Reuse/Release Equivalence Principle</i> - The unit of reuse
is the unit of release. Effective reuse requires tracking of releases from a change control
system. The package is the effective unit of reuse and release.&nbsp;</li>
+    <li><i>The Acyclic Dependencies Principle</i> - The dependency structure
between packages must be a direct acyclic graph; there must be no cycles in the dependency
+  </ul>
+  <p>105. Isolate volatile classes and interfaces in separate packages.</p>
+  <p>106. Avoid making packages that are difficult to change dependent on packages
that are easy to change.</p>
+  <ul>
+    <li><i>The Stable Dependencies Principle</i> - The dependencies between
packages should be orientated in the direction of increasing stability. A package should only
depend on packages more stable than it is.</li>
+  </ul>
+  <p>107. Maximize abstraction to maximize stability.&nbsp;</p>
+  <ul>
+    <li><i>The Stable Abstractions Principle </i>- The stability exhibited
by a package is directly proportional to its level of abstraction. The more abstract a package
is, the most stable it tends to be. The more concrete a package is, the more unstable
+      it tends to be.</li>
+  </ul>
+  <p>108. Capture high-level design and architecture as stable abstractions organized
into stable packages.</p>
+  <p><i>For more about these rules, and 103 others - <a href="">get
the book</a> - highly recommended.</i></p>

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message