avalon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From blorit...@apache.org
Subject cvs commit: jakarta-avalon/src/proposal CHARTER.txt
Date Wed, 04 Dec 2002 04:52:26 GMT
bloritsch    2002/12/03 20:52:26

  Added:       src/proposal CHARTER.txt
  add initial cut of Avalon charter that is in desparate need of community refinement
  Revision  Changes    Path
  1.1                  jakarta-avalon/src/proposal/CHARTER.txt
  Index: CHARTER.txt
  avalon.apache.org is a collaborative software development project
  dedicated to providing robust, full-featured, commercial-quality, and
  freely available component architecture.  This project is managed in
  cooperation with various individuals worldwide (both independent and
  company-affiliated experts), who use the Internet to communicate, plan,
  and develop Avalon component software and related documentation.
  This charter briefly describes the mission, history, organization, and
  processes of the project.
  avalon.apache.org exists to promote the use of Avalon components. 
  Component Based Design is a proven practice that helps create systems
  that are loosely coupled and easy to maintain.  Component Based
  Design requires a general framework, components, and containers to
  function properly.
  avalon.apache.org defines the framework, the reference implementation
  of the containers, the compliance testing suite, and a set of components
  that can be used in third party projects. These components plug into each
  other using standard APIs (formal, de facto, or proposed). The components
  must be high performance, reliable, secure, and easy to use.  The
  components must be part of an underlying architectural orchestration that
  will allow them to work together without major negotiations or breakage.
  We believe that the best way to define this Avalon architecture is by
  having both individuals and corporations collaborate on the best possible
  infrastructure, APIs, code, testing, and release cycles. Components must
  be vendor neutral and usable as core components for all.
  In order to achieve a coherent architecture between avalon.apache.org
  components and other components and applications, standards (formal or
  de facto) will be used as much as possible for both protocols and
  APIs. We will also allow the innovation of new protocols, APIs, and
  components in order to seed new concepts not yet defined by standards.
  This project was established under the direction of the
  Apache Software Foundation in November 2002 to facilitate joint
  open-source development.
  The avalon.apache.org project is managed by a small, core group of
  contributors known as the Project Management Committee [PMC].  The PMC
  must have at least one officer from the Apache Board, who will be the
  Chairperson and report to the Apache Board.  See
  http://www.apache.org/foundation/bylaws.html for reference.
  The PMC has the following responsibilities:
  1) Accepting new subproject proposals, formally submitting these
     proposals for committer vote, and creating the subproject (see
     SUBPROJECTS below).
  2) Facilitating code or other donations by individuals or companies.
  3) Resolving license issues and other legal issues.
  4) Approving new committers.
  5) Ensuring that administrative and infrastructure work is completed.
  6) Facilitating relationships among projects.
  7) Facilitating relationships between avalon.apache.org and the external
  8) Overseeing avalon.apache.org to ensure that the mission defined in
     this document is being fulfilled.
  9) Resolving conflicts within the project.
  To become a member of the PMC, an individual must be nominated by a
  contributor, unanimously approved by all PMC members, and approved by
  a two-thirds majority of committers. In most cases, developers will
  have actively contributed to development for at least six months
  before being considered for membership on the PMC.  It is also
  possible for a project depending on Avalon to nominate a representative.
  The client project's representative needs to be unanimously
  approved by all PMC members, and a two-thirds majority vote of
  In the unlikely event that a member of the PMC becomes disruptive to
  the process or ceases to contribute for an extended period, 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 unanimously approved by all members of the
  PMC. A contributor may challenge a change to the charter at any time
  and ask for a vote of all committers, in which case a two-thirds
  majority must approve the change.
  avalon.apache.org is comprised of subprojects; a subproject is a
  component whose scope is well defined.  Each subproject has its own
  set of developers.
  A new subproject proposal is submitted to the PMC, accepted by majority
  committer vote, and then subject to final approval by the PMC.
  Each subproject has a set of committers. Committers are developers who
  have read/write access to the source code repository. New committers
  are added when a developer is nominated by a committer and approved by
  at least 50 percent of the committers for that subproject with no
  opposing votes.  In most cases, new committers will already be
  participating in the development process by submitting suggestions
  and/or fixes via the bug report page or mailing lists.
  Like all Apache projects, the Avalon project is a meritocracy -- the more
  work you do, the more you are allowed to do. Occasional contributors
  will be able to report bugs and participate in the mailing lists.
  Specific changes to a product proposed for discussion or voting on the
  appropriate development mailing list 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 [PATCH] and including
  a distinctive one-line summary that corresponds to the action item for
  that patch.
  Use the diff -u command from the original software file(s) to the
  modified software file(s) to create the patch. Patches should be
  submitted against the latest CVS versions of the software to avoid
  conflicts and ensure that you are not submitting a patch for a problem
  that has already been resolved.
  Developers who make regular and substantial contributions may become
  committers as described above.
  The avalon.apache.org project site must provide the following:
  Bug Database -- This is a system for tracking bugs and feature
  Subproject Source Repositories -- These are several CVS repositories
  containing both the source code and documentation for the
  subprojects. Each subproject will have a set of committers to its
  Website -- An avalon.apache.org website will contain information about
  the avalon.apache.org 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 should have a devoted mailing
  list. Many subprojects may wish to have both user and development
  lists. The individual subprojects may decide on the exact structure of
  their mailing lists.
  All contributions to the avalon.apache.org project adhere to the "ASF
  Source Code License." All further contributions must be made under the
  same terms. All contributions must contain the following copyright
  notice: [This changes now that the license is available]
  Copyright (c) {date} {name of contributor} and others. All rights
  reserved. This program and the accompanying materials are made
  available under the terms of the ASF Source Code License, as found in
  the file ASF.code.license.html that is included in this distribution.
  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 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
  Each subproject must have a set of requirements as well as an
  up-to-date release plan and design document on its dedicated web page.
  It must be possible for each subproject to plug into the Gump nightly
  build system (see http://jakarta.apache.org/builds/gump). It is
  recommended that each subproject have a smoke-test system that works at
  least as a basic integration test.
  The avalon.apache.org project should work closely with other Apache
  projects, such as Jakarta and the Apache Server, to avoid redundancy
  and achieve a coherent architecture among avalon.apache.org and these

To unsubscribe, e-mail:   <mailto:avalon-cvs-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-cvs-help@jakarta.apache.org>

View raw message