|
Project Guidelines
has been created by Hadrian Zbarcea
(Dec 03, 2008).
Content:
Apache Camel Bylaws
Project Charter
SCOPE
- Apache Camel is an integration framework based on known Enterprise Integration
Patterns used to implement routing and mediation rules.
- The Apache Camel team is dedicated to providing a robust, full-featured,
commercial-quality, and freely available project. The project is managed
in cooperation with various individuals worldwide (both independent and
company-affiliated experts), who use the Internet to communicate, plan, and
develop the code and the related documentation.
- This charter briefly describes the mission, history, organization, and
processes of the project.
MISSION
- Apache Camel is intended to simplify the integration effort. First and foremost
Camel aims to be an extensible, component based integration framework. Camel
supports out-of-the-box commonly used standards, protocols, data formats and
programming languages. We intend it to allow users to define routing and
mediation rules in a concise way. Users must also be able to easily implement
other ways of processing messages as needed.
- Apache Camel is designed to be high performance, reliable, lightweight,
embeddable and easy to use. Apache Camel is designed to be integrated and work
efficiently with other Apache projects that deal with messaging whenever possible.
- We believe that the best way to further these goals is by having both
individuals and corporations collaborate on the best possible infrastructure,
APIs, code, testing, and release cycles. Camel components must also be vendor
neutral.
HISTORY
- Apache Camel was a Apache ActiveMQ subproject started based on ideas
borrowed from Apache ServiceMix. Apache Camel quickly became mature, got
a larger and active community, grew to serve needs outside those of
Apache ActiveMQ and got adopted by other ASF and non-ASF projects.
TERMS
- The ASF Board. The management board of the Apache Software Foundation.
- The Project. The Apache Camel Project; intended to refer to the source code,
website and community that are Apache Camel.
- Subproject. The Apache Camel project may have subprojects; a
subproject is responsible for a component or application whose scope is
well defined.
- Product. Some deliverable (usually a binary or source
package) that a subproject releases to the public. Subprojects
may have multiple products.
- Release. A specific version of a product. Subprojects may have
multiple releases of a given product.
- Contributor. Anyone who makes a contribution to the development
of the Apache Camel project or a subproject.
- Committer. Each Apache Camel subproject has a set of committers.
Committers are contributors who have read/write access to the source code
repository.
- PMC. The PMC (Project Management Committee) is the group of people
that form the entity that makes decisions and controls the project. Individual
people or committers do not control the project.
THE PROJECT MANAGEMENT COMMITTEE
- The Apache Camel project is managed by a core group of committers
known as the Project Management Committee (PMC), which is composed of volunteers
from among the active committers (see 8.3 below) from all subprojects. Each
subproject must have at least one representative on the PMC, to ensure active
supervision of the subproject.
- The activities of the PMC are coordinated by the Chairperson, who is an
officer of the corporation and reports to the Apache Board. The Chairperson
will, on the request of the Apache Board, provide reports to the Board on issues
related to the running of the Apache Camel project.
- The PMC has the following responsibilities:
- Accepting new subproject proposals, voting on these proposals and creating
the subproject.
- Facilitating code or other donations by individuals or companies, in
collaboration with the Incubator.
- Resolving license issues and other legal issues in conjunction with
the ASF board.
- Ensuring that administrative and infrastructure work is completed.
- Facilitating relationships among subprojects and other Apache projects.
- Facilitating relationships between Apache Camel and the external world.
- Overseeing Apache Camel to ensure that the mission defined in this document
is being fulfilled.
- Resolving conflicts within the project.
- Reporting to the ASF board (through the Chair) on the progress of the project.
- In cases where the sub-project is unable to directly provide at least one
representative on the PMC--implying that there are no active committers on that
code base--then the subproject should be considered dormant, and any relevant
Apache policies for dormant projects should be implemented. At the least, the
subproject's status should be updated on its website.
- Every 12 months, or at the request of the Board, the PMC will provide a
recommendation to the Apache Board for the position of Chairperson of the PMC.
- This recommendation will be made on the basis of an election held within the
PMC. The election will be performed using a simple majority vote of PMC members.
- Upon agreement by the Apache Board, the recommended Chairperson will, if
they are not already, be appointed an officer of the corporation. See
http://www.apache.org/foundation/bylaws.html![]() for more information.
- In the unlikely event that a member of the PMC becomes disruptive to the
process, ceases to make codebase contributions for an extended period, or ceases
to take part in PMC votes for an extended period of time, said member may be
removed by unanimous vote of remaining PMC members.
- The PMC is responsible for maintaining and updating this charter.
Development must follow the process outlined below, so any change to the
development process necessitates a change to the charter. Changes must be
approved by a two-thirds majority of all members of the PMC.
SUBPROJECTS
- When a new subproject proposal is submitted to the PMC, it may be accepted
by unanimous vote of the PMC.
- A subproject may be removed by unanimous vote of the PMC, subject to the
approval of the ASF board.
CONTRIBUTORS
- Like all Apache projects, the Apache Camel project is a meritocracy – the
more work you do, the more you are allowed to do. Contributions willinclude
participating in mailing lists, reporting bugs, providing patches and proposing
changes to a product.
- Contributors who make regular and substantial contributions may become
committers as described below.
COMMITTERS
- Each subproject has a set of committers. Committers are contributors who
have read/write access to the source code repository.
- Normally, a new committer is added after a contributor has been nominated by
a committer and approved by at least 50 percent of the active committers for
that subproject with no opposing votes. In the case that a subproject has a very
small number of active committers, the PMC may choose to require a PMC
resolution to approve the nomination of a contributor by one of the active
committers in that subproject. All committers must have a signed Contributor
License Agreement on file with the Secretary of the Corporation. Since, in most
cases, contributors will already have contributed significant amounts of code,
this should usually have been done before nomination.
- Committers have write access to the primary subproject by which they have
been nominated as well as the area for common components, if any. A committer
may be elected to multiple subprojects.
- For the purposes of voting, committers will be classed as "active" or
"inactive". Only active committers will be included in the totals used to
determine the success or failure of a particular vote, and only active
committers can be members of the PMC.
- Committers remain active as long as they are contributing code or posting to
the subproject mailing lists. If a committer has neither contributed code nor
posted to the subproject mailing lists in 3 months, the PMC chair may e-mail the
committer, the subproject development list, and the PMC mailing list notifying
the committer that they are going to be moved to inactive status. If there is
no response in 72 hours, the committer will become inactive, and may be removed
from the PMC mailing list.
- An inactive status will not prevent a committer committing new code changes
or posting to the mailing lists. Either of these activities will automatically
re-activate the committer for the purposes of voting.
INFRASTRUCTURE
- The Apache Camel project relies on the Apache Infrastructure project
for the following:
- Bug Database – This is a system for tracking bugs and feature requests.
- Subproject Source Repositories – These are several repositories containing
both the source code and documentation for the subprojects.
- Website – The camel.apache.org website will contain information about
the Apache Camel project, including documentation, downloads of releases,
and this charter. Each subproject will have its own website with subproject
information.
- PMC Mailing List – This list is for PMC business requiring confidentiality,
particularly when an individual or company requests discretion. All other PMC
business should be done on the general mailing list.
- General Mailing List – This mailing list is open to the public. It is
intended for discussions that cross subprojects.
- Subproject Mailing Lists – Each subproject (except for common components)
should have at least one devoted mailing list. Many subprojects may wish to
have both user and dev (development) lists. The individual subprojects may
decide on the exact structure of their mailing lists.
LICENSING
- All contributions to the Apache Camel project adhere to the Apache
Software Foundation License, v.2.0 (http://www.apache.org/licenses/LICENSE-2.0![]() ).
All further contributions must be made under the same terms.
- When a committer is considering integrating a contribution from a
contributor who has no CLA on file with the Corporation, it is the
responsibility of the committer, in consultation with the PMC, to conduct due
diligence on the pedigree of the contribution under consideration.
THE DEVELOPMENT PROCESS
- The development process is intentionally lightweight; like other Apache
projects, the committers decide which changes may be committed to the
repository. Three +1 ('yes' votes) with no -1 ('no' votes or vetoes) are needed
to approve a significant code change. For efficiency, some code changes from
some contributors (e.g. feature additions, bug fixes) may be approved in
advance, in which case they may be committed first and changed as needed, with
conflicts resolved by majority vote of the committers.
SUBPROJECT REQUIREMENTS
- Each subproject should have a set of requirements as well as an up-to-date
release plan and design document on its dedicated web page.
- It is recommended that each subproject have a smoke-test system that works
at least as a basic integration test.
RELATIONSHIP TO OTHER APACHE PROJECTS
- The Apache Camel project should work closely with other Apache
projects, such as ActiveMQ, ServiceMix and CXF, to avoid redundancy and
achieve a coherent architecture among Apache Camel and these projects.
|
