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-subscr...@struts.apache.org?subject=subscribe&body=subscribe"></a></td> + <td><a href="mailto:dev-unsubscr...@struts.apache.org?subject=unsubscribe&body=unsubscribe">dev-unsubscr...@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-subscr...@struts.apache.org?subject=subscribe&body=subscribe">commits-subscr...@struts.apache.org</a></td> + <td><a href="mailto:commits-unsubscr...@struts.apache.org?subject=unsubscribe&body=unsubscribe">commits-unsubscr...@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-subscr...@struts.apache.org?subject=subscribe&body=subscribe">issues-subscr...@struts.apache.org</a></td> + <td><a href="mailto:issues-unsubscr...@struts.apache.org?subject=unsubscribe&body=unsubscribe">issues-unsubscr...@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)