You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@struts.apache.org by lu...@apache.org on 2014/01/22 10:37:26 UTC
svn commit: r1560296 - in /struts/site/trunk/content: markdown/builds.md
markdown/bylaws.md markdown/dev-mail.md markdown/dev/
markdown/git-for-struts.md markdown/releases.md markdown/volunteers.md
xdoc/dev/
Author: lukaszlenart
Date: Wed Jan 22 09:37:26 2014
New Revision: 1560296
URL: http://svn.apache.org/r1560296
Log:
Migrated dev/ to Markdown
Added:
struts/site/trunk/content/markdown/builds.md
struts/site/trunk/content/markdown/bylaws.md
struts/site/trunk/content/markdown/dev-mail.md
struts/site/trunk/content/markdown/git-for-struts.md
- copied unchanged from r1560259, struts/site/trunk/content/markdown/dev/git-for-struts.md
struts/site/trunk/content/markdown/releases.md
struts/site/trunk/content/markdown/volunteers.md
Removed:
struts/site/trunk/content/markdown/dev/
struts/site/trunk/content/xdoc/dev/
Added: struts/site/trunk/content/markdown/builds.md
URL: http://svn.apache.org/viewvc/struts/site/trunk/content/markdown/builds.md?rev=1560296&view=auto
==============================================================================
--- struts/site/trunk/content/markdown/builds.md (added)
+++ struts/site/trunk/content/markdown/builds.md Wed Jan 22 09:37:26 2014
@@ -0,0 +1,108 @@
+# Source Code
+
+## Source Code
+
+As a convenience to developers who are helping to create and maintain the Apache Struts framework,
+public access to the live source code repository is available. This is our one-and-only development repository.
+Accordingly, the source may not always compile or be in a release-ready state.
+
+*Access at your own risk!*
+
+NOTE: The full source code is provided with each [release.](downloads.html) If you simply want to build
+your own copy of the product, use the source code provided with an approved release, rather than the development head.
+
+Read-only access to the Apache Struts source repository is available through both
+[web browser](https://git-wip-us.apache.org/repos/asf/struts/repo?p=struts.git;a=summary) and
+[Git client](http://git-scm.com/) interfaces.
+
+With the [Git client](http://git-scm.com/) installed, obtaining a working copy of the Struts codebase is as simple as
+
+ > git clone http://git.apache.org/repos/asf/struts.git
+
+(Committers with write access should use the **https** protocol instead)
+
+ > git clone https://git-wip-us.apache.org/repos/asf/struts.git
+
+
+For more about using version control systems at Apache, see the ASF's
+[Source Code Repositories](http://www.apache.org/dev/#version-control) page.
+
+## Building Apache Struts
+
+If you are building Apache Struts from source, we recommend that you install and use
+[Apache Maven 3.](http://maven.apache.org) During the build process, Maven will automatically acquire
+whatever external JARs your system may need. (Of course, you can still use your build system of choice to build
+your own applications!)
+
+With Maven installed, building a Struts codebase is as simple as
+
+ > mvn install
+
+or
+
+ > mvn -DskipAssembly=true install
+
+Maven will automatically download any dependencies as needed.
+
+For more about using Maven to build Struts 2, see
+[Building the framework from source](/2.x/docs/building-the-framework-from-source.html) in the
+[Struts 2 Contributors Guide.](/2.x/docs/contributors-guide.html)
+
+For more about using Maven to build Struts 1, see our [Maven wiki page.](http://wiki.apache.org/struts/StrutsMaintenanceMaven)
+
+## NightlyBuilds
+
+As part of our continuous integration practice, we also make available each morning the
+[latest stable development build.](https://builds.apache.org/view/S-Z/view/Struts/job/Struts2-JDK6/lastStableBuild/org.apache.struts$struts2-assembly/)
+
+*Again: Use at your own risk!*
+
+If you do **not** plan to contribute to the development of the framework, then you probably want to download a
+[release](downloads.html)
+
+NOTE: The Struts 2 nightly build is not fully operational. We suggest that contributors checkout
+the [source code](#SourceCode) instead.
+
+## Test Builds
+
+As we prepare for a new release, the project group may create interim *test builds*. When test builds are available,
+we post them [here](http://people.apache.org/builds/struts/) in binary, source and library distributions.
+Library distributions include any external dependencies needed to use a product with your application.
+
+A test build is made available so that it can be reviewed for quality by the Apache Struts development group.
+When a build is judged "ready for prime time", it is promoted to "General Availability" status and may be
+made the "Best Available" release. If the group feels that a build requires more testing, then it may be marked
+as "Beta" release. When a test build is upgraded to "Beta" or "GA" by a vote of the project members,
+we make the distribution available as a formal [release.](downloads.html)
+
+## Maven Snapshots
+
+When a distribution is first made available, it is rated as a development build or "snapshot". Later, the quality
+of the distribution may be upgraded to "Beta" or "General Availability", based on feedback from the community,
+and then made available through ibiblio and other public Maven repositories. To obtain an early distribution via Maven,
+specify the ASF Snapshot repository in the project's POM.
+
+ <repositories>
+ <repository>
+ <id>apache.snapshots</id>
+ <name>ASF Maven 2 Snapshot</name>
+ <url>https://repository.apache.org/content/groups/snapshots/</url>
+ </repository>
+ </repositories>
+
+
+## Licensing of Apache Struts Builds
+
+Apache Struts 2 source code and documentation is licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file included in any distribution for additional information
+regarding copyright ownership. The ASF licenses the source code and documentation files in our Apache Struts distribution
+to you under the Apache License, Version 2.0 (the "License"); you may not use the Apache Struts product except in compliance
+with the License.
+
+You may obtain a copy of the License at [http://www.apache.org/licenses/LICENSE-2.0]
+
+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.
+
+Next: [Release Guidelines](releases.html)
Added: struts/site/trunk/content/markdown/bylaws.md
URL: http://svn.apache.org/viewvc/struts/site/trunk/content/markdown/bylaws.md?rev=1560296&view=auto
==============================================================================
--- struts/site/trunk/content/markdown/bylaws.md (added)
+++ struts/site/trunk/content/markdown/bylaws.md Wed Jan 22 09:37:26 2014
@@ -0,0 +1,199 @@
+# Project Management Committee Charter
+
+## Apache Struts PMC Charter
+
+Struts is a Project of the [Apache Software Foundation](http://apache.org/foundation) (ASF), formed by a resolution
+of the [ASF Board of Directors](http://apache.org/foundation/board/). As an ASF Project, Struts is subject to the
+[ASF Bylaws](http://apache.org/foundation/bylaws.html) and the direction of the ASF Board.
+
+The Project Charter incorporates by reference the current version
+of [How the ASF works](http://apache.org/foundation/how-it-works.html, with the additional guidelines
+and clarifications found herein.
+
+## Roles and Responsibilities
+
+The roles and responsibilities that people can assume in the project are based on merit.
+Everybody can help no matter what their role. Those who have been long term or valuable contributors to
+the project can earn the right to commit directly to the source repository and to cast binding votes during
+the decision-making process.
+
+### Users.
+
+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.
+When a user starts to contribute code or documentation patches, they become a Contributor.
+
+### Contributors.
+
+Contributors are the people who write code or documentation patches or contribute positively to the project
+in other ways. When a volunteer's patch is applied, the contribution is recognized in the version control log.
+
+
+### Committers.
+
+Contributors who give frequent and valuable contributions to a subproject of the Project can have their status
+promoted to that of a "*Committer*" for that subproject. A Committer has write access to the source code repository.
+Committer status is granted by the Project Management Committee by majority vote.
+
+
+### Project Management Committee (PMC).
+
+Committers and other volunteers who frequently participate with valuable contributions may have their status promoted
+to that of a "*Project Management Committee Member*". The PMC is responsible for the day-to-day management
+of the Project.
+
+## Management
+
+The Vice President is appointed by the ASF Board. The Vice President is assisted by the Project Management Committee
+(PMC) and also serves as the PMC chair. The PMC may nominate new members. Nominees may then be approved
+with a 3/4 majority vote of the PMC. Membership can be revoked by a unanimous vote of all the active PMC members
+other than the member in question. The list of active PMC members can be found on our [Volunteers page](volunteers.html).
+
+## PMC Duties
+
+The PMC is responsible for the day-to-day management of the Struts Project. The PMC oversees all changes
+made to the codebase. The PMC must ensure that all code under a Apache Struts repository is the lawful property
+of the Foundation and may be distributed under the [Apache Software License](http://apache.org/licenses/).
+All releases of a Struts subproject must be sanctioned by the Project Management Committee.
+
+## Subprojects
+
+Subprojects are the Project's unit of release. Each subproject should represent an implementation of a Struts framework
+or a related component. Each subproject should focus on creating, maintaining, and releasing a single software
+product or "deliverable".
+
+All PMC Members have voting rights in all subprojects. Members not familiar with a subproject codebase may abstain
+from any given vote. All Committers have write access to all subprojects. Subprojects are units of release, not
+units of work.
+
+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 any mailing lists or
+repositories, if any, which are to be created. Creation of a new subproject requires approval by a 3/4 majority
+vote of the PMC.
+
+## Decision Making
+
+All [Volunteers](http://apache.org/foundation/how-it-works.html#roles) (Users, Developers, Committers, PMC Members)
+are encouraged to participate in the decision-making process, but binding decisions are made only
+by the Project Management Committee.
+
+## Voting
+
+Any subscriber to the list may [vote](http://apache.org/foundation/voting.html) on any issue or action item.
+Votes from Developers and Committers are especially welcome. However, the only binding votes are those cast by a PMC
+Member.
+
+The act of voting carries certain obligations. Voters are not only stating their opinion, they are also agreeing
+to help do the work.
+
+Each vote can be made in one of three flavors:
+
+<table class="bodyTable">
+ <tr class="a">
+ <td>
+ <strong>+1</strong>
+ </td>
+ <td>
+ "Yes" "Agree," or "the action should be performed".
+ On some issues this is only binding if the voter has tested the action on their own system(s).
+ </td>
+ </tr>
+ <tr class="b">
+ <td>
+ <strong>+/-0</strong>
+ </td>
+ <td>
+ "Abstain", "no opinion".
+ An abstention may have detrimental effects if too many people abstain.
+ </td>
+ </tr>
+ <tr class="a">
+ <td>
+ <strong>-1</strong>
+ </td>
+ <td>
+ "No".
+
+ On issues where consensus is required, this vote counts as a **veto**.
+ All vetos must contain an explanation of why the veto is appropriate. Vetos with no explanation are void.
+ A veto cannot be overruled. If you disagree with the veto, you should lobby the person who
+ cast the veto. Voters intending to veto an action item should make their opinions known to the group
+ immediately so that the problem can be remedied as early as possible.
+
+ If a Committer tries to "override" a veto by restoring a vetoed change, the PMC may ask the infrastructure
+ group to revoke that Committer's write privileges.
+ </td>
+ </tr>
+</table>
+
+An action requiring consensus approval must receive at least **3 binding +1** votes and **no binding vetos**.
+An action requiring majority approval must receive at least **3 binding +1** votes and more **+1** votes than
+**-1** votes. All other action items are considered to have lazy approval until somebody votes**-1**, after which
+point they are decided by either consensus or majority vote, depending on the type of action item.
+
+Voting represent consensus and votes are never final. Circumstances change, and so may votes. A veto may be converted
+to a +1 after discussion, and likewise a +1 may be converted to a -1. By convention, Committers should allow a vote
+to circulate for 72 hours before taking action.
+
+## Action Items
+
+All decisions revolve around "*Action Items*". Action Items consist of the following:
+- Long Term Plans
+- Short Term Plans
+- Product Changes
+- Showstoppers (or "blockers")
+- Release Plan
+- Release Grade
+
+### Long Term Plans
+
+Long term plans are simply announcements that group members are working on particular issues related to the Project.
+These items are not voted on, but Committers and PMC Members who do not agree with a particular plan, or think that
+an alternative plan would be better, are obligated to inform the group of their feelings.
+
+### Short Term Plan
+
+Short term plans are announcements that a volunteer is working on a particular set of documentation or code files
+with the implication that other volunteers should avoid them or try to coordinate their changes.
+
+### Product Changes
+
+All product changes to the repository are subject to lazy consensus.
+
+### Showstoppers
+
+Showstoppers are issues that require a fix be in place before the next public release. They are designated as "blockers"
+in the issue tracker in order to focus special attention on these problems. An issue becomes a showstopper when it is
+designated as such in the issue tracker by a PMC member and remains so by lazy consensus.
+
+### Release Plan
+
+A release plan must be used to keep all volunteers aware of when a release is desired, whether it will be a major,
+minor, or milestone release, who will be the release manager, when the repository will be tagged to create
+the distribution, and other assorted information to keep volunteers from tripping over each other. A release
+plan must be incorporated into the product documentation, or otherwise announced to the DEV list.
+Lazy majority decides each issue in a release plan.
+
+
+### Release Grade
+
+After a proposed release is built, it must be tested and classified before being released to the general public.
+The proposed release may be assigned "Alpha", "Beta" or "General Availability" classifications by majority vote.
+Once a release is classified by the PMC Members, it may be distributed to the general public on behalf of the Foundation.
+Distributions may be reclassified or withdrawn by majority vote, but the release number may not be reused by another distribution.
+
+
+## Sandbox
+
+Pursuant to the ["Rules for Revolutionaries"](http://incubator.apache.org/learn/rules-for-revolutionaries.html),
+any committer may submit experimental material to the Sandbox area of the repository at his or her own discretion.
+
+Material must be moved from the sandbox to the main repository before it can be released.
+
+If a sandbox whiteboard becomes dormant for six or more months, it may be moved to the archive section of the repository.
+
+Experimental material that is outside the scope of the Struts project may also be submitted to the
+[Apache Labs](http://labs.apache.org/)
+
+Next: [Volunteers](volunteers.html)
Added: struts/site/trunk/content/markdown/dev-mail.md
URL: http://svn.apache.org/viewvc/struts/site/trunk/content/markdown/dev-mail.md?rev=1560296&view=auto
==============================================================================
--- struts/site/trunk/content/markdown/dev-mail.md (added)
+++ struts/site/trunk/content/markdown/dev-mail.md Wed Jan 22 09:37:26 2014
@@ -0,0 +1,43 @@
+# Dev Mailing List
+
+## Development Lists
+
+The following mailing lists are meant for people who want to contribute to Struts itself. Patches, Documentation
+improvements and discussion on future Struts are welcome. **For questions on using Struts, please subscribe to the
+[user list](mail.html)**.
+
+Please make sure you have read the guidelines on [this page](mail.html)
+
+<table>
+ <tr>
+ <th>Name</th>
+ <th>Subscribe</th>
+ <th>Unsubscribe</th>
+ <th>Description</th>
+ </tr>
+ <tr>
+ <td>Struts-Dev</td>
+ <td><a href="mailto:dev-subscribe@struts.apache.org?subject=subscribe&body=subscribe"></a></td>
+ <td><a href="mailto:dev-unsubscribe@struts.apache.org?subject=unsubscribe&body=unsubscribe">dev-unsubscribe@struts.apache.org</a></td>
+ <td>Contact other developers interested in expanding and improving Struts functionality.</td>
+ </tr>
+ <tr>
+ <td>Struts-Commits</td>
+ <td><a href="mailto:commits-subscribe@struts.apache.org?subject=subscribe&body=subscribe">commits-subscribe@struts.apache.org</a></td>
+ <td><a href="mailto:commits-unsubscribe@struts.apache.org?subject=unsubscribe&body=unsubscribe">commits-unsubscribe@struts.apache.org</a></td>
+ <td>Receive notifications of changes to the Struts source code repository.</td>
+ </tr>
+ <tr>
+ <td>Struts-Issues</td>
+ <td><a href="mailto:issues-subscribe@struts.apache.org?subject=subscribe&body=subscribe">issues-subscribe@struts.apache.org</a></td>
+ <td><a href="mailto:issues-unsubscribe@struts.apache.org?subject=unsubscribe&body=unsubscribe">issues-unsubscribe@struts.apache.org</a></td>
+ <td>Receive notifications from the Struts issue tracker.</td>
+ </tr>
+</table>
+
+
+## Archives
+
+You can read the [ASF Mail](http://mail-archives.apache.org/mod_mbox/struts-dev/) or the
+[Mark Mail](http://markmail.org/list/org.apache.struts.dev/) archives if you are looking for older discussions.
+There are many other archives out there as well.
Added: struts/site/trunk/content/markdown/releases.md
URL: http://svn.apache.org/viewvc/struts/site/trunk/content/markdown/releases.md?rev=1560296&view=auto
==============================================================================
--- struts/site/trunk/content/markdown/releases.md (added)
+++ struts/site/trunk/content/markdown/releases.md Wed Jan 22 09:37:26 2014
@@ -0,0 +1,105 @@
+# Release Guidelines
+
+## Release Guidelines
+
+This document describes the Apache Struts release process and our [coding conventions](#Coding),
+which are applicable to all subprojects. Both stable and development releases are
+[available for download.](downloads.html)
+
+## Release Process
+
+A [point release](http://commons.apache.org/releases/versioning.html) should be made before and after
+any product change that is not a "fully-compatible change" (see link). This includes moving a dependency from
+an internal package to an external product, including products distributed through the Apache Commons.
+We should place any fully-compatible changes in the hands of the community before starting on a change that
+is only "interface" or "external-interface" compatible.
+
+Additional remarks:
+
+- Every committer is encouraged to participate in the release process, either as the release manager or a
+ helper. Committers may also share the release manager role.
+- The release process can seem daunting when you review it for the first time. But, essentially, it breaks
+ down into four phases of just a few steps each:
+ - **Rolling** - Issues, dependencies, release notes, JAR manifest, licenses, copyrights,
+ and build (using the release target).
+ - **Testing** - JUnit, Cactus, web apps (for all "supported" containers).
+ - **Voting** - Upload test build to internal directory, post majority vote on DEV list as to release
+ grade: Alpha, Beta, General Availability.
+ - **Distributing** - Checksum, sign, mirror, update download page, announce.
+- Committers are **required** to post a release plan before tagging the repository and should wait
+ the traditional 72 hours before proceeding.
+- A checklist format can be used for the [release plan](http://wiki.apache.org/struts/StrutsReleasePlans),
+ to help step through the process. The plan may be maintained in the repository or on the
+ [Struts wiki](http://wiki.apache.org/struts/).
+- Our dependencies on external JARs (including Commons JARs) should be in line with our own release status.
+ Our nightly build can be dependant on another nightly build. Our beta can be dependant on another beta (or
+ "release candidate"), but should avoid a dependance on a nightly build. Our General Availability release
+ may only have dependencies on other GA, final, or stable releases.
+- Use your own discretion as to detail needed by the Release Notes. A high-level description of the changes
+ is more important than providing uninterpreted detail. At a minimum, new features and deprecations should be
+ summarized, since these are commonly asked questions. Ideally, the release notes should be maintained,
+ continuously for the nightly build so that we they do not need to be assembled at the last minute.
+- Try building the distribution under prior version of J2SE, if possible, to ensure that we are still
+ backwardly-compatible. But, our distributions should be built using the **latest production release of J2SE**,
+ to take advantage of all available compiler enhancements.
+- If you have multiple J2SE versions configured, run the JUnit and Cactus tests using the same configuration
+ that will be used to build the distribution.
+- There is a "release" target in the buildfile that will zip and tar the distribution. Before uploading the
+ distribution, extract the sample web applications and deploy the WARs under each of the "supported"
+ containers (if you can). Play test each application under each container to be sure they operate
+ nominally.
+- The test build can be posted to the internal distribution directory (svn.apache.org/struts/) and
+ announced to the Struts DEV and PMC lists (only!). Do not announce a test build on any other Apache lists or
+ link to it from an Apache website.
+- If the test build is voted to Alpha, Beta, or GA status, the release can announced to the User list and
+ linked from the website.
+- Any formal release may be submitted for mirroring. All GA releases **must** be mirrored.
+- After announcing a release, remember to update the Downloads and Announcements pages. If the release is
+ to be mirrored, wait at least 24 hours after submittal before making public announcements (as stated in the
+ [Apache Mirroring guidelines](http://apache.org/dev/mirrors.html).
+- If a serious flaw if found in a test build or release, it may be withdrawn by a majority vote of the PMC and
+ removed from ASF distribution channels.
+
+## Coding Conventions and Guidelines
+
+Source code and documentation contributed to the Struts repositories should observe the:
+- The ["Code Conventions for the Java Programming Language"](http://www.oracle.com/technetwork/java/codeconvtoc-136057.html),
+ as published by Oracle.
+
+### Clarifications
+- First, "Observe the style of the original". Resist the temptation to make stylistic changes for their own
+ sake. But, if you must reformat code, commit style changes separately from code changes. Either change
+ the style, commit, and then change the code, or vice-versa.
+- Set editors to replace tabs with spaces and do not trim trailing spaces. Tabs confound the version
+ control alerts. Trimming trailing spaces creates unnecessary changes.
+- Specify imported classes (do not use _.*_).
+- Write all if/else statements as full blocks with each clause within braces, unless the entire statement fits
+ on the same line.
+- Use `FIXME:` and `TODO:` tokens to mark follow up notes in code. You may also
+ include your Apache username and the date.
+- Omit `@author` tags.
+- `@since` to document changes between Struts versions, as in `@since Struts 2.1.`
+- Wrap lines of code and JavaDoc at column 78. You can include a "comment rule" in the source to help with
+ this.
+- Please do your best to provide high-quality Javadocs for all source code elements. Package overviews
+ (aka "Developer Guides") are also encouraged.
+- When working on a bugfix, please first write a test case that proves the bug exists, and then use the test
+ to prove the bug is fixed. =:0)
+- When working on an enhancement, please feel free to use test-driven design and write the test first `<head-slap/>`
+- As files are updated from year to year, the copyright on each file should be extended to include the current
+ year. *You do not need to change the copyright year unless you change the file.* Every source file should
+ include the ASF copyright notice and current Apache License and copyright.
+- Provide high-level API compatibility for any changes made within the same major release series (#.x.x).
+ Changes which adversely affect compatibility should be slotted for the next major release series (++#.x.x).
+- Our favorite books about programming are
+ [Design Patterns](http://www.amazon.com/exec/obidos/ISBN=0201633612/apachesoftwar-20/),
+ [Refactoring](http://www.amazon.com/exec/obidos/ISBN=0201485672/apachesoftwar-20/,
+ and [Code Complete](http://www.amazon.com/exec/obidos/ISBN=0735619670/apachesoftwar-20/)
+- Our favorite book about open source development is the
+ [The Cathedral and the Bazaar](http://www.amazon.com/exec/obidos/ISBN=1565927249/apachesoftwar-20/)
+- Our favorite science fiction author is
+ [Robert Heinlein](http://www.nitrosyncretic.com/rah/),
+ [TANSTAAFL](http://jargon.net/jargonfile/t/TANSTAAFL.html),
+ (Except on Friday, when we favor [Douglas Adams](http://news.bbc.co.uk/1/hi/uk/1326657.stm)).
+
+Next: [PMC Charter](bylaws.html)
\ No newline at end of file
Added: struts/site/trunk/content/markdown/volunteers.md
URL: http://svn.apache.org/viewvc/struts/site/trunk/content/markdown/volunteers.md?rev=1560296&view=auto
==============================================================================
--- struts/site/trunk/content/markdown/volunteers.md (added)
+++ struts/site/trunk/content/markdown/volunteers.md Wed Jan 22 09:37:26 2014
@@ -0,0 +1,84 @@
+# Volunteers
+
+## Volunteers
+
+The project consists of a diverse group of volunteers who share common values regarding collaborative,
+community-based open source development. If you are interested in some statistics, you can find
+some [here](http://www.apache.org/~vgritsenko/stats/projects/struts)
+
+### Project Management Committee Members
+
+Committee members are listed in the chronological order, according to the date each person become a committer
+or committee member.
+
+- James Holmes (jholmes at apache.org)
+- Don Brown (mrdon at apache.org)
+- Wendy Smoak (wsmoak at apache.org)
+- Laurie Harper (laurieh at apache.org)
+- Alexandru Popescu (apopescu at apache.org)
+- Rene Gielen, Vice President and Chair (rgielen at apache.org)
+- Rainer Hermanns (hermanns at apache.org)
+- Toby Jee (tmjee at apache.org)
+- Paul Benedict (pbenedict at apache.org)
+- Musachy Barroso (musachy at apache.org)
+- Dave Newton (davenewton at apache.org)
+- Wes Wannemacher (wesw at apache.org)
+- Lukasz Lenart (lukaszlenart at apache.org)
+- Philip Luppens (phil at apache.org)
+- Maurizio Cucchiara (mcucchiara at apache.org)
+- Johannes Geppert (jogep at apache.org)
+- Christian Grobmeier (grobmeier at apache.org)
+
+### Committers
+
+Other committers are listed in the chronological order, according to the date each person became a committer.
+
+- Michael Jouravlev (mikus at apache.org)
+- Bob Lee (crazybob at apache.org)
+- David H. DeWolf (ddewolf at apache.org)
+- Tom Schneider (tschneider at apache.org)
+- Matt Raible (mraible at apache.org)
+- Brian Pontarelli (bpontarelli at apache.org)
+- Jeromy Evans (jeromy at apache.org)
+- Mathias Bogaert (pathos at apache.org)
+- John Lindal (jafl at apache.org)
+- Bruce A. Phillips (bphillips at apache.org)
+- Greg Huber (ghuber at apache.org)
+
+### Emeritus Volunteers
+
+Emeritus volunteers are no longer active in the project. An emeritus volunteer can become active again upon request.
+("Merit never expires.")
+
+- Luis Arias
+- David Geary (dgeary at apache.org)
+- Pierre Delisle (pierred at apache.org)
+- Michael Schachter
+- Vincent Massol (vmassol at apache.org)
+- David Winterfeldt (dwinterfeldt at apache.org)
+- Oleg Alexeev (oalexeev at apache.org)
+- Rob Leland (rleland at apache.org)
+- Arron Bates (arron at apache.org)
+- Steve Raeburn (PMC) (sraeburn at apache.org)
+- James Turner (turner at apache.org)
+- Sean Schofield (PMC) (schof at apache.org)
+- Richard Feit (rich at apache.org)
+- David M. Karr (PMC) (dmkarr at apache.org)
+- David Graham (PMC) (dgraham at apache.org)
+- Eddie Bush (ekbush at apache.org)
+- Henri Yandell (PMC) (bayard at apache.org)
+- Patrick Lightbody (PMC) (plightbo at apache.org)
+- Greg Reddin (PMC) (greddin at apache.org)
+- Ian Roughley (PMC) (roughley at apache.org)
+- Craig R. McClanahan (PMC) (craigmcc at apache.org)
+- Joe Germuska (PMC) (germuska at apache.org)
+- Hubert Rabago (PMC) (hrabago at apache.org)
+- Gary VanMatre (PMC) (gvanmatre at apache.org)
+- Jason Carreira (PMC) (jcarreira at apache.org)
+- Cedric Dumoulin (PMC) (cedric at apache.org)
+- James Mitchell (PMC) (jmitchell at apache.org)
+- Antonio Petrelli (PMC) (apetrelli at apache.org)
+- Ted Husted (PMC) (husted at apache.org)
+- Nils-Helge Garli Hegvik (PMC) (nilsga at apache.org)
+- Martin Cooper (PMC) (martinc at apache.org)
+- Niall Pemberton (PMC) (niallp at apache.org)