You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@db.apache.org by jv...@apache.org on 2003/02/04 07:59:40 UTC
cvs commit: db-site/xdocs management.xml roles.xml source.xml
jvanzyl 2003/02/03 22:59:40
Modified: . maven.xml project.xml
templates mail.xml
xdocs management.xml roles.xml source.xml
Log:
o Tidying things up and trying to make things consistent across the site.
Revision Changes Path
1.3 +5 -3 db-site/maven.xml
Index: maven.xml
===================================================================
RCS file: /home/cvs/db-site/maven.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- maven.xml 4 Feb 2003 04:43:06 -0000 1.2
+++ maven.xml 4 Feb 2003 06:59:40 -0000 1.3
@@ -1,5 +1,5 @@
<project
- default="db-site"
+ default="site"
xmlns:maven="jelly:maven"
xmlns:velocity="jelly:org.apache.commons.jelly.tags.velocity.VelocityTagLibrary">
@@ -9,6 +9,10 @@
|
-->
+ <preGoal name="site">
+ <attainGoal name="db-site"/>
+ </preGoal>
+
<goal name="db-site">
<maven:reactor
@@ -44,8 +48,6 @@
basedir="${basedir}/templates"
template="whoweare.xml"/>
- <attainGoal name="xdoc"/>
-
</goal>
</project>
1.4 +2 -0 db-site/project.xml
Index: project.xml
===================================================================
RCS file: /home/cvs/db-site/project.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- project.xml 4 Feb 2003 06:32:07 -0000 1.3
+++ project.xml 4 Feb 2003 06:59:40 -0000 1.4
@@ -40,5 +40,7 @@
</dependency>
</dependencies>
+ <reports/>
+
</project>
1.3 +4 -6 db-site/templates/mail.xml
Index: mail.xml
===================================================================
RCS file: /home/cvs/db-site/templates/mail.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- mail.xml 4 Feb 2003 04:43:06 -0000 1.2
+++ mail.xml 4 Feb 2003 06:59:40 -0000 1.3
@@ -12,9 +12,8 @@
<p>
<b>The DB Announcement List</b>
<br/>
- <b>Low Traffic</b>
- <a href="mailto:announcements-subscribe@db.apache.org">Subscribe</a>
- <a href="mailto:announcements-unsubscribe@db.apache.org">Unsubscribe</a>
+ <a href="mailto:announcements-subscribe@db.apache.org">Subscribe</a> |
+ <a href="mailto:announcements-unsubscribe@db.apache.org">Unsubscribe</a> |
<a href="http://www.mail-archive.com/announcements@db.apache.org/">Archive</a>
</p>
<p>
@@ -26,9 +25,8 @@
<p>
<b>The DB General Project List</b>
<br/>
- <b>Medium Traffic</b>
- <a href="mailto:general-subscribe@db.apache.org">Subscribe</a>
- <a href="mailto:general-unsubscribe@db.apache.org">Unsubscribe</a>
+ <a href="mailto:general-subscribe@db.apache.org">Subscribe</a> |
+ <a href="mailto:general-unsubscribe@db.apache.org">Unsubscribe</a> |
<a href="http://www.mail-archive.com/general@db.apache.org/">Archive</a>
</p>
<p>
1.3 +51 -47 db-site/xdocs/management.xml
Index: management.xml
===================================================================
RCS file: /home/cvs/db-site/xdocs/management.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- management.xml 4 Feb 2003 02:38:47 -0000 1.2
+++ management.xml 4 Feb 2003 06:59:40 -0000 1.3
@@ -22,58 +22,62 @@
<a href="./whoweare.html"> Project Credits</a>.
</p>
- <p>
- <b>Roles</b>
- <br/> The PMC is responsible for the strategic direction
- and success of the DB Project. This governing body is expected to
- ensure the project's welfare and guide its overall direction. The PMC
- may not necessarily participate in the day-to-day coding but is
- involved in the overall development plans, the alleviation of any
- bottlenecks, the resolution of conflicts, and the overall technical
- success of the project.
- </p>
+ <subsection name="Roles">
+ <p>
+ The PMC is responsible for the strategic direction
+ and success of the DB Project. This governing body is expected to
+ ensure the project's welfare and guide its overall direction. The PMC
+ may not necessarily participate in the day-to-day coding but is
+ involved in the overall development plans, the alleviation of any
+ bottlenecks, the resolution of conflicts, and the overall technical
+ success of the project.
+ </p>
- <p>
- The PMC is answerable to the Apache Board with its Chairman serving as
- primary liaison.
- </p>
+ <p>
+ The PMC is answerable to the Apache Board with its Chairman serving as
+ primary liaison.
+ </p>
+ </subsection>
- <p>
- <b>Meetings</b>
- <br/> The PMC
- <a href="pmc/index.html">meets monthly</a>
- with a majority of its members to discuss issues, determine strategic
- direction, and forward progress. These meetings may take place online,
- via teleconference, or via other means deemed effective by the PMC.
- </p>
+ <subsection name="Meetings">
+ <p>
+ The PMC
+ <a href="pmc/index.html">meets monthly</a>
+ with a majority of its members to discuss issues, determine strategic
+ direction, and forward progress. These meetings may take place online,
+ via teleconference, or via other means deemed effective by the PMC.
+ </p>
+ </subsection>
- <p>
- <b>Membership</b>
- <br/> PMC members may resign at any time. The Chairman
- may resign as Chairman at any time without resigning membership to the
- PMC. The Chairman or any member may be removed from the PMC by a 3/4
- vote of the PMC.
- </p>
+ <subsection name="Membership">
+ <p>
+ PMC members may resign at any time. The Chairman
+ may resign as Chairman at any time without resigning membership to the
+ PMC. The Chairman or any member may be removed from the PMC by a 3/4
+ vote of the PMC.
+ </p>
- <p>
- In the event that the number of members drops below 7, the remaining PMC
- members may choose to elect a new member to serve out the remainder of
- the annual term. In order to be elected, a
- person must have served as a
- <a href="roles.html">Committer</a> and be
- nominated by a PMC Member. Once nominated, all of the PMC will vote
- and those receiving a 3/4 positive vote will become a member.
- </p>
+ <p>
+ In the event that the number of members drops below 7, the remaining PMC
+ members may choose to elect a new member to serve out the remainder of
+ the annual term. In order to be elected, a
+ person must have served as a
+ <a href="roles.html">Committer</a> and be
+ nominated by a PMC Member. Once nominated, all of the PMC will vote
+ and those receiving a 3/4 positive vote will become a member.
+ </p>
+ </subsection>
- <p>
- <b>Creation of subprojects</b>
- <br/> PMC members may propose the creation
- of new subprojects. Proposals are to contain the scope of the project,
- identify the initial source from which the project is to be populated,
- identify the mailing list(s) if any which are to be created, and
- identify the initial set of committers. Creation of a new subproject
- requires approval by 3/4 vote of the PMC.
- </p>
+ <subsection name="Creation of Subprojects">
+ <p>
+ PMC members may propose the creation
+ of new subprojects. Proposals are to contain the scope of the project,
+ identify the initial source from which the project is to be populated,
+ identify the mailing list(s) if any which are to be created, and
+ identify the initial set of committers. Creation of a new subproject
+ requires approval by 3/4 vote of the PMC.
+ </p>
+ </subsection>
</section>
</body>
1.2 +213 -209 db-site/xdocs/roles.xml
Index: roles.xml
===================================================================
RCS file: /home/cvs/db-site/xdocs/roles.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- roles.xml 4 Feb 2003 01:23:27 -0000 1.1
+++ roles.xml 4 Feb 2003 06:59:40 -0000 1.2
@@ -9,7 +9,7 @@
<body>
- <section name="Roles & Responsibilities">
+ <section name="Roles and Responsibilities">
<p>
The roles and responsibilities that people can assume in the project
are based on merit. Everybody can help no matter what their role.
@@ -17,215 +17,219 @@
obtain the right to vote and commit directly to the source repository.
</p>
- <h2>Users</h2>
+ <subsection name="Users">
- <p>
- Users are the people who use the products of the Project. People in
- this role aren't contributing code, but they are using the products,
- reporting bugs, making feature requests, and such. This is by far
- the most important category of people as, without users, there is no
- reason for the Project.
- </p>
-
- <p>
- When a user starts to contribute code or documentation patches, they
- become a Contributor.
- </p>
-
- <h2>Contributors</h2>
-
- <p>
- Contributors are the people who write code or documentation patches or
- contribute positively to the project in other ways. A volunteer's
- contribution is always recognized. In source code, all volunteers
- who contribute to a source file may add their name to the list of
- authors for that file.
- </p>
-
- <h2>Committers</h2>
-
- <p>
- Contributors who give frequent and valuable contributions to a
- subproject of the Project can have their status promoted to that of
- a "
- <em>Committer</em>" for that subproject. A Committer
- has write access to the source code repository and gains voting
- rights allowing them to affect the future of the subproject.
- </p>
-
- <p>
- In order for a Contributor to become a Committer, another Committer
- can nominate that Contributor or the Contributor can ask for it.
- </p>
-
- <p>
- Once a Contributor is nominated, all of the Committers for a subproject
- will vote. If there are at least 3 positive votes and no negative
- votes, the Contributor is converted into a Committer and given write
- access to the source code repository for that subproject. This is an
- example offer letter that should be sent to the volunteer after
- 3 positive votes have been received:
- </p>
-
- <source><![CDATA[
- Dear Contributor,
-
- The DB project would like to offer you commit privileges.
- We have been impressed with your contributions up till now, and
- believe that your involvement will improve the quality of the
- libraries we produce.
-
- It is important that you realize that these commit privileges give
- you access to the specific DB project repository for which you
- are involved with. They do not provide commit access to any other
- Apache based project. Those projects will have to grant you commit
- privileges themselves.
-
- If you are interested in having commit privileges, please just let us
- know, and we will setup an account on apache.org. It would expedite
- the process if you could provide your preferred account name and
- possibly a public SSH key. This process could take a few days once
- we get this information.
-
- We all hope that you accept this invitation.
-
- The DB Project Management Committee.
- ]]></source>
-
- <p>
- Once there are 3 positive votes and the response to the above letter
- has been received, someone from the project community who already has
- commit access should send email to:
- <strong>root at apache.org</strong>
- that the account should be created. The following information
- must be included in the email:
- </p>
-
- <ul>
- <li>
- The name and email address of the new user.
- (ie: John Smith <john.smith@foo.com>)
- </li>
- <li>
- Suggested account userid. This is optional.
- (ie: jmsith)
- </li>
- <li>
- The project that the user should be given access to.
- (ie: DB Foo)
- </li>
- <li>
- The results of the votes. In other words, the names and email
- addresses of the committers who approved the addition.
- </li>
- </ul>
-
- <p>
- The new committer should also send an email to
- <strong>asf at jaguNET.com</strong>
- with the following information (please cut and paste to return format):
- </p>
-
- <blockquote>
- Name: {your name}
- <br/>
- Email: {your email address on the ASF lists}
- <br/>
- Projects: {comma separated list of ASF projects to which you have commit access}
- <br/>
- Key: {a blank line followed by your key}
- </blockquote>
-
- <p>For example:</p>
-
- <blockquote>
- Name: Joe Foobar
- <br/>
- Email: joe@byteme.com
- <br/>
- Projects: Tomcat, httpd
- <br/>
- Key:
- <br/>
- adklajdAL()@ N*@U)U@()@@ @)U@
- </blockquote>
-
- <p>
- Finally, a new committer should also submit a signed copy of the Contributor
- License Agreement to the ASF. See the
- <a href="agreement.html">
- <strong>Contributor
- License Agreement page</strong>
- </a> for details.
- </p>
-
- <p>
- Note 0: If a committer already has an account on the apache.org server
- and the committer needs commit access to additional projects, then all
- that needs to be done is to have the user notify
- pmc@db.apache.org with the results of the voting (as documented
- above) and the user will be given access. In other words, the root
- email address should only be used on the basis of new account
- creation.
- </p>
-
- <p>
- Note 1: All committers will be given access to the db-site module
- on request. In other words, committers should be able to update the
- main DB website.
- </p>
-
- <!--
-
- This may be required shortly. But not currently. jvz.
-
- <p>
- Note 2: If the module that the committer needs access to is a sub
- module within a project (ie: jakarta-turbine-tdk or
- jakarta-avalon-logkit), it is up to the individual project to
- determine how to deal with giving out access. In other words, access
- may be granted by default to all sub modules or it can be granted by
- vote.
- </p>
-
- -->
-
- <p>
- At times, Committers may go inactive for a variety of reasons. A
- Committer that has been inactive for 6 months or more may lose their
- status as a Committer. Getting access back is as simple as
- re-requesting it on the project's Developer mailing list.
- </p>
-
- <p>
- A list of some of our current Committers can be found in our
- <a
- href="./whoweare.html">Project Credits</a>.
- </p>
-
- <p>
- <h2>Project Management Committee (PMC)</h2>
- Committers who frequently participate with valuable contributions may
- have their status promoted to that of a "
- <em>Project Management
- Committee Member</em>". This committee is the official managing
- body of the DB Project and is responsible for setting overall
- project direction. In order to become a Member, someone on
- the PMC must nominate the Committer. The individual may then be
- approved with a 3/4 majority of the PMC.
- </p>
-
- <p>
- To view the Project Management Committee bylaws,
- <a href="management.html">
- click here</a>.
- </p>
-
- <p>
- A list of our current PMC Members can be found in our
- <a
- href="./whoweare.html">Project Credits</a>.
- </p>
+ <p>
+ Users are the people who use the products of the Project. People in
+ this role aren't contributing code, but they are using the products,
+ reporting bugs, making feature requests, and such. This is by far
+ the most important category of people as, without users, there is no
+ reason for the Project.
+ </p>
+
+ <p>
+ When a user starts to contribute code or documentation patches, they
+ become a Contributor.
+ </p>
+ </subsection>
+
+ <subsection name="Contributors">
+
+ <p>
+ Contributors are the people who write code or documentation patches or
+ contribute positively to the project in other ways. A volunteer's
+ contribution is always recognized. In source code, all volunteers
+ who contribute to a source file may add their name to the list of
+ authors for that file.
+ </p>
+ </subsection>
+
+ <subsection name="Committers">
+
+ <p>
+ Contributors who give frequent and valuable contributions to a
+ subproject of the Project can have their status promoted to that of
+ a "
+ <em>Committer</em>" for that subproject. A Committer
+ has write access to the source code repository and gains voting
+ rights allowing them to affect the future of the subproject.
+ </p>
+
+ <p>
+ In order for a Contributor to become a Committer, another Committer
+ can nominate that Contributor or the Contributor can ask for it.
+ </p>
+
+ <p>
+ Once a Contributor is nominated, all of the Committers for a subproject
+ will vote. If there are at least 3 positive votes and no negative
+ votes, the Contributor is converted into a Committer and given write
+ access to the source code repository for that subproject. This is an
+ example offer letter that should be sent to the volunteer after
+ 3 positive votes have been received:
+ </p>
+
+ <source><![CDATA[
+ Dear Contributor,
+
+ The DB project would like to offer you commit privileges.
+ We have been impressed with your contributions up till now, and
+ believe that your involvement will improve the quality of the
+ libraries we produce.
+
+ It is important that you realize that these commit privileges give
+ you access to the specific DB project repository for which you
+ are involved with. They do not provide commit access to any other
+ Apache based project. Those projects will have to grant you commit
+ privileges themselves.
+
+ If you are interested in having commit privileges, please just let us
+ know, and we will setup an account on apache.org. It would expedite
+ the process if you could provide your preferred account name and
+ possibly a public SSH key. This process could take a few days once
+ we get this information.
+
+ We all hope that you accept this invitation.
+
+ The DB Project Management Committee.
+ ]]></source>
+
+ <p>
+ Once there are 3 positive votes and the response to the above letter
+ has been received, someone from the project community who already has
+ commit access should send email to:
+ <strong>root at apache.org</strong>
+ that the account should be created. The following information
+ must be included in the email:
+ </p>
+
+ <ul>
+ <li>
+ The name and email address of the new user.
+ (ie: John Smith <john.smith@foo.com>)
+ </li>
+ <li>
+ Suggested account userid. This is optional.
+ (ie: jmsith)
+ </li>
+ <li>
+ The project that the user should be given access to.
+ (ie: DB Foo)
+ </li>
+ <li>
+ The results of the votes. In other words, the names and email
+ addresses of the committers who approved the addition.
+ </li>
+ </ul>
+
+ <p>
+ The new committer should also send an email to
+ <strong>asf at jaguNET.com</strong>
+ with the following information (please cut and paste to return format):
+ </p>
+
+ <blockquote>
+ Name: {your name}
+ <br/>
+ Email: {your email address on the ASF lists}
+ <br/>
+ Projects: {comma separated list of ASF projects to which you have commit access}
+ <br/>
+ Key: {a blank line followed by your key}
+ </blockquote>
+
+ <p>For example:</p>
+
+ <blockquote>
+ Name: Joe Foobar
+ <br/>
+ Email: joe@byteme.com
+ <br/>
+ Projects: Tomcat, httpd
+ <br/>
+ Key:
+ <br/>
+ adklajdAL()@ N*@U)U@()@@ @)U@
+ </blockquote>
+
+ <p>
+ Finally, a new committer should also submit a signed copy of the Contributor
+ License Agreement to the ASF. See the
+ <a href="agreement.html">
+ <strong>Contributor
+ License Agreement page</strong>
+ </a> for details.
+ </p>
+
+ <p>
+ Note 0: If a committer already has an account on the apache.org server
+ and the committer needs commit access to additional projects, then all
+ that needs to be done is to have the user notify
+ pmc@db.apache.org with the results of the voting (as documented
+ above) and the user will be given access. In other words, the root
+ email address should only be used on the basis of new account
+ creation.
+ </p>
+
+ <p>
+ Note 1: All committers will be given access to the db-site module
+ on request. In other words, committers should be able to update the
+ main DB website.
+ </p>
+
+ <!--
+
+ This may be required shortly. But not currently. jvz.
+
+ <p>
+ Note 2: If the module that the committer needs access to is a sub
+ module within a project (ie: jakarta-turbine-tdk or
+ jakarta-avalon-logkit), it is up to the individual project to
+ determine how to deal with giving out access. In other words, access
+ may be granted by default to all sub modules or it can be granted by
+ vote.
+ </p>
+
+ -->
+
+ <p>
+ At times, Committers may go inactive for a variety of reasons. A
+ Committer that has been inactive for 6 months or more may lose their
+ status as a Committer. Getting access back is as simple as
+ re-requesting it on the project's Developer mailing list.
+ </p>
+
+ <p>
+ A list of some of our current Committers can be found in our
+ <a
+ href="./whoweare.html">Project Credits</a>.
+ </p>
+ </subsection>
+
+ <subsection name="Management Committee (PMC)">
+ <p>
+ Committers who frequently participate with valuable contributions may
+ have their status promoted to that of a "
+ <em>Project Management
+ Committee Member</em>". This committee is the official managing
+ body of the DB Project and is responsible for setting overall
+ project direction. In order to become a Member, someone on
+ the PMC must nominate the Committer. The individual may then be
+ approved with a 3/4 majority of the PMC.
+ </p>
+
+ <p>
+ To view the Project Management Committee bylaws,
+ <a href="management.html">
+ click here</a>.
+ </p>
+
+ <p>
+ A list of our current PMC Members can be found in our
+ <a
+ href="./whoweare.html">Project Credits</a>.
+ </p>
+ </subsection>
</section>
</body>
1.2 +182 -179 db-site/xdocs/source.xml
Index: source.xml
===================================================================
RCS file: /home/cvs/db-site/xdocs/source.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- source.xml 4 Feb 2003 01:23:27 -0000 1.1
+++ source.xml 4 Feb 2003 06:59:40 -0000 1.2
@@ -28,185 +28,188 @@
for links to subproject conventions.
</p>
- <h2>License</h2>
-
- <p>
- All source code committed to the Project's repositories must be
- covered by the
- <a href="http://www.apache.org/foundation/licence-FAQ.html">Apache License</a>
- or contain a copyright and license that allows redistribution under the same
- conditions as the Apache License.
- </p>
-
- <p>
- Committers should update the copyright notice on the Apache License to
- include the current year when they revise a source file. If it is 2002,
- and you revise a source file from 1999, change the copyright notice in
- the license to cite "1999, 2002". If the file was from 2001, we would
- change it to 2001-2002. And so forth. This will happen most often in the
- early part of a year, but maintenance of the copyright date should occur
- year-round, as needed.
- </p>
-
- <p>
- Any code, document, or binary that is committed to the Project's
- repositories, but not being donated to the ASF, must be clearly marked as
- such. All contributors should have a
- <a href="agreement.html">Contributor
- License Agreement</a> on file.
- </p>
-
- <p>
- Any
- <a href="jars.html">JAR</a> committed to the Project's repositories
- <strong>must</strong> be licensed for redistribution. BSD and MPL style
- licenses are generally fine, but many
- <a href="jars.html">Sun JARs</a>
- do not permit redistribution.
- </p>
-
- <h2>Status Files</h2>
-
- <p>
- Each of the Project's active source code repositories contain a file
- named
- <span class="code">STATUS</span> which is used to keep track
- of the agenda and plans for work within that repository. The status
- file includes information about release plans, a summary of code
- changes committed since the last release, a list of proposed changes
- that are under discussion, brief notes about items that individual
- developers are working on or want discussion about, and anything
- else that may be useful to help the group track progress.
- </p>
-
- <p>
- 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. 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>
- Simple patches to fix bugs can be committed then reviewed. With a
- commit-then-review process, the Committer is trusted to have a high
- degree of confidence in the change.
- </p>
-
- <p>
- Doubtful changes, new features, and large scale overhauls need to be
- discussed before committing them into the repository. Any change
- that affects the semantics of an existing API function, the size of
- the program, configuration data formats, or other major areas must
- receive consensus approval before being committed.
- </p>
-
- <p>
- Related changes should be committed as a group, or very closely
- 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. Also, any unit tests should also pass.
- </p>
-
- <p>
- The current source code tree for a subproject should be capable of
- complete compilation at all times. However, it is sometimes
- impossible for a developer on one platform to avoid breaking some
- other platform when a change is committed. If it is anticipated that
- a given change will break the build on some other platform, the
- committer must indicate that in the commit message.
- </p>
-
- <p>
- A committed change must be reversed if it is vetoed by one of the
- voting members and the veto conditions cannot be immediately
- satisfied by the equivalent of a "bug fix" commit. The
- veto must be rescinded before the change can be included in any
- public release.
- </p>
-
- <h2>Patches</h2>
-
- <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
- 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). 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 (preferred)</p>
-
- <source>
- cvs diff -u Main.java >> patchfile.txt
- </source>
-
- <p>or (Win32)</p>
-
- <p>
- You can use
- <a href="http://www.wincvs.org/">WinCVS</a> for a nice GUI or
- you can install
- <a href="http://sources.redhat.com/cygwin/">Cygwin</a> which
- will enable you to use the bash shell and also installs a lot of other
- utilities (such as diff and patch) that will turn your PC into a virtual
- Unix machine.
- </p>
-
- <p>
- All patches necessary to address an action item should be
- 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>
+ <subsection name="License">
+ <p>
+ All source code committed to the Project's repositories must be
+ covered by the
+ <a href="http://www.apache.org/foundation/licence-FAQ.html">Apache License</a>
+ or contain a copyright and license that allows redistribution under the same
+ conditions as the Apache License.
+ </p>
+
+ <p>
+ Committers should update the copyright notice on the Apache License to
+ include the current year when they revise a source file. If it is 2002,
+ and you revise a source file from 1999, change the copyright notice in
+ the license to cite "1999, 2002". If the file was from 2001, we would
+ change it to 2001-2002. And so forth. This will happen most often in the
+ early part of a year, but maintenance of the copyright date should occur
+ year-round, as needed.
+ </p>
+
+ <p>
+ Any code, document, or binary that is committed to the Project's
+ repositories, but not being donated to the ASF, must be clearly marked as
+ such. All contributors should have a
+ <a href="agreement.html">Contributor
+ License Agreement</a> on file.
+ </p>
+
+ <p>
+ Any
+ <a href="jars.html">JAR</a> committed to the Project's repositories
+ <strong>must</strong> be licensed for redistribution. BSD and MPL style
+ licenses are generally fine, but many
+ <a href="jars.html">Sun JARs</a>
+ do not permit redistribution.
+ </p>
+ </subsection>
+
+ <subsection name="Status Files">
+ <p>
+ Each of the Project's active source code repositories contain a file
+ named
+ <span class="code">STATUS</span> which is used to keep track
+ of the agenda and plans for work within that repository. The status
+ file includes information about release plans, a summary of code
+ changes committed since the last release, a list of proposed changes
+ that are under discussion, brief notes about items that individual
+ developers are working on or want discussion about, and anything
+ else that may be useful to help the group track progress.
+ </p>
+
+ <p>
+ It is recommended that the active status files are automatically
+ posted to the developer mailing lists three times per week.
+ </p>
+ </subsection>
+
+ <subsection name="Branches">
+
+ <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. 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>
+ </subsection>
+
+ <subsection name="Changes">
+
+ <p>
+ Simple patches to fix bugs can be committed then reviewed. With a
+ commit-then-review process, the Committer is trusted to have a high
+ degree of confidence in the change.
+ </p>
+
+ <p>
+ Doubtful changes, new features, and large scale overhauls need to be
+ discussed before committing them into the repository. Any change
+ that affects the semantics of an existing API function, the size of
+ the program, configuration data formats, or other major areas must
+ receive consensus approval before being committed.
+ </p>
+
+ <p>
+ Related changes should be committed as a group, or very closely
+ 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. Also, any unit tests should also pass.
+ </p>
+
+ <p>
+ The current source code tree for a subproject should be capable of
+ complete compilation at all times. However, it is sometimes
+ impossible for a developer on one platform to avoid breaking some
+ other platform when a change is committed. If it is anticipated that
+ a given change will break the build on some other platform, the
+ committer must indicate that in the commit message.
+ </p>
+
+ <p>
+ A committed change must be reversed if it is vetoed by one of the
+ voting members and the veto conditions cannot be immediately
+ satisfied by the equivalent of a "bug fix" commit. The
+ veto must be rescinded before the change can be included in any
+ public release.
+ </p>
+ </subsection>
+
+ <subsection name="Patches">
+
+ <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
+ 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). 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 (preferred)</p>
+
+ <source>
+ cvs diff -u Main.java >> patchfile.txt
+ </source>
+
+ <p>or (Win32)</p>
+
+ <p>
+ You can use
+ <a href="http://www.wincvs.org/">WinCVS</a> for a nice GUI or
+ you can install
+ <a href="http://sources.redhat.com/cygwin/">Cygwin</a> which
+ will enable you to use the bash shell and also installs a lot of other
+ utilities (such as diff and patch) that will turn your PC into a virtual
+ Unix machine.
+ </p>
+
+ <p>
+ All patches necessary to address an action item should be
+ 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>
+ </subsection>
</section>