You are viewing a plain text version of this content. The canonical link for it is here.
Posted to site-cvs@jakarta.apache.org by jo...@apache.org on 2001/02/09 23:54:08 UTC
cvs commit: jakarta-site2/xdocs/site source.xml
jon 01/02/09 14:54:07
Modified: docs/site source.html
xdocs/site source.xml
Log:
add more helpful comments and insight.
-jon
Revision Changes Path
1.13 +41 -13 jakarta-site2/docs/site/source.html
Index: source.html
===================================================================
RCS file: /home/cvs/jakarta-site2/docs/site/source.html,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- source.html 2001/01/28 04:44:50 1.12
+++ source.html 2001/02/09 22:54:06 1.13
@@ -126,14 +126,19 @@
<p>
All Java Language source code in the repository must be written in
conformance to the "<a href="http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html">Code
-Conventions for the Java Programming Language</a> as published by Sun.
+ Conventions for the Java Programming Language</a> as published by Sun.
+ However, some projects may decide to override these defaults and use
+ their own defined conventions. For example, the <a href="/turbine/">Turbine</a>
+ project has its own <a href="/turbine/code-standards.html">defined conventions</a>
+ which are similar to the Sun standards but specifiy slightly different
+ conventions.
</p>
<h2>License</h2>
<p>
All source code committed to the Project's repositories must be
covered by the <a href="../LICENSE">Apache License</a> or contain a
copyright and license that allows redistribution under the same
- conditions as the Apache License.
+ conditions as the Apache License. All code must be copyright to the ASF.
</p>
<h2>Status Files</h2>
<p>
@@ -147,14 +152,16 @@
else that may be useful to help the group track progress.
</p>
<p>
- The active status files are automatically posted to the developer
- mailing lists three times per week.
+ It is recommended that the active status files are automatically
+ posted to the developer mailing lists three times per week.
</p>
<h2>Branches</h2>
<p>
Groups are allowed to create a branch for release cycles, etc. They
- are expected to merge completely back with the main branch as soon
- as their release cycle is complete.
+ are expected to merge completely back with the main branch as soon as
+ their release cycle is complete. All branches currently in use should
+ be documented by the respective projects. For example, <a href="/turbine/branches.html">Turbine</a> has page on the site that
+ details the branches currently in use.
</p>
<h2>Changes</h2>
<p>
@@ -174,7 +181,7 @@
together. Half complete projects should never be committed to the
main branch of a development repository. All code changes must be
successfully compiled on the developer's platform before being
- committed.
+ committed. Also, any unit tests should also pass.
</p>
<p>
The current source code tree for a subproject should be capable of
@@ -195,16 +202,22 @@
<p>
When a specific change to a product is proposed for discussion or
voting on the appropriate development mailing list, it should be
- presented in the form of input to the patch command. When sent to
- the mailing list, the message should contain a Subject beginning
- with <span class="code">[PATCH]</span> and a distinctive one-line
- summary corresponding to the action item for that patch.
+ presented in the form of input to the patch command. When sent to the
+ mailing list, the message should contain a Subject beginning with
+ <span class="code">[PATCH]</span> and a distinctive one-line summary
+ in the subject corresponding to the action item for that patch.
</p>
<p>
The patch should be created by using the <span class="code">diff
-u</span> command from the original software file(s) to the modified
- software file(s). For example:
+ software file(s). It is recommended that you submit patches against
+ the latest CVS versions of the software in order to avoid conflicts.
+ This will also ensure that you are not submitting a patch for a problem
+ that has already been resolved.
</p>
+ <p>
+ For example:
+ </p>
<div align="left">
<table cellspacing="4" cellpadding="0" border="0">
<tr>
@@ -226,7 +239,7 @@
</tr>
</table>
</div>
- <p>or</p>
+ <p>or (preferred)</p>
<div align="left">
<table cellspacing="4" cellpadding="0" border="0">
<tr>
@@ -261,6 +274,21 @@
concatencated within a single patch message. If later modification
to the patch proves necessary, the entire new patch should be posted
and not just the difference between the two patches.
+ </p>
+ <p>
+ If your email client line wraps the patch, consider placing the patch
+ file up on a website and sending a message to the development list
+ with the URL so that the developers with commit access can download
+ the commit the patch file more easily. You can also add the patch as
+ part of a bug report.
+ </p>
+ <p>
+ When a patch has been checked into CVS, the person who checked in the
+ patch should send a message to the person who sent the patch in as
+ well as the mailing list specifying that the patch has been checked
+ in. The reason is that not everyone watches commit messages and it is
+ helpful for others to know what has been checked in and when in order
+ to help prevent people from applying the patch at the same time.
</p>
</blockquote>
</td></tr>
1.2 +47 -14 jakarta-site2/xdocs/site/source.xml
Index: source.xml
===================================================================
RCS file: /home/cvs/jakarta-site2/xdocs/site/source.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- source.xml 2000/11/25 21:36:36 1.1
+++ source.xml 2001/02/09 22:54:07 1.2
@@ -1,5 +1,5 @@
<?xml version="1.0"?>
-<document prefix="../site/" url="./source.xml">
+<document>
<properties>
<author email="jon@latchkey.com">Jon S. Stevens</author>
@@ -20,7 +20,12 @@
All Java Language source code in the repository must be written in
conformance to the "<a
href="http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html">Code
-Conventions for the Java Programming Language</a> as published by Sun.
+ Conventions for the Java Programming Language</a> as published by Sun.
+ However, some projects may decide to override these defaults and use
+ their own defined conventions. For example, the <a href="/turbine/">Turbine</a>
+ project has its own <a href="/turbine/code-standards.html">defined conventions</a>
+ which are similar to the Sun standards but specifiy slightly different
+ conventions.
</p>
<h2>License</h2>
@@ -29,7 +34,7 @@
All source code committed to the Project's repositories must be
covered by the <a href="../LICENSE">Apache License</a> or contain a
copyright and license that allows redistribution under the same
- conditions as the Apache License.
+ conditions as the Apache License. All code must be copyright to the ASF.
</p>
<h2>Status Files</h2>
@@ -46,16 +51,19 @@
</p>
<p>
- The active status files are automatically posted to the developer
- mailing lists three times per week.
+ It is recommended that the active status files are automatically
+ posted to the developer mailing lists three times per week.
</p>
<h2>Branches</h2>
<p>
Groups are allowed to create a branch for release cycles, etc. They
- are expected to merge completely back with the main branch as soon
- as their release cycle is complete.
+ are expected to merge completely back with the main branch as soon as
+ their release cycle is complete. All branches currently in use should
+ be documented by the respective projects. For example, <a
+ href="/turbine/branches.html">Turbine</a> has page on the site that
+ details the branches currently in use.
</p>
<h2>Changes</h2>
@@ -79,7 +87,7 @@
together. Half complete projects should never be committed to the
main branch of a development repository. All code changes must be
successfully compiled on the developer's platform before being
- committed.
+ committed. Also, any unit tests should also pass.
</p>
<p>
@@ -104,23 +112,30 @@
<p>
When a specific change to a product is proposed for discussion or
voting on the appropriate development mailing list, it should be
- presented in the form of input to the patch command. When sent to
- the mailing list, the message should contain a Subject beginning
- with <span class="code">[PATCH]</span> and a distinctive one-line
- summary corresponding to the action item for that patch.
+ presented in the form of input to the patch command. When sent to the
+ mailing list, the message should contain a Subject beginning with
+ <span class="code">[PATCH]</span> and a distinctive one-line summary
+ in the subject corresponding to the action item for that patch.
</p>
<p>
The patch should be created by using the <span class="code">diff
-u</span> command from the original software file(s) to the modified
- software file(s). For example:
+ software file(s). It is recommended that you submit patches against
+ the latest CVS versions of the software in order to avoid conflicts.
+ This will also ensure that you are not submitting a patch for a problem
+ that has already been resolved.
</p>
+ <p>
+ For example:
+ </p>
+
<source>
diff -u Main.java.orig Main.java >> patchfile.txt
</source>
- <p>or</p>
+ <p>or (preferred)</p>
<source>
cvs diff -u Main.java >> patchfile.txt
@@ -142,6 +157,24 @@
to the patch proves necessary, the entire new patch should be posted
and not just the difference between the two patches.
</p>
+
+ <p>
+ If your email client line wraps the patch, consider placing the patch
+ file up on a website and sending a message to the development list
+ with the URL so that the developers with commit access can download
+ the commit the patch file more easily. You can also add the patch as
+ part of a bug report.
+ </p>
+
+ <p>
+ When a patch has been checked into CVS, the person who checked in the
+ patch should send a message to the person who sent the patch in as
+ well as the mailing list specifying that the patch has been checked
+ in. The reason is that not everyone watches commit messages and it is
+ helpful for others to know what has been checked in and when in order
+ to help prevent people from applying the patch at the same time.
+ </p>
+
</section>
</body>