[VOTE]: motion to transform Xerces into a top-level project as a member of the "federation" of XML projects
Neil Graham <[email protected]>
| Newsgroups | gmane.text.xml.general |
|---|---|
| Message-ID | <OF4646E993.D4A88CD7-ON85256E67.00822AFE__22426.7762773254$1080690329@ca.ibm.com> |
Hi all, Throughout January and February, the idea [1] of converting the XML project into a "Federation" of projects was discussed. The reason for doing this is that the by-laws of the Apache Software Foundation make certain assumptions about its structure, and the Board is concerned about how this relates to questions which might need to be defended legally--such as whether a given release of a product was sanctioned. Releases, for instance, are supposed to be voted on by the PMC responsible for a product, not merely by the committers for that product, since PMC's are creatures of the Board and their chairs are officers of the Corporation and so there is a verifiable link between the Board and the decision to make a release. That said, clearly there's lots of benefits inherent to the current situation--all the XML-related technologies are grouped together in a recognizable way, and share a common website and, at least in some sense, a sense of community. So the proposal is that various subprojects should become top-level projects, but continue to share common infrastructure and, hopefully, retain that sense of community. After some discussion, the proposal received consensus, and was discussed at the February Board meeting. The Board liked the direction, and is now expecting the subprojects identified in the proposal to vote on whether they would like to become top-level projects. In this note, I'm proposing that The Xerces-C, Xerces-J, and Xerces-P subprojects form an Apache Xerces project. We'llneed an initial charter, and I'm attaching a proposal to this message. This is based on the Apache XML project's charter [2], appropriately modified to meet our needs. Note that I've also deviated from the Apache XML charter in certain other respects: e.g., I've got rid of all references to unanimous PMC votes (except for removing subprojects) since these have been demonstrated to be unworkable in practice. To get things rolling, here's my +1. Cheers! Neil [1]: http://nagoya.apache.org/wiki/apachewiki.cgi?XMLProjectPages/FederationProposal [2]: http://xml.apache.org/mission.html (See attached file: charter.txt) Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
charter.txt
(application/octet-stream, 12 KB)
1 INTRODUCTION
==============
1.1 Apache Xerces is a collaborative software development project
dedicated to providing robust, full-featured, commercial-quality, and
freely available XML parsers on a wide variety of platforms supporting
several languages. 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 XML software and related
documentation.
1.2 This charter briefly describes the mission, history, organization, and
processes of the project.
2 MISSION
=========
2.1 Apache Xerces exists to promote the use of XML. We view XML as a
compelling paradigm that structures data as information, thereby
facilitating the exchange, transformation, and presentation of
knowledge. The ability to transform raw data into usable information
has great potential to improve the functionality and use of
information systems. We intend to build freely available XML
parsers in order to engender such improvements.
2.2 The Apache Xerces parsers support standard APIs (formal, de facto,
or proposed).
They are designed to be high performance, reliable, and easy to use.
To facilitate easy porting of ideas between languages, the API's supported
should be as similar as possible, given the constraints of the languages
and existing architectures. Apache Xerces parsers should also be designed
to work efficiently with other Apache projects that deal
with XML whenever possible.
2.3 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. Components must be vendor neutral and usable as
core components for all.
2.4 In order to achieve a coherent architecture between Apache Xerces parsers
and other components and applications, standards (formal or
de facto) will be used as much as possible for both protocols and
APIs. Where appropriate, experiences and lessons learned will be fed
back to standards bodies in an effort to assist in the development of
those standards. We will also encourage the innovation of new
protocols, APIs, and components in order to seed new concepts not
yet defined by standards.
3 HISTORY
=========
3.1 The Apache Xerces project was originally part of the Apache XML Project.
In early 2004, reflecting the growth both in the Apache
XML project and in Apache Xerces, Apache Xerces became a formal
project of the Apache Software Foundation. However, Apache Xerces still
shares much infrastructure with the Apache XML project and the
other subprojects of Apache XML that have become projects in their own right.
4 TERMS
=======
4.1 The ASF Board. The management board of the Apache Software
Foundation.
4.2 The Project. The Apache Xerces Project; intended
to refer to the source code, website and community that are Apache Xerces.
4.3 Subproject. Apache Xerces is comprised of a number of subprojects,
corresponding to each of the languages for which a parser has been
produced. Currently, there are parsers for Java, C/C++ and Perl.
4.4 Contributor. Anyone who makes a contribution to the development
of the Apache Xerces project or a subproject.
4.5 Committer. Apache Xerces has a set of committers. Committers
are contributors who have read/write access to the source code
repository.
5 THE PROJECT MANAGEMENT COMMITTEE
==================================
5.1 The Apache Xerces project is managed by a core group of
contributors known as the Project Management Committee [PMC],
which is composed of all active committers (see 8.3 below) from all subprojects.
5.2 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 Xerces project.
5.3 The PMC has the following responsibilities:
a) Accepting new subproject proposals, voting on these
proposals and creating the
subproject (see SUBPROJECTS below). This is done in collaboration
with the Incubator (see http://incubator.apache.org).
b) Facilitating code or other donations by individuals or companies,
in collaboration with the Incubator.
c) Resolving license issues and other legal issues in conjunction with
the ASF board.
d) Ensuring that administrative and infrastructure work is completed.
e) Facilitating relationships among subprojects and other Apache projects.
f) Facilitating relationships between Apache Xerces and the external
world.
g) Overseeing Apache Xerces to ensure that the mission defined in
this document is being fulfilled.
h) Resolving conflicts within the project.
i) Reporting to the ASF board (through the Chair) on the progress
of the project.
5.4 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.
5.5 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.
5.6 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.
5.7 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.
5.8 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.
5.9 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.
6 SUBPROJECTS
=============
6.1 Apache Xerces is composed of subprojects; a subproject is
responsible for an XML parser implementation in a particular language.
6.2 A new subproject proposal is submitted to the PMC, and then accepted
by a two-thirds vote.
6.3 A subproject may be removed by unanimous vote of the PMC, subject to the
approval of the ASF board.
7 CONTRIBUTORS
==============
7.1 Like all Apache projects, the Apache Xerces project is a meritocracy --
the more work you do, the more you are allowed to do. Contributions
will include participating in mailing lists, reporting bugs, providing
patches and proposing changes to a product.
7.2 Developers who make regular and substantial contributions may become
committers as described below.
8 COMMITTERS
============
8.1 Each subproject has a set of committers. Committers are contributors who
have read/write access to the source code repository. New committers
are added when a contributor is nominated by a committer, approved by
at least 50 percent of the active committers for that subproject with no
opposing votes, and files a signed Contributor License Agreement with the Secretary of the Corporation. 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.
8.2 Although committers have write access to all Apache Xerces subprojects,
they are only permitted to make changes to the subprojects to which they
have been elected committers. A committer may be elected to multiple
subprojects, but, except that no new access need be granted,
the process is the same as for any other contributor.
8.3 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 are part of the PMC.
8.4 Committers remain active as long as they are contributing code or
posting to the subproject mailing lists. If a committers 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.
8.5 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, and necessitate
their addition to the PMC mailing list.
9 INFRASTRUCTURE
================
9.1 The Apache Xerces project relies on the Apache XML project
and the Apache Infrastructure project for the following:
a) Bug Database -- This is a system for tracking bugs and feature
requests.
b) Subproject Source Repositories -- These are several repositories
containing both the source code and documentation for the
subprojects.
c) Website -- An xml.apache.org website will contain information about
the Apache Xerces project, including documentation, downloads of
releases, and this charter. Each subproject will have its own website
with subproject information.
d) 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.
e) General Mailing List -- This mailing list is open to the public. It is
intended for discussions that cross subprojects.
f) Subproject Mailing Lists -- Each subproject should have at least one 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.
10 LICENSING
===========
10.1 All contributions to the Apache Xerces project adhere to the "ASF
Source Code License." All further contributions must be made under the
same terms. All contributed files must contain the full text of the ASF
Source Code License.
10.2 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.
11 THE DEVELOPMENT PROCESS
==========================
11.1 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.
12 SUBPROJECT REQUIREMENTS
==========================
12.1 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.
12.2 It is recommended that each subproject have a smoke-test system
that works at least as a basic integration test.
13 RELATIONSHIP TO OTHER APACHE PROJECTS
========================================
13.1 The Apache Xerces project should work closely with other Apache
projects, such as XML, Jakarta and the Apache Server, to avoid redundancy
and achieve a coherent architecture among Apache Xerces and these
projects.