leosimons 2002/12/06 07:06:13 Modified: src/proposal CHARTER.txt Log: Quite a few changes: - removed as many references to specific technology (like Gump or bugzilla) as possible - removed the "disfunctional PMC" clause. This is handled in the asf bylaws - formatting, spacing, etc - removed the bit on "infrastructure". Do not think we need this in the charter - change a lot of wording - give my view on the "mission". This is again merely intended as a discussion-starter; I do not have a strong opinion on it yet Revision Changes Path 1.3 +141 -171 jakarta-avalon/src/proposal/CHARTER.txt Index: CHARTER.txt =================================================================== RCS file: /home/cvs/jakarta-avalon/src/proposal/CHARTER.txt,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- CHARTER.txt 5 Dec 2002 19:42:36 -0000 1.2 +++ CHARTER.txt 6 Dec 2002 15:06:13 -0000 1.3 @@ -1,203 +1,173 @@ -Apache Avalon 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. +Apache Avalon is a collaborative software development project dedicated to +providing a high-quality freely available component architecture according to +the principles of the Apache Software Foundation [ASF]. -This charter briefly describes the mission, history, organization, and -processes of the project. +This charter briefly describes the mission, history, organization, and +processes of the Apache Avalon project. MISSION ======= -Apache Avalon 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. - -Apache Avalon 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 Apache Avalon -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. +Apache Avalon exists to promote and facilitate Component Based Design. +Component Based Design is a proven practice that helps create systems that are +loosely coupled and easy to maintain. Component Based Design requires a rigid +software framework to function properly. + +Apache Avalon provides a specification for such a framework, an implementation +of that specification and a compliance testing suite, and tools and components +to facilate development using that framework. + +The software developed by the Apache Avalon project must be high performance, +reliable, secure, and easy to use. The individual software components must be +part of an underlying architectural orchestration that will allow them to work +together without major negotiations or breakage. + +The process followed for the development of Apache Avalon software is the same +as the process followed by other ASF projects: individuals and corporations +collaborate on the best possible infrastructure, APIs, code, testing, and +release cycles. + +In order to achieve a coherent architecture between Apache Avalon 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. HISTORY ======= -This project was established under the direction of the -Apache Software Foundation in November 2002 to facilitate joint -open-source development. +This project was established under the direction of the Apache Software +Foundation in November 2002 to facilitate joint open-source development. THE PROJECT MANAGEMENT COMMITTEE ================================ -The Apache Avalon 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 Apache Avalon project is managed by a small, core group of contributors +known as the Project Management Committee [PMC]. The PMC must have at least +one ASF Officer, who will also be the PMC Chairperson and who will report to +the ASF 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 Apache Avalon and the external - world. -8) Overseeing Apache Avalon 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 -committers. - -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. - -SUBPROJECTS -=========== -Apache Avalon 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. +o Facilitating code or other donations by individuals or companies. +o Resolving license issues and other legal issues. +o Approving new committers. +o Ensuring that administrative and infrastructure work is completed. +o Overseeing Apache Avalon to ensure that the mission defined in + this document is being fulfilled. +o 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. + +The PMC is responsible for maintaining and updating this charter. Development +must follow the process outlined in this charter, 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. COMMITTERS ========== -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. +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 existing committers 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. CONTRIBUTORS ============ -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. - +Anyone is allowed and encouraged to participate in the development of the +Apache Avalon software products. Occasional contributors will be able to +report bugs, participate in the mailing lists, and submit patches. + 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. - -INFRASTRUCTURE -============== -The Apache Avalon project site must provide the following: - -Bug Database -- This is a system for tracking bugs and feature -requests. - -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 -repository. - -Website -- An Apache Avalon website will contain information about -the Apache Avalon 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. +appropriate development mailing list should be presented in the form of +patches. When sent to the mailing list, the message should contain a subject +beginning with [PATCH] and include a clear summary that describes the effect of +that patch. + +Like all Apache projects, the Avalon project is a meritocracy -- the more work +you do, the more you are allowed to do. Developers who make regular and +substantial contributions may become committers as described above. LICENSING ========= -All contributions to the Apache Avalon 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. - +All contributions to the Apache Avalon project adhere to the "ASF Source Code +License." All contributions must be made under those terms. All +contributions must contain the following copyright notice and license: + + ============================================================================ + The Apache Software License, Version 1.1 + ============================================================================ + + Copyright (C) 1999-2002 The Apache Software Foundation. All rights reserved. + + Redistribution and use in source and binary forms, with or without modifica- + tion, are permitted provided that the following conditions are met: + + 1. Redistributions of source code must retain the above copyright notice, + this list of conditions and the following disclaimer. + + 2. Redistributions in binary form must reproduce the above copyright notice, + this list of conditions and the following disclaimer in the documentation + and/or other materials provided with the distribution. + + 3. The end-user documentation included with the redistribution, if any, must + include the following acknowledgment: "This product includes software + developed by the Apache Software Foundation (http://www.apache.org/)." + Alternately, this acknowledgment may appear in the software itself, if + and wherever such third-party acknowledgments normally appear. + + 4. The names "Jakarta", "Apache Avalon", "Avalon Framework" and + "Apache Software Foundation" must not be used to endorse or promote + products derived from this software without prior written + permission. For written permission, please contact [EMAIL PROTECTED] + + 5. Products derived from this software may not be called "Apache", nor may + "Apache" appear in their name, without prior written permission of the + Apache Software Foundation. + + THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, + INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND + FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE + APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, + INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU- + DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS + OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + + This software consists of voluntary contributions made by many individuals + on behalf of the Apache Software Foundation. For more information on the + Apache Software Foundation, please see <http://www.apache.org/>. + 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 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 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 development process is intentionally lightweight and follows the same +guidelines as other ASF projects. The project 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 committers. + +PRODUCT REQUIREMENTS +==================== +All software products developed by Apache Avalon must have a set of requirments +as well as an up-to-date release plan and architecture design. All software +products developed by Apache Avalon must have a test system to verify their +correct functioning and are ideally subject to continous integration testing, +regression testing and unit testing. RELATIONSHIP TO OTHER APACHE PROJECTS ===================================== -The Apache Avalon project should work closely with other Apache -projects, such as Jakarta and the Apache Server, to avoid redundancy -and achieve a coherent architecture among Apache Avalon and these -projects. +The Apache Avalon project should work closely with other Apache projects, such +as Jakarta and Apache HTTP Server, to avoid redundancy and achieve a coherent +architecture among Apache Avalon and these projects.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
