You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Neil Graham <ne...@ca.ibm.com> on 2004/11/15 05:21:54 UTC
[VOTE]: motion to transform Xerces into a top-level project
Hello all Xerces developers and XML PMC'ers,
I think we're finally at the point where we can vote to transform Xerces
into a top-level project of the Apache Software Foundation. The text of
the motion, to which I give my +1, is as follows:
The Xerces community recommends to the Apache Software Foundation Board
that:
1. The top-level Xerces project contain the existing Xerces-J,
Xerces-C and Xerces-P subprojects of the Apache XML project
2. The initial committers for this project be the existing committers of
the Xerces-C, Xerces-J and Xerces-P subprojects
3. The initial PMC members for this project be:
Andy Clark
Michael Glavassevich
Neil Graham
Berin Lautenbach
Gareth Reakes
Jason Stewart
thus representing each of Xerces-J, Xerces-C and Xerces-P.
4. The initial PMC Chairperson be Gareth Reakes.
5. The mission statement and charter for the new project will be as
follows:
================================
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 and closely related technologies
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 and closely related technologies 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 code base which formed the foundations of both the
Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
was originally donated to Apache by IBM in 1999. Xerces-Perl
came into existence as a subproject of the Apache XML project
after the Xerces-C++ community had already matured to a
significant extent. All three were subprojects of the Apache XML
Project until late 2004. At this time, reflecting the growth in
the Apache XML project and these communities themselves, Apache
Xerces became a top-level Project of the Apache Software
Foundation. Apache Xerces still shares much infrastructure with
the Apache XML project and the other former 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 composed of a number of subprojects
which fit into one of two categories:
a) An XML parser implementation in some particular programming
language. There may be multiple parsers for a given
language, if the API's the parsers support are sufficiently
dissimilar. At the time of writing, there is one parser for
each of Java, C/C++ and Perl.
b) A set of components serving some purpose not directly
pertinent to XML parsing, but which are used in related
applications and are tightly bound, usually through internal
API's, to one (or more) of the parser subprojects.
4.4 Product. Some deliverable (usually a binary or source
package) that a subproject releases to the public. Subprojects
may have multiple products.
4.5 Contributor. Anyone who makes a contribution to the development
of the Apache Xerces project or a subproject.
4.6 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
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.
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 When a new subproject proposal is submitted to the PMC, it
may be accepted by a two-thirds vote of the PMC.
6.2 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 In order to ensure that all code contained in the Apache
Xerces project's code repository is free of licensing,
intellectual property and patent issues, any developer wishing
to contribute a new feature to Xerces must either sign:
a) If contributing as an individual, sign the "Individual
Contributor License Agreement (CLA)"
(http://www.apache.org/licenses/icla.txt) and file a copy with
the Secretary of the Corporation; or
b) If making the contribution as part of their employment
responsibilities, sign the "Corporate CLA (CCLA)",
(http://www.apache.org/licenses/cla-corporate.txt) and file a
copy with the Secretary of the Corporation.
7.3 If the contribution in question is a small bugfix, the
contributor need not sign a CLA, but need only provide the
following information, attaching it to the communication
containing the patch:
a) Name and employer
b) Are you the author of the code being conributed?
c) Do you have the right to grant the copyright and patent
licenses for the contribution that are set forth in the ASF v.2.0
license (http://www.apache.org/licenses/LICENSE-2.0)?
d) Does your employer have any rights to code that you have
written, for example, through your contract for employment? If
so, has your employer given you permission to contribute the code
on its behalf or waived its rights in the code?
e) Are you aware of any third-party licenses or other
restrictions (such as related patents or trademarks) that could
apply to your contribution? If so, what are they?
7.4 Contributors 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.
8.2 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.
8.3 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.4 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.5 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.
8.6 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 -- A xerces.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
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.
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; see sections 7.2 and 7.3.
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 should 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.
Neil Graham
Manager, XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: neilg@ca.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Andy Clark <an...@apache.org>.
+1
--
Andy Clark * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Gareth Reakes <ga...@parthenoncomputing.com>.
Hi all,
Thanks for the nomination for chair Neil.
+1
Gareth
On 15 Nov 2004, at 4:21, Neil Graham wrote:
> Hello all Xerces developers and XML PMC'ers,
>
> I think we're finally at the point where we can vote to transform
> Xerces
> into a top-level project of the Apache Software Foundation. The text
> of
> the motion, to which I give my +1, is as follows:
>
> The Xerces community recommends to the Apache Software Foundation Board
> that:
>
> 1. The top-level Xerces project contain the existing Xerces-J,
> Xerces-C and Xerces-P subprojects of the Apache XML project
>
> 2. The initial committers for this project be the existing committers
> of
> the Xerces-C, Xerces-J and Xerces-P subprojects
>
> 3. The initial PMC members for this project be:
>
> Andy Clark
> Michael Glavassevich
> Neil Graham
> Berin Lautenbach
> Gareth Reakes
> Jason Stewart
>
> thus representing each of Xerces-J, Xerces-C and Xerces-P.
>
> 4. The initial PMC Chairperson be Gareth Reakes.
>
> 5. The mission statement and charter for the new project will be as
> follows:
>
> ================================
> 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 and closely related technologies
> 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 and closely related technologies 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 code base which formed the foundations of both the
> Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
> was originally donated to Apache by IBM in 1999. Xerces-Perl
> came into existence as a subproject of the Apache XML project
> after the Xerces-C++ community had already matured to a
> significant extent. All three were subprojects of the Apache XML
> Project until late 2004. At this time, reflecting the growth in
> the Apache XML project and these communities themselves, Apache
> Xerces became a top-level Project of the Apache Software
> Foundation. Apache Xerces still shares much infrastructure with
> the Apache XML project and the other former 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 composed of a number of subprojects
> which fit into one of two categories:
>
> a) An XML parser implementation in some particular programming
> language. There may be multiple parsers for a given
> language, if the API's the parsers support are sufficiently
> dissimilar. At the time of writing, there is one parser for
> each of Java, C/C++ and Perl.
> b) A set of components serving some purpose not directly
> pertinent to XML parsing, but which are used in related
> applications and are tightly bound, usually through internal
> API's, to one (or more) of the parser subprojects.
>
> 4.4 Product. Some deliverable (usually a binary or source
> package) that a subproject releases to the public. Subprojects
> may have multiple products.
>
> 4.5 Contributor. Anyone who makes a contribution to the development
> of the Apache Xerces project or a subproject.
>
> 4.6 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
> 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.
>
> 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 When a new subproject proposal is submitted to the PMC, it
> may be accepted by a two-thirds vote of the PMC.
>
> 6.2 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 In order to ensure that all code contained in the Apache
> Xerces project's code repository is free of licensing,
> intellectual property and patent issues, any developer wishing
> to contribute a new feature to Xerces must either sign:
>
> a) If contributing as an individual, sign the "Individual
> Contributor License Agreement (CLA)"
> (http://www.apache.org/licenses/icla.txt) and file a copy with
> the Secretary of the Corporation; or
> b) If making the contribution as part of their employment
> responsibilities, sign the "Corporate CLA (CCLA)",
> (http://www.apache.org/licenses/cla-corporate.txt) and file a
> copy with the Secretary of the Corporation.
>
> 7.3 If the contribution in question is a small bugfix, the
> contributor need not sign a CLA, but need only provide the
> following information, attaching it to the communication
> containing the patch:
>
> a) Name and employer
> b) Are you the author of the code being conributed?
> c) Do you have the right to grant the copyright and patent
> licenses for the contribution that are set forth in the ASF v.2.0
> license (http://www.apache.org/licenses/LICENSE-2.0)?
> d) Does your employer have any rights to code that you have
> written, for example, through your contract for employment? If
> so, has your employer given you permission to contribute the code
> on its behalf or waived its rights in the code?
> e) Are you aware of any third-party licenses or other
> restrictions (such as related patents or trademarks) that could
> apply to your contribution? If so, what are they?
>
> 7.4 Contributors 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.
>
> 8.2 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.
>
> 8.3 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.4 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.5 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.
>
> 8.6 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 -- A xerces.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
> 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.
>
> 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; see sections 7.2 and 7.3.
>
> 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 should 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.
>
>
> Neil Graham
> Manager, XML Parser Development
> IBM Toronto Lab
> Phone: 905-413-3519, T/L 969-3519
> E-mail: neilg@ca.ibm.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: pmc-unsubscribe@xml.apache.org
> For additional commands, e-mail: pmc-help@xml.apache.org
>
>
>
--
Gareth Reakes, Managing Director Parthenon Computing
+44-1865-811184 http://www.parthcomp.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Neil Graham <ne...@ca.ibm.com>.
Hi all,
This vote has been open for a week now, and it looks to me like it's time
to call it. So far, I've counted 14 +1's from active Xerces committers, 5
+1's from XML PMC members, and a couple of +1's from users. No -1's or
0's that I'm aware of.
So IMO we're ready to present this to the Board. I'm not sure how to go
about doing this, but in any event that's probably a discussion best had
between Berin and Gareth. :)
Cheers!
Neil
Neil Graham
Manager, XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: neilg@ca.ibm.com
Neeraj Bajaj <Ne...@Sun.COM>
11/18/2004 06:53 AM
Please respond to
xerces-j-dev
To
xerces-j-dev@xml.apache.org
cc
Subject
Re: [VOTE]: motion to transform Xerces into a top-level project
+1 .
Neeraj
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Neeraj Bajaj <Ne...@Sun.COM>.
+1 .
Neeraj
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Gareth Reakes <ga...@parthenoncomputing.com>.
Hey,
Is it that you think this is to restrictive, or not restrictive
enough? I have been talking to a lot of people here at XML 2004 about
what they would like to see in Xerces in the future. People have been
suggesting different parser technologies and different validation
technologies. When Neil was creating the charter, I looked at the
section and felt that validation was covered within the parser part. Or
is it the free part you are referring to?
Cheers,
Gareth
On 18 Nov 2004, at 3:47, Simon Kitching wrote:
>>> ================================
>>> 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 and closely related technologies
>>> on a wide variety of platforms supporting several languages.
>
> Is the Xerces TLP project really about providing "freely available XML
> parsers"?
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: pmc-unsubscribe@xml.apache.org
> For additional commands, e-mail: pmc-help@xml.apache.org
>
>
>
--
Gareth Reakes, Managing Director Parthenon Computing
+44-1865-811184 http://www.parthcomp.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Gareth Reakes <ga...@parthenoncomputing.com>.
Hey,
Is it that you think this is to restrictive, or not restrictive
enough? I have been talking to a lot of people here at XML 2004 about
what they would like to see in Xerces in the future. People have been
suggesting different parser technologies and different validation
technologies. When Neil was creating the charter, I looked at the
section and felt that validation was covered within the parser part. Or
is it the free part you are referring to?
Cheers,
Gareth
On 18 Nov 2004, at 3:47, Simon Kitching wrote:
>>> ================================
>>> 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 and closely related technologies
>>> on a wide variety of platforms supporting several languages.
>
> Is the Xerces TLP project really about providing "freely available XML
> parsers"?
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: pmc-unsubscribe@xml.apache.org
> For additional commands, e-mail: pmc-help@xml.apache.org
>
>
>
--
Gareth Reakes, Managing Director Parthenon Computing
+44-1865-811184 http://www.parthcomp.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
> > ================================
> > 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 and closely related technologies
> > on a wide variety of platforms supporting several languages.
Is the Xerces TLP project really about providing "freely available XML
parsers"?
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Venu <K....@Sun.COM>.
+1
Neil Graham wrote:
> Hello all Xerces developers and XML PMC'ers,
>
> I think we're finally at the point where we can vote to transform Xerces
> into a top-level project of the Apache Software Foundation. The text of
> the motion, to which I give my +1, is as follows:
>
> The Xerces community recommends to the Apache Software Foundation Board
> that:
>
> 1. The top-level Xerces project contain the existing Xerces-J,
> Xerces-C and Xerces-P subprojects of the Apache XML project
>
> 2. The initial committers for this project be the existing committers of
> the Xerces-C, Xerces-J and Xerces-P subprojects
>
> 3. The initial PMC members for this project be:
>
> Andy Clark
> Michael Glavassevich
> Neil Graham
> Berin Lautenbach
> Gareth Reakes
> Jason Stewart
>
> thus representing each of Xerces-J, Xerces-C and Xerces-P.
>
> 4. The initial PMC Chairperson be Gareth Reakes.
>
> 5. The mission statement and charter for the new project will be as
> follows:
>
> ================================
> 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 and closely related technologies
> 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 and closely related technologies 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 code base which formed the foundations of both the
> Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
> was originally donated to Apache by IBM in 1999. Xerces-Perl
> came into existence as a subproject of the Apache XML project
> after the Xerces-C++ community had already matured to a
> significant extent. All three were subprojects of the Apache XML
> Project until late 2004. At this time, reflecting the growth in
> the Apache XML project and these communities themselves, Apache
> Xerces became a top-level Project of the Apache Software
> Foundation. Apache Xerces still shares much infrastructure with
> the Apache XML project and the other former 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 composed of a number of subprojects
> which fit into one of two categories:
>
> a) An XML parser implementation in some particular programming
> language. There may be multiple parsers for a given
> language, if the API's the parsers support are sufficiently
> dissimilar. At the time of writing, there is one parser for
> each of Java, C/C++ and Perl.
> b) A set of components serving some purpose not directly
> pertinent to XML parsing, but which are used in related
> applications and are tightly bound, usually through internal
> API's, to one (or more) of the parser subprojects.
>
> 4.4 Product. Some deliverable (usually a binary or source
> package) that a subproject releases to the public. Subprojects
> may have multiple products.
>
> 4.5 Contributor. Anyone who makes a contribution to the development
> of the Apache Xerces project or a subproject.
>
> 4.6 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
> 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.
>
> 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 When a new subproject proposal is submitted to the PMC, it
> may be accepted by a two-thirds vote of the PMC.
>
> 6.2 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
--
Regards,
Venu
---Quote for the week.-----
Vision is the art of seeing the invisible. --Jonathan Swift
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Berin Lautenbach <be...@wingsofhermes.org>.
+1 - And thanks Neil for all the hard work!
Cheers,
Berin
Neil Graham wrote:
> Hello all Xerces developers and XML PMC'ers,
>
> I think we're finally at the point where we can vote to transform Xerces
> into a top-level project of the Apache Software Foundation. The text of
> the motion, to which I give my +1, is as follows:
>
> The Xerces community recommends to the Apache Software Foundation Board
> that:
>
> 1. The top-level Xerces project contain the existing Xerces-J,
> Xerces-C and Xerces-P subprojects of the Apache XML project
>
> 2. The initial committers for this project be the existing committers of
> the Xerces-C, Xerces-J and Xerces-P subprojects
>
> 3. The initial PMC members for this project be:
>
> Andy Clark
> Michael Glavassevich
> Neil Graham
> Berin Lautenbach
> Gareth Reakes
> Jason Stewart
>
> thus representing each of Xerces-J, Xerces-C and Xerces-P.
>
> 4. The initial PMC Chairperson be Gareth Reakes.
>
> 5. The mission statement and charter for the new project will be as
> follows:
>
> ================================
> 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 and closely related technologies
> 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 and closely related technologies 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 code base which formed the foundations of both the
> Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
> was originally donated to Apache by IBM in 1999. Xerces-Perl
> came into existence as a subproject of the Apache XML project
> after the Xerces-C++ community had already matured to a
> significant extent. All three were subprojects of the Apache XML
> Project until late 2004. At this time, reflecting the growth in
> the Apache XML project and these communities themselves, Apache
> Xerces became a top-level Project of the Apache Software
> Foundation. Apache Xerces still shares much infrastructure with
> the Apache XML project and the other former 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 composed of a number of subprojects
> which fit into one of two categories:
>
> a) An XML parser implementation in some particular programming
> language. There may be multiple parsers for a given
> language, if the API's the parsers support are sufficiently
> dissimilar. At the time of writing, there is one parser for
> each of Java, C/C++ and Perl.
> b) A set of components serving some purpose not directly
> pertinent to XML parsing, but which are used in related
> applications and are tightly bound, usually through internal
> API's, to one (or more) of the parser subprojects.
>
> 4.4 Product. Some deliverable (usually a binary or source
> package) that a subproject releases to the public. Subprojects
> may have multiple products.
>
> 4.5 Contributor. Anyone who makes a contribution to the development
> of the Apache Xerces project or a subproject.
>
> 4.6 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
> 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.
>
> 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 When a new subproject proposal is submitted to the PMC, it
> may be accepted by a two-thirds vote of the PMC.
>
> 6.2 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
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Berin Lautenbach <be...@wingsofhermes.org>.
+1 - And thanks Neil for all the hard work!
Cheers,
Berin
Neil Graham wrote:
> Hello all Xerces developers and XML PMC'ers,
>
> I think we're finally at the point where we can vote to transform Xerces
> into a top-level project of the Apache Software Foundation. The text of
> the motion, to which I give my +1, is as follows:
>
> The Xerces community recommends to the Apache Software Foundation Board
> that:
>
> 1. The top-level Xerces project contain the existing Xerces-J,
> Xerces-C and Xerces-P subprojects of the Apache XML project
>
> 2. The initial committers for this project be the existing committers of
> the Xerces-C, Xerces-J and Xerces-P subprojects
>
> 3. The initial PMC members for this project be:
>
> Andy Clark
> Michael Glavassevich
> Neil Graham
> Berin Lautenbach
> Gareth Reakes
> Jason Stewart
>
> thus representing each of Xerces-J, Xerces-C and Xerces-P.
>
> 4. The initial PMC Chairperson be Gareth Reakes.
>
> 5. The mission statement and charter for the new project will be as
> follows:
>
> ================================
> 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 and closely related technologies
> 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 and closely related technologies 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 code base which formed the foundations of both the
> Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
> was originally donated to Apache by IBM in 1999. Xerces-Perl
> came into existence as a subproject of the Apache XML project
> after the Xerces-C++ community had already matured to a
> significant extent. All three were subprojects of the Apache XML
> Project until late 2004. At this time, reflecting the growth in
> the Apache XML project and these communities themselves, Apache
> Xerces became a top-level Project of the Apache Software
> Foundation. Apache Xerces still shares much infrastructure with
> the Apache XML project and the other former 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 composed of a number of subprojects
> which fit into one of two categories:
>
> a) An XML parser implementation in some particular programming
> language. There may be multiple parsers for a given
> language, if the API's the parsers support are sufficiently
> dissimilar. At the time of writing, there is one parser for
> each of Java, C/C++ and Perl.
> b) A set of components serving some purpose not directly
> pertinent to XML parsing, but which are used in related
> applications and are tightly bound, usually through internal
> API's, to one (or more) of the parser subprojects.
>
> 4.4 Product. Some deliverable (usually a binary or source
> package) that a subproject releases to the public. Subprojects
> may have multiple products.
>
> 4.5 Contributor. Anyone who makes a contribution to the development
> of the Apache Xerces project or a subproject.
>
> 4.6 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
> 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.
>
> 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 When a new subproject proposal is submitted to the PMC, it
> may be accepted by a two-thirds vote of the PMC.
>
> 6.2 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
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Venu <K....@Sun.COM>.
+1
Neil Graham wrote:
> Hello all Xerces developers and XML PMC'ers,
>
> I think we're finally at the point where we can vote to transform Xerces
> into a top-level project of the Apache Software Foundation. The text of
> the motion, to which I give my +1, is as follows:
>
> The Xerces community recommends to the Apache Software Foundation Board
> that:
>
> 1. The top-level Xerces project contain the existing Xerces-J,
> Xerces-C and Xerces-P subprojects of the Apache XML project
>
> 2. The initial committers for this project be the existing committers of
> the Xerces-C, Xerces-J and Xerces-P subprojects
>
> 3. The initial PMC members for this project be:
>
> Andy Clark
> Michael Glavassevich
> Neil Graham
> Berin Lautenbach
> Gareth Reakes
> Jason Stewart
>
> thus representing each of Xerces-J, Xerces-C and Xerces-P.
>
> 4. The initial PMC Chairperson be Gareth Reakes.
>
> 5. The mission statement and charter for the new project will be as
> follows:
>
> ================================
> 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 and closely related technologies
> 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 and closely related technologies 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 code base which formed the foundations of both the
> Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
> was originally donated to Apache by IBM in 1999. Xerces-Perl
> came into existence as a subproject of the Apache XML project
> after the Xerces-C++ community had already matured to a
> significant extent. All three were subprojects of the Apache XML
> Project until late 2004. At this time, reflecting the growth in
> the Apache XML project and these communities themselves, Apache
> Xerces became a top-level Project of the Apache Software
> Foundation. Apache Xerces still shares much infrastructure with
> the Apache XML project and the other former 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 composed of a number of subprojects
> which fit into one of two categories:
>
> a) An XML parser implementation in some particular programming
> language. There may be multiple parsers for a given
> language, if the API's the parsers support are sufficiently
> dissimilar. At the time of writing, there is one parser for
> each of Java, C/C++ and Perl.
> b) A set of components serving some purpose not directly
> pertinent to XML parsing, but which are used in related
> applications and are tightly bound, usually through internal
> API's, to one (or more) of the parser subprojects.
>
> 4.4 Product. Some deliverable (usually a binary or source
> package) that a subproject releases to the public. Subprojects
> may have multiple products.
>
> 4.5 Contributor. Anyone who makes a contribution to the development
> of the Apache Xerces project or a subproject.
>
> 4.6 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
> 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.
>
> 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 When a new subproject proposal is submitted to the PMC, it
> may be accepted by a two-thirds vote of the PMC.
>
> 6.2 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
--
Regards,
Venu
---Quote for the week.-----
Vision is the art of seeing the invisible. --Jonathan Swift
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level
project
Posted by Alberto Massari <am...@progress.com>.
Hi Neil,
here is my +1 vote.
Thanks,
Alberto
P.S. there is an extra '?' in the licensing part of the document
>10 LICENSING
>===========
>10.1 All contributions to the Apache Xerces project adhere to the
>Apache Software Foundation License, v.2.0
>(http://www.apache.org/licenses/LICENSE-2.0)?
-------------------------------------------
At 23.21 14/11/2004 -0500, Neil Graham wrote:
>Hello all Xerces developers and XML PMC'ers,
>
>I think we're finally at the point where we can vote to transform Xerces
>into a top-level project of the Apache Software Foundation. The text of
>the motion, to which I give my +1, is as follows:
>
>The Xerces community recommends to the Apache Software Foundation Board
>that:
>
>1. The top-level Xerces project contain the existing Xerces-J,
>Xerces-C and Xerces-P subprojects of the Apache XML project
>
>2. The initial committers for this project be the existing committers of
>the Xerces-C, Xerces-J and Xerces-P subprojects
>
>3. The initial PMC members for this project be:
>
>Andy Clark
>Michael Glavassevich
>Neil Graham
>Berin Lautenbach
>Gareth Reakes
>Jason Stewart
>
>thus representing each of Xerces-J, Xerces-C and Xerces-P.
>
>4. The initial PMC Chairperson be Gareth Reakes.
>
>5. The mission statement and charter for the new project will be as
>follows:
>
>================================
>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 and closely related technologies
>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 and closely related technologies 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 code base which formed the foundations of both the
>Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
>was originally donated to Apache by IBM in 1999. Xerces-Perl
>came into existence as a subproject of the Apache XML project
>after the Xerces-C++ community had already matured to a
>significant extent. All three were subprojects of the Apache XML
>Project until late 2004. At this time, reflecting the growth in
>the Apache XML project and these communities themselves, Apache
>Xerces became a top-level Project of the Apache Software
>Foundation. Apache Xerces still shares much infrastructure with
>the Apache XML project and the other former 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 composed of a number of subprojects
>which fit into one of two categories:
>
>a) An XML parser implementation in some particular programming
> language. There may be multiple parsers for a given
> language, if the API's the parsers support are sufficiently
> dissimilar. At the time of writing, there is one parser for
> each of Java, C/C++ and Perl.
>b) A set of components serving some purpose not directly
> pertinent to XML parsing, but which are used in related
> applications and are tightly bound, usually through internal
> API's, to one (or more) of the parser subprojects.
>
>4.4 Product. Some deliverable (usually a binary or source
>package) that a subproject releases to the public. Subprojects
>may have multiple products.
>
>4.5 Contributor. Anyone who makes a contribution to the development
>of the Apache Xerces project or a subproject.
>
>4.6 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
>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.
>
>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 When a new subproject proposal is submitted to the PMC, it
>may be accepted by a two-thirds vote of the PMC.
>
>6.2 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 In order to ensure that all code contained in the Apache
>Xerces project's code repository is free of licensing,
>intellectual property and patent issues, any developer wishing
>to contribute a new feature to Xerces must either sign:
>
>a) If contributing as an individual, sign the "Individual
> Contributor License Agreement (CLA)"
> (http://www.apache.org/licenses/icla.txt) and file a copy with
> the Secretary of the Corporation; or
>b) If making the contribution as part of their employment
> responsibilities, sign the "Corporate CLA (CCLA)",
> (http://www.apache.org/licenses/cla-corporate.txt) and file a
> copy with the Secretary of the Corporation.
>
>7.3 If the contribution in question is a small bugfix, the
>contributor need not sign a CLA, but need only provide the
>following information, attaching it to the communication
>containing the patch:
>
>a) Name and employer
>b) Are you the author of the code being conributed?
>c) Do you have the right to grant the copyright and patent
> licenses for the contribution that are set forth in the ASF v.2.0
> license (http://www.apache.org/licenses/LICENSE-2.0)?
>d) Does your employer have any rights to code that you have
> written, for example, through your contract for employment? If
> so, has your employer given you permission to contribute the code
> on its behalf or waived its rights in the code?
>e) Are you aware of any third-party licenses or other
> restrictions (such as related patents or trademarks) that could
> apply to your contribution? If so, what are they?
>
>7.4 Contributors 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.
>
>8.2 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.
>
>8.3 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.4 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.5 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.
>
>8.6 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 -- A xerces.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
>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.
>
>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; see sections 7.2 and 7.3.
>
>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 should 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.
>
>
>Neil Graham
>Manager, XML Parser Development
>IBM Toronto Lab
>Phone: 905-413-3519, T/L 969-3519
>E-mail: neilg@ca.ibm.com
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Venu <K....@Sun.COM>.
+1
Neil Graham wrote:
> Hello all Xerces developers and XML PMC'ers,
>
> I think we're finally at the point where we can vote to transform Xerces
> into a top-level project of the Apache Software Foundation. The text of
> the motion, to which I give my +1, is as follows:
>
> The Xerces community recommends to the Apache Software Foundation Board
> that:
>
> 1. The top-level Xerces project contain the existing Xerces-J,
> Xerces-C and Xerces-P subprojects of the Apache XML project
>
> 2. The initial committers for this project be the existing committers of
> the Xerces-C, Xerces-J and Xerces-P subprojects
>
> 3. The initial PMC members for this project be:
>
> Andy Clark
> Michael Glavassevich
> Neil Graham
> Berin Lautenbach
> Gareth Reakes
> Jason Stewart
>
> thus representing each of Xerces-J, Xerces-C and Xerces-P.
>
> 4. The initial PMC Chairperson be Gareth Reakes.
>
> 5. The mission statement and charter for the new project will be as
> follows:
>
> ================================
> 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 and closely related technologies
> 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 and closely related technologies 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 code base which formed the foundations of both the
> Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
> was originally donated to Apache by IBM in 1999. Xerces-Perl
> came into existence as a subproject of the Apache XML project
> after the Xerces-C++ community had already matured to a
> significant extent. All three were subprojects of the Apache XML
> Project until late 2004. At this time, reflecting the growth in
> the Apache XML project and these communities themselves, Apache
> Xerces became a top-level Project of the Apache Software
> Foundation. Apache Xerces still shares much infrastructure with
> the Apache XML project and the other former 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 composed of a number of subprojects
> which fit into one of two categories:
>
> a) An XML parser implementation in some particular programming
> language. There may be multiple parsers for a given
> language, if the API's the parsers support are sufficiently
> dissimilar. At the time of writing, there is one parser for
> each of Java, C/C++ and Perl.
> b) A set of components serving some purpose not directly
> pertinent to XML parsing, but which are used in related
> applications and are tightly bound, usually through internal
> API's, to one (or more) of the parser subprojects.
>
> 4.4 Product. Some deliverable (usually a binary or source
> package) that a subproject releases to the public. Subprojects
> may have multiple products.
>
> 4.5 Contributor. Anyone who makes a contribution to the development
> of the Apache Xerces project or a subproject.
>
> 4.6 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
> 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.
>
> 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 When a new subproject proposal is submitted to the PMC, it
> may be accepted by a two-thirds vote of the PMC.
>
> 6.2 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
--
Regards,
Venu
---Quote for the week.-----
Vision is the art of seeing the invisible. --Jonathan Swift
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Santiago Pericas-Geertsen <Sa...@Sun.COM>.
On Nov 14, 2004, at 11:21 PM, Neil Graham wrote:
> Hello all Xerces developers and XML PMC'ers,
>
> I think we're finally at the point where we can vote to transform
> Xerces
> into a top-level project of the Apache Software Foundation. The text
> of
> the motion, to which I give my +1, is as follows:
Looks good. +1!
-- Santiago
Re: [VOTE]: motion to transform Xerces into a top-level
project
Posted by Alberto Massari <am...@progress.com>.
Hi Neil,
here is my +1 vote.
Thanks,
Alberto
P.S. there is an extra '?' in the licensing part of the document
>10 LICENSING
>===========
>10.1 All contributions to the Apache Xerces project adhere to the
>Apache Software Foundation License, v.2.0
>(http://www.apache.org/licenses/LICENSE-2.0)?
-------------------------------------------
At 23.21 14/11/2004 -0500, Neil Graham wrote:
>Hello all Xerces developers and XML PMC'ers,
>
>I think we're finally at the point where we can vote to transform Xerces
>into a top-level project of the Apache Software Foundation. The text of
>the motion, to which I give my +1, is as follows:
>
>The Xerces community recommends to the Apache Software Foundation Board
>that:
>
>1. The top-level Xerces project contain the existing Xerces-J,
>Xerces-C and Xerces-P subprojects of the Apache XML project
>
>2. The initial committers for this project be the existing committers of
>the Xerces-C, Xerces-J and Xerces-P subprojects
>
>3. The initial PMC members for this project be:
>
>Andy Clark
>Michael Glavassevich
>Neil Graham
>Berin Lautenbach
>Gareth Reakes
>Jason Stewart
>
>thus representing each of Xerces-J, Xerces-C and Xerces-P.
>
>4. The initial PMC Chairperson be Gareth Reakes.
>
>5. The mission statement and charter for the new project will be as
>follows:
>
>================================
>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 and closely related technologies
>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 and closely related technologies 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 code base which formed the foundations of both the
>Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
>was originally donated to Apache by IBM in 1999. Xerces-Perl
>came into existence as a subproject of the Apache XML project
>after the Xerces-C++ community had already matured to a
>significant extent. All three were subprojects of the Apache XML
>Project until late 2004. At this time, reflecting the growth in
>the Apache XML project and these communities themselves, Apache
>Xerces became a top-level Project of the Apache Software
>Foundation. Apache Xerces still shares much infrastructure with
>the Apache XML project and the other former 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 composed of a number of subprojects
>which fit into one of two categories:
>
>a) An XML parser implementation in some particular programming
> language. There may be multiple parsers for a given
> language, if the API's the parsers support are sufficiently
> dissimilar. At the time of writing, there is one parser for
> each of Java, C/C++ and Perl.
>b) A set of components serving some purpose not directly
> pertinent to XML parsing, but which are used in related
> applications and are tightly bound, usually through internal
> API's, to one (or more) of the parser subprojects.
>
>4.4 Product. Some deliverable (usually a binary or source
>package) that a subproject releases to the public. Subprojects
>may have multiple products.
>
>4.5 Contributor. Anyone who makes a contribution to the development
>of the Apache Xerces project or a subproject.
>
>4.6 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
>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.
>
>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 When a new subproject proposal is submitted to the PMC, it
>may be accepted by a two-thirds vote of the PMC.
>
>6.2 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 In order to ensure that all code contained in the Apache
>Xerces project's code repository is free of licensing,
>intellectual property and patent issues, any developer wishing
>to contribute a new feature to Xerces must either sign:
>
>a) If contributing as an individual, sign the "Individual
> Contributor License Agreement (CLA)"
> (http://www.apache.org/licenses/icla.txt) and file a copy with
> the Secretary of the Corporation; or
>b) If making the contribution as part of their employment
> responsibilities, sign the "Corporate CLA (CCLA)",
> (http://www.apache.org/licenses/cla-corporate.txt) and file a
> copy with the Secretary of the Corporation.
>
>7.3 If the contribution in question is a small bugfix, the
>contributor need not sign a CLA, but need only provide the
>following information, attaching it to the communication
>containing the patch:
>
>a) Name and employer
>b) Are you the author of the code being conributed?
>c) Do you have the right to grant the copyright and patent
> licenses for the contribution that are set forth in the ASF v.2.0
> license (http://www.apache.org/licenses/LICENSE-2.0)?
>d) Does your employer have any rights to code that you have
> written, for example, through your contract for employment? If
> so, has your employer given you permission to contribute the code
> on its behalf or waived its rights in the code?
>e) Are you aware of any third-party licenses or other
> restrictions (such as related patents or trademarks) that could
> apply to your contribution? If so, what are they?
>
>7.4 Contributors 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.
>
>8.2 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.
>
>8.3 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.4 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.5 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.
>
>8.6 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 -- A xerces.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
>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.
>
>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; see sections 7.2 and 7.3.
>
>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 should 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.
>
>
>Neil Graham
>Manager, XML Parser Development
>IBM Toronto Lab
>Phone: 905-413-3519, T/L 969-3519
>E-mail: neilg@ca.ibm.com
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by James Berry <ja...@jberry.us>.
+1.
Thanks for getting all this together, Neil.
James.
On Nov 14, 2004, at 8:21 PM, Neil Graham wrote:
> Hello all Xerces developers and XML PMC'ers,
>
> I think we're finally at the point where we can vote to transform
> Xerces
> into a top-level project of the Apache Software Foundation. The text
> of
> the motion, to which I give my +1, is as follows:
>
> The Xerces community recommends to the Apache Software Foundation Board
> that:
>
> 1. The top-level Xerces project contain the existing Xerces-J,
> Xerces-C and Xerces-P subprojects of the Apache XML project
>
> 2. The initial committers for this project be the existing committers
> of
> the Xerces-C, Xerces-J and Xerces-P subprojects
>
> 3. The initial PMC members for this project be:
>
> Andy Clark
> Michael Glavassevich
> Neil Graham
> Berin Lautenbach
> Gareth Reakes
> Jason Stewart
>
> thus representing each of Xerces-J, Xerces-C and Xerces-P.
>
> 4. The initial PMC Chairperson be Gareth Reakes.
>
> 5. The mission statement and charter for the new project will be as
> follows:
>
> ================================
> 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 and closely related technologies
> 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 and closely related technologies 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 code base which formed the foundations of both the
> Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
> was originally donated to Apache by IBM in 1999. Xerces-Perl
> came into existence as a subproject of the Apache XML project
> after the Xerces-C++ community had already matured to a
> significant extent. All three were subprojects of the Apache XML
> Project until late 2004. At this time, reflecting the growth in
> the Apache XML project and these communities themselves, Apache
> Xerces became a top-level Project of the Apache Software
> Foundation. Apache Xerces still shares much infrastructure with
> the Apache XML project and the other former 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 composed of a number of subprojects
> which fit into one of two categories:
>
> a) An XML parser implementation in some particular programming
> language. There may be multiple parsers for a given
> language, if the API's the parsers support are sufficiently
> dissimilar. At the time of writing, there is one parser for
> each of Java, C/C++ and Perl.
> b) A set of components serving some purpose not directly
> pertinent to XML parsing, but which are used in related
> applications and are tightly bound, usually through internal
> API's, to one (or more) of the parser subprojects.
>
> 4.4 Product. Some deliverable (usually a binary or source
> package) that a subproject releases to the public. Subprojects
> may have multiple products.
>
> 4.5 Contributor. Anyone who makes a contribution to the development
> of the Apache Xerces project or a subproject.
>
> 4.6 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
> 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.
>
> 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 When a new subproject proposal is submitted to the PMC, it
> may be accepted by a two-thirds vote of the PMC.
>
> 6.2 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 In order to ensure that all code contained in the Apache
> Xerces project's code repository is free of licensing,
> intellectual property and patent issues, any developer wishing
> to contribute a new feature to Xerces must either sign:
>
> a) If contributing as an individual, sign the "Individual
> Contributor License Agreement (CLA)"
> (http://www.apache.org/licenses/icla.txt) and file a copy with
> the Secretary of the Corporation; or
> b) If making the contribution as part of their employment
> responsibilities, sign the "Corporate CLA (CCLA)",
> (http://www.apache.org/licenses/cla-corporate.txt) and file a
> copy with the Secretary of the Corporation.
>
> 7.3 If the contribution in question is a small bugfix, the
> contributor need not sign a CLA, but need only provide the
> following information, attaching it to the communication
> containing the patch:
>
> a) Name and employer
> b) Are you the author of the code being conributed?
> c) Do you have the right to grant the copyright and patent
> licenses for the contribution that are set forth in the ASF v.2.0
> license (http://www.apache.org/licenses/LICENSE-2.0)?
> d) Does your employer have any rights to code that you have
> written, for example, through your contract for employment? If
> so, has your employer given you permission to contribute the code
> on its behalf or waived its rights in the code?
> e) Are you aware of any third-party licenses or other
> restrictions (such as related patents or trademarks) that could
> apply to your contribution? If so, what are they?
>
> 7.4 Contributors 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.
>
> 8.2 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.
>
> 8.3 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.4 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.5 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.
>
> 8.6 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 -- A xerces.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
> 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.
>
> 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; see sections 7.2 and 7.3.
>
> 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 should 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.
>
>
> Neil Graham
> Manager, XML Parser Development
> IBM Toronto Lab
> Phone: 905-413-3519, T/L 969-3519
> E-mail: neilg@ca.ibm.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by James Berry <ja...@jberry.us>.
+1.
Thanks for getting all this together, Neil.
James.
On Nov 14, 2004, at 8:21 PM, Neil Graham wrote:
> Hello all Xerces developers and XML PMC'ers,
>
> I think we're finally at the point where we can vote to transform
> Xerces
> into a top-level project of the Apache Software Foundation. The text
> of
> the motion, to which I give my +1, is as follows:
>
> The Xerces community recommends to the Apache Software Foundation Board
> that:
>
> 1. The top-level Xerces project contain the existing Xerces-J,
> Xerces-C and Xerces-P subprojects of the Apache XML project
>
> 2. The initial committers for this project be the existing committers
> of
> the Xerces-C, Xerces-J and Xerces-P subprojects
>
> 3. The initial PMC members for this project be:
>
> Andy Clark
> Michael Glavassevich
> Neil Graham
> Berin Lautenbach
> Gareth Reakes
> Jason Stewart
>
> thus representing each of Xerces-J, Xerces-C and Xerces-P.
>
> 4. The initial PMC Chairperson be Gareth Reakes.
>
> 5. The mission statement and charter for the new project will be as
> follows:
>
> ================================
> 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 and closely related technologies
> 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 and closely related technologies 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 code base which formed the foundations of both the
> Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
> was originally donated to Apache by IBM in 1999. Xerces-Perl
> came into existence as a subproject of the Apache XML project
> after the Xerces-C++ community had already matured to a
> significant extent. All three were subprojects of the Apache XML
> Project until late 2004. At this time, reflecting the growth in
> the Apache XML project and these communities themselves, Apache
> Xerces became a top-level Project of the Apache Software
> Foundation. Apache Xerces still shares much infrastructure with
> the Apache XML project and the other former 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 composed of a number of subprojects
> which fit into one of two categories:
>
> a) An XML parser implementation in some particular programming
> language. There may be multiple parsers for a given
> language, if the API's the parsers support are sufficiently
> dissimilar. At the time of writing, there is one parser for
> each of Java, C/C++ and Perl.
> b) A set of components serving some purpose not directly
> pertinent to XML parsing, but which are used in related
> applications and are tightly bound, usually through internal
> API's, to one (or more) of the parser subprojects.
>
> 4.4 Product. Some deliverable (usually a binary or source
> package) that a subproject releases to the public. Subprojects
> may have multiple products.
>
> 4.5 Contributor. Anyone who makes a contribution to the development
> of the Apache Xerces project or a subproject.
>
> 4.6 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
> 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.
>
> 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 When a new subproject proposal is submitted to the PMC, it
> may be accepted by a two-thirds vote of the PMC.
>
> 6.2 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 In order to ensure that all code contained in the Apache
> Xerces project's code repository is free of licensing,
> intellectual property and patent issues, any developer wishing
> to contribute a new feature to Xerces must either sign:
>
> a) If contributing as an individual, sign the "Individual
> Contributor License Agreement (CLA)"
> (http://www.apache.org/licenses/icla.txt) and file a copy with
> the Secretary of the Corporation; or
> b) If making the contribution as part of their employment
> responsibilities, sign the "Corporate CLA (CCLA)",
> (http://www.apache.org/licenses/cla-corporate.txt) and file a
> copy with the Secretary of the Corporation.
>
> 7.3 If the contribution in question is a small bugfix, the
> contributor need not sign a CLA, but need only provide the
> following information, attaching it to the communication
> containing the patch:
>
> a) Name and employer
> b) Are you the author of the code being conributed?
> c) Do you have the right to grant the copyright and patent
> licenses for the contribution that are set forth in the ASF v.2.0
> license (http://www.apache.org/licenses/LICENSE-2.0)?
> d) Does your employer have any rights to code that you have
> written, for example, through your contract for employment? If
> so, has your employer given you permission to contribute the code
> on its behalf or waived its rights in the code?
> e) Are you aware of any third-party licenses or other
> restrictions (such as related patents or trademarks) that could
> apply to your contribution? If so, what are they?
>
> 7.4 Contributors 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.
>
> 8.2 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.
>
> 8.3 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.4 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.5 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.
>
> 8.6 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 -- A xerces.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
> 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.
>
> 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; see sections 7.2 and 7.3.
>
> 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 should 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.
>
>
> Neil Graham
> Manager, XML Parser Development
> IBM Toronto Lab
> Phone: 905-413-3519, T/L 969-3519
> E-mail: neilg@ca.ibm.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Gareth Reakes <ga...@parthenoncomputing.com>.
Hi all,
Thanks for the nomination for chair Neil.
+1
Gareth
On 15 Nov 2004, at 4:21, Neil Graham wrote:
> Hello all Xerces developers and XML PMC'ers,
>
> I think we're finally at the point where we can vote to transform
> Xerces
> into a top-level project of the Apache Software Foundation. The text
> of
> the motion, to which I give my +1, is as follows:
>
> The Xerces community recommends to the Apache Software Foundation Board
> that:
>
> 1. The top-level Xerces project contain the existing Xerces-J,
> Xerces-C and Xerces-P subprojects of the Apache XML project
>
> 2. The initial committers for this project be the existing committers
> of
> the Xerces-C, Xerces-J and Xerces-P subprojects
>
> 3. The initial PMC members for this project be:
>
> Andy Clark
> Michael Glavassevich
> Neil Graham
> Berin Lautenbach
> Gareth Reakes
> Jason Stewart
>
> thus representing each of Xerces-J, Xerces-C and Xerces-P.
>
> 4. The initial PMC Chairperson be Gareth Reakes.
>
> 5. The mission statement and charter for the new project will be as
> follows:
>
> ================================
> 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 and closely related technologies
> 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 and closely related technologies 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 code base which formed the foundations of both the
> Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
> was originally donated to Apache by IBM in 1999. Xerces-Perl
> came into existence as a subproject of the Apache XML project
> after the Xerces-C++ community had already matured to a
> significant extent. All three were subprojects of the Apache XML
> Project until late 2004. At this time, reflecting the growth in
> the Apache XML project and these communities themselves, Apache
> Xerces became a top-level Project of the Apache Software
> Foundation. Apache Xerces still shares much infrastructure with
> the Apache XML project and the other former 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 composed of a number of subprojects
> which fit into one of two categories:
>
> a) An XML parser implementation in some particular programming
> language. There may be multiple parsers for a given
> language, if the API's the parsers support are sufficiently
> dissimilar. At the time of writing, there is one parser for
> each of Java, C/C++ and Perl.
> b) A set of components serving some purpose not directly
> pertinent to XML parsing, but which are used in related
> applications and are tightly bound, usually through internal
> API's, to one (or more) of the parser subprojects.
>
> 4.4 Product. Some deliverable (usually a binary or source
> package) that a subproject releases to the public. Subprojects
> may have multiple products.
>
> 4.5 Contributor. Anyone who makes a contribution to the development
> of the Apache Xerces project or a subproject.
>
> 4.6 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
> 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.
>
> 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 When a new subproject proposal is submitted to the PMC, it
> may be accepted by a two-thirds vote of the PMC.
>
> 6.2 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 In order to ensure that all code contained in the Apache
> Xerces project's code repository is free of licensing,
> intellectual property and patent issues, any developer wishing
> to contribute a new feature to Xerces must either sign:
>
> a) If contributing as an individual, sign the "Individual
> Contributor License Agreement (CLA)"
> (http://www.apache.org/licenses/icla.txt) and file a copy with
> the Secretary of the Corporation; or
> b) If making the contribution as part of their employment
> responsibilities, sign the "Corporate CLA (CCLA)",
> (http://www.apache.org/licenses/cla-corporate.txt) and file a
> copy with the Secretary of the Corporation.
>
> 7.3 If the contribution in question is a small bugfix, the
> contributor need not sign a CLA, but need only provide the
> following information, attaching it to the communication
> containing the patch:
>
> a) Name and employer
> b) Are you the author of the code being conributed?
> c) Do you have the right to grant the copyright and patent
> licenses for the contribution that are set forth in the ASF v.2.0
> license (http://www.apache.org/licenses/LICENSE-2.0)?
> d) Does your employer have any rights to code that you have
> written, for example, through your contract for employment? If
> so, has your employer given you permission to contribute the code
> on its behalf or waived its rights in the code?
> e) Are you aware of any third-party licenses or other
> restrictions (such as related patents or trademarks) that could
> apply to your contribution? If so, what are they?
>
> 7.4 Contributors 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.
>
> 8.2 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.
>
> 8.3 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.4 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.5 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.
>
> 8.6 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 -- A xerces.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
> 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.
>
> 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; see sections 7.2 and 7.3.
>
> 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 should 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.
>
>
> Neil Graham
> Manager, XML Parser Development
> IBM Toronto Lab
> Phone: 905-413-3519, T/L 969-3519
> E-mail: neilg@ca.ibm.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: pmc-unsubscribe@xml.apache.org
> For additional commands, e-mail: pmc-help@xml.apache.org
>
>
>
--
Gareth Reakes, Managing Director Parthenon Computing
+44-1865-811184 http://www.parthcomp.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Santiago Pericas-Geertsen <Sa...@Sun.COM>.
On Nov 14, 2004, at 11:21 PM, Neil Graham wrote:
> Hello all Xerces developers and XML PMC'ers,
>
> I think we're finally at the point where we can vote to transform
> Xerces
> into a top-level project of the Apache Software Foundation. The text
> of
> the motion, to which I give my +1, is as follows:
Looks good. +1!
-- Santiago
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Neil Graham <ne...@ca.ibm.com>.
Hi all,
Here's Jason's +1, sent to me privately:
----- Forwarded by Neil Graham/Toronto/IBM on 11/17/2004 09:18 AM -----
"Jason E. Stewart" <ja...@openinformatics.com> wrote on 11/17/2004
08:00:45 AM:
> Neil Graham <ne...@ca.ibm.com> writes:
>
> > Hi Jason. Meant to CC you; would particularly like your +1 since I've
got
> > you on the PMC... Without you we wouldn't be able to migrate
Xerces-P, so
> > hope you're willing!
>
> Hey Neil,
>
> Please forward to the appropriate list.
>
> I'm happy to participate - just swamped with an email migration issue
> currently.
>
> +1
>
> jas.
Cheers,
Neil
Neil Graham
Manager, XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: neilg@ca.ibm.com
Neil Graham/Toronto/IBM@IBMCA
11/14/2004 11:21 PM
Please respond to
xerces-j-dev
To
xerces-c-dev@xml.apache.org, xerces-j-dev@xml.apache.org,
pmc@xml.apache.org
cc
xerces-j-user@xml.apache.org
Subject
[VOTE]: motion to transform Xerces into a top-level project
Hello all Xerces developers and XML PMC'ers,
I think we're finally at the point where we can vote to transform Xerces
into a top-level project of the Apache Software Foundation. The text of
the motion, to which I give my +1, is as follows:
The Xerces community recommends to the Apache Software Foundation Board
that:
1. The top-level Xerces project contain the existing Xerces-J,
Xerces-C and Xerces-P subprojects of the Apache XML project
2. The initial committers for this project be the existing committers of
the Xerces-C, Xerces-J and Xerces-P subprojects
3. The initial PMC members for this project be:
Andy Clark
Michael Glavassevich
Neil Graham
Berin Lautenbach
Gareth Reakes
Jason Stewart
thus representing each of Xerces-J, Xerces-C and Xerces-P.
4. The initial PMC Chairperson be Gareth Reakes.
5. The mission statement and charter for the new project will be as
follows:
================================
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 and closely related technologies
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 and closely related technologies 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 code base which formed the foundations of both the
Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
was originally donated to Apache by IBM in 1999. Xerces-Perl
came into existence as a subproject of the Apache XML project
after the Xerces-C++ community had already matured to a
significant extent. All three were subprojects of the Apache XML
Project until late 2004. At this time, reflecting the growth in
the Apache XML project and these communities themselves, Apache
Xerces became a top-level Project of the Apache Software
Foundation. Apache Xerces still shares much infrastructure with
the Apache XML project and the other former 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 composed of a number of subprojects
which fit into one of two categories:
a) An XML parser implementation in some particular programming
language. There may be multiple parsers for a given
language, if the API's the parsers support are sufficiently
dissimilar. At the time of writing, there is one parser for
each of Java, C/C++ and Perl.
b) A set of components serving some purpose not directly
pertinent to XML parsing, but which are used in related
applications and are tightly bound, usually through internal
API's, to one (or more) of the parser subprojects.
4.4 Product. Some deliverable (usually a binary or source
package) that a subproject releases to the public. Subprojects
may have multiple products.
4.5 Contributor. Anyone who makes a contribution to the development
of the Apache Xerces project or a subproject.
4.6 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
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.
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 When a new subproject proposal is submitted to the PMC, it
may be accepted by a two-thirds vote of the PMC.
6.2 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 In order to ensure that all code contained in the Apache
Xerces project's code repository is free of licensing,
intellectual property and patent issues, any developer wishing
to contribute a new feature to Xerces must either sign:
a) If contributing as an individual, sign the "Individual
Contributor License Agreement (CLA)"
(http://www.apache.org/licenses/icla.txt) and file a copy with
the Secretary of the Corporation; or
b) If making the contribution as part of their employment
responsibilities, sign the "Corporate CLA (CCLA)",
(http://www.apache.org/licenses/cla-corporate.txt) and file a
copy with the Secretary of the Corporation.
7.3 If the contribution in question is a small bugfix, the
contributor need not sign a CLA, but need only provide the
following information, attaching it to the communication
containing the patch:
a) Name and employer
b) Are you the author of the code being conributed?
c) Do you have the right to grant the copyright and patent
licenses for the contribution that are set forth in the ASF v.2.0
license (http://www.apache.org/licenses/LICENSE-2.0)?
d) Does your employer have any rights to code that you have
written, for example, through your contract for employment? If
so, has your employer given you permission to contribute the code
on its behalf or waived its rights in the code?
e) Are you aware of any third-party licenses or other
restrictions (such as related patents or trademarks) that could
apply to your contribution? If so, what are they?
7.4 Contributors 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.
8.2 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.
8.3 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.4 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.5 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.
8.6 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 -- A xerces.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
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.
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; see sections 7.2 and 7.3.
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 should 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.
Neil Graham
Manager, XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: neilg@ca.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Gareth Reakes <ga...@parthenoncomputing.com>.
Hey all,
My first mail only seemed to hit the pmc list - sorry if this is a
duplicate for you.
Thanks for the nomination Neil,
+1 from me.
Gareth
On 15 Nov 2004, at 5:24, Michael Glavassevich wrote:
>
> Neil, thanks for all the hard work you've put in to get us to this
> point.
>
> +1 from me.
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
> Neil Graham/Toronto/IBM@IBMCA wrote on 11/14/2004 11:21:54 PM:
>
> > Hello all Xerces developers and XML PMC'ers,
> >
> > I think we're finally at the point where we can vote to transform
> Xerces
> > into a top-level project of the Apache Software Foundation. Â The
> text of
> > the motion, to which I give my +1, is as follows:
> >
> > The Xerces community recommends to the Apache Software Foundation
> Board
> > that:
> >
> > 1. Â The top-level Xerces project contain the existing Xerces-J,
> > Xerces-C and Xerces-P subprojects of the Apache XML project
> >
> > 2. The initial committers for this project be the existing
> committers of
> > the Xerces-C, Xerces-J and Xerces-P subprojects
> >
> > 3. The initial PMC members for this project be:
> >
> > Andy Clark
> > Michael Glavassevich
> > Neil Graham
> > Berin Lautenbach
> > Gareth Reakes
> > Jason Stewart
> >
> > thus representing each of Xerces-J, Xerces-C and Xerces-P.
> >
> > 4. The initial PMC Chairperson be Gareth Reakes.
> >
> > 5. Â The mission statement and charter for the new project will be as
> > follows:
> >
> > ================================
> > 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 and closely related technologies
> > 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 and closely related technologies 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 code base which formed the foundations of both the
> > Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
> > was originally donated to Apache by IBM in 1999. Â Xerces-Perl
> > came into existence as a subproject of the Apache XML project
> > after the Xerces-C++ community had already matured to a
> > significant extent. Â All three were subprojects of the Apache XML
> > Project until late 2004. Â At this time, reflecting the growth in
> > the Apache XML project and these communities themselves, Apache
> > Xerces became a top-level Project of the Apache Software
> > Foundation. Â Apache Xerces still shares much infrastructure with
> > the Apache XML project and the other former 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 composed of a number of
> subprojects
> > which fit into one of two categories:
> >
> > a) An XML parser implementation in some particular programming
> > Â Â language. Â There may be multiple parsers for a given
> > Â Â language, if the API's the parsers support are sufficiently
> > Â Â dissimilar. Â At the time of writing, there is one parser for
> > Â Â each of Java, C/C++ and Perl.
> > b) A set of components serving some purpose not directly
> > Â Â pertinent to XML parsing, but which are used in related
> > Â Â applications and are tightly bound, usually through internal
> > Â Â API's, to one (or more) of the parser subprojects.
> >
> > 4.4 Product. Â Some deliverable (usually a binary or source
> > package) that a subproject releases to the public. Â Subprojects
> > may have multiple products.
> >
> > 4.5 Contributor. Â Anyone who makes a contribution to the development
> > of the Apache Xerces project or a subproject.
> >
> > 4.6 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
> > 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.
> >
> > 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 When a new subproject proposal is submitted to the PMC, it
> > may be accepted by a two-thirds vote of the PMC.
> >
> > 6.2 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 In order to ensure that all code contained in the Apache
> > Xerces project's code repository is free of licensing,
> > intellectual property and patent issues, any developer wishing
> > to contribute a new feature to Xerces must either sign:
> >
> > a) If contributing as an individual, sign the "Individual
> > Â Â Contributor License Agreement (CLA)"
> > Â Â (http://www.apache.org/licenses/icla.txt) and file a copy with
> > Â Â the Secretary of the Corporation; or
> > b) If making the contribution as part of their employment
> > Â Â responsibilities, sign the "Corporate CLA (CCLA)",
> > Â Â (http://www.apache.org/licenses/cla-corporate.txt) and file a
> > Â Â copy with the Secretary of the Corporation.
> >
> > 7.3 If the contribution in question is a small bugfix, the
> > contributor need not sign a CLA, but need only provide the
> > following information, attaching it to the communication
> > containing the patch:
> >
> > a) Name and employer
> > b) Are you the author of the code being conributed?
> > c) Do you have the right to grant the copyright and patent
> > Â Â licenses for the contribution that are set forth in the ASF v.2.0
> > Â Â license (http://www.apache.org/licenses/LICENSE-2.0)?
> > d) Does your employer have any rights to code that you have
> > Â Â written, for example, through your contract for employment? Â If
> > Â Â so, has your employer given you permission to contribute the code
> > Â Â on its behalf or waived its rights in the code?
> > e) Are you aware of any third-party licenses or other
> > Â Â restrictions (such as related patents or trademarks) that could
> > Â Â apply to your contribution? Â If so, what are they?
> >
> > 7.4 Contributors 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.
> >
> > 8.2 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.
> >
> > 8.3 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.4 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.5 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.
> >
> > 8.6 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 -- A xerces.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
> > 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.
> >
> > 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; see sections 7.2 and 7.3.
> >
> > 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 should 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.
> >
> >
> > Neil Graham
> > Manager, XML Parser Development
> > IBM Toronto Lab
> > Phone: Â 905-413-3519, T/L 969-3519
> > E-mail: Â neilg@ca.ibm.com
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-j-user-help@xml.apache.org
> >
>
--
Gareth Reakes, Managing Director Parthenon Computing
+44-1865-811184 http://www.parthcomp.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Gareth Reakes <ga...@parthenoncomputing.com>.
Hey all,
My first mail only seemed to hit the pmc list - sorry if this is a
duplicate for you.
Thanks for the nomination Neil,
+1 from me.
Gareth
On 15 Nov 2004, at 5:24, Michael Glavassevich wrote:
>
> Neil, thanks for all the hard work you've put in to get us to this
> point.
>
> +1 from me.
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
> Neil Graham/Toronto/IBM@IBMCA wrote on 11/14/2004 11:21:54 PM:
>
> > Hello all Xerces developers and XML PMC'ers,
> >
> > I think we're finally at the point where we can vote to transform
> Xerces
> > into a top-level project of the Apache Software Foundation. Â The
> text of
> > the motion, to which I give my +1, is as follows:
> >
> > The Xerces community recommends to the Apache Software Foundation
> Board
> > that:
> >
> > 1. Â The top-level Xerces project contain the existing Xerces-J,
> > Xerces-C and Xerces-P subprojects of the Apache XML project
> >
> > 2. The initial committers for this project be the existing
> committers of
> > the Xerces-C, Xerces-J and Xerces-P subprojects
> >
> > 3. The initial PMC members for this project be:
> >
> > Andy Clark
> > Michael Glavassevich
> > Neil Graham
> > Berin Lautenbach
> > Gareth Reakes
> > Jason Stewart
> >
> > thus representing each of Xerces-J, Xerces-C and Xerces-P.
> >
> > 4. The initial PMC Chairperson be Gareth Reakes.
> >
> > 5. Â The mission statement and charter for the new project will be as
> > follows:
> >
> > ================================
> > 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 and closely related technologies
> > 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 and closely related technologies 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 code base which formed the foundations of both the
> > Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
> > was originally donated to Apache by IBM in 1999. Â Xerces-Perl
> > came into existence as a subproject of the Apache XML project
> > after the Xerces-C++ community had already matured to a
> > significant extent. Â All three were subprojects of the Apache XML
> > Project until late 2004. Â At this time, reflecting the growth in
> > the Apache XML project and these communities themselves, Apache
> > Xerces became a top-level Project of the Apache Software
> > Foundation. Â Apache Xerces still shares much infrastructure with
> > the Apache XML project and the other former 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 composed of a number of
> subprojects
> > which fit into one of two categories:
> >
> > a) An XML parser implementation in some particular programming
> > Â Â language. Â There may be multiple parsers for a given
> > Â Â language, if the API's the parsers support are sufficiently
> > Â Â dissimilar. Â At the time of writing, there is one parser for
> > Â Â each of Java, C/C++ and Perl.
> > b) A set of components serving some purpose not directly
> > Â Â pertinent to XML parsing, but which are used in related
> > Â Â applications and are tightly bound, usually through internal
> > Â Â API's, to one (or more) of the parser subprojects.
> >
> > 4.4 Product. Â Some deliverable (usually a binary or source
> > package) that a subproject releases to the public. Â Subprojects
> > may have multiple products.
> >
> > 4.5 Contributor. Â Anyone who makes a contribution to the development
> > of the Apache Xerces project or a subproject.
> >
> > 4.6 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
> > 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.
> >
> > 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 When a new subproject proposal is submitted to the PMC, it
> > may be accepted by a two-thirds vote of the PMC.
> >
> > 6.2 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 In order to ensure that all code contained in the Apache
> > Xerces project's code repository is free of licensing,
> > intellectual property and patent issues, any developer wishing
> > to contribute a new feature to Xerces must either sign:
> >
> > a) If contributing as an individual, sign the "Individual
> > Â Â Contributor License Agreement (CLA)"
> > Â Â (http://www.apache.org/licenses/icla.txt) and file a copy with
> > Â Â the Secretary of the Corporation; or
> > b) If making the contribution as part of their employment
> > Â Â responsibilities, sign the "Corporate CLA (CCLA)",
> > Â Â (http://www.apache.org/licenses/cla-corporate.txt) and file a
> > Â Â copy with the Secretary of the Corporation.
> >
> > 7.3 If the contribution in question is a small bugfix, the
> > contributor need not sign a CLA, but need only provide the
> > following information, attaching it to the communication
> > containing the patch:
> >
> > a) Name and employer
> > b) Are you the author of the code being conributed?
> > c) Do you have the right to grant the copyright and patent
> > Â Â licenses for the contribution that are set forth in the ASF v.2.0
> > Â Â license (http://www.apache.org/licenses/LICENSE-2.0)?
> > d) Does your employer have any rights to code that you have
> > Â Â written, for example, through your contract for employment? Â If
> > Â Â so, has your employer given you permission to contribute the code
> > Â Â on its behalf or waived its rights in the code?
> > e) Are you aware of any third-party licenses or other
> > Â Â restrictions (such as related patents or trademarks) that could
> > Â Â apply to your contribution? Â If so, what are they?
> >
> > 7.4 Contributors 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.
> >
> > 8.2 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.
> >
> > 8.3 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.4 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.5 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.
> >
> > 8.6 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 -- A xerces.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
> > 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.
> >
> > 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; see sections 7.2 and 7.3.
> >
> > 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 should 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.
> >
> >
> > Neil Graham
> > Manager, XML Parser Development
> > IBM Toronto Lab
> > Phone: Â 905-413-3519, T/L 969-3519
> > E-mail: Â neilg@ca.ibm.com
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-j-user-help@xml.apache.org
> >
>
--
Gareth Reakes, Managing Director Parthenon Computing
+44-1865-811184 http://www.parthcomp.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Neil, thanks for all the hard work you've put in to get us to this point.
+1 from me.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Neil Graham/Toronto/IBM@IBMCA wrote on 11/14/2004 11:21:54 PM:
> Hello all Xerces developers and XML PMC'ers,
>
> I think we're finally at the point where we can vote to transform Xerces
> into a top-level project of the Apache Software Foundation. The text of
> the motion, to which I give my +1, is as follows:
>
> The Xerces community recommends to the Apache Software Foundation Board
> that:
>
> 1. The top-level Xerces project contain the existing Xerces-J,
> Xerces-C and Xerces-P subprojects of the Apache XML project
>
> 2. The initial committers for this project be the existing committers of
> the Xerces-C, Xerces-J and Xerces-P subprojects
>
> 3. The initial PMC members for this project be:
>
> Andy Clark
> Michael Glavassevich
> Neil Graham
> Berin Lautenbach
> Gareth Reakes
> Jason Stewart
>
> thus representing each of Xerces-J, Xerces-C and Xerces-P.
>
> 4. The initial PMC Chairperson be Gareth Reakes.
>
> 5. The mission statement and charter for the new project will be as
> follows:
>
> ================================
> 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 and closely related technologies
> 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 and closely related technologies 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 code base which formed the foundations of both the
> Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
> was originally donated to Apache by IBM in 1999. Xerces-Perl
> came into existence as a subproject of the Apache XML project
> after the Xerces-C++ community had already matured to a
> significant extent. All three were subprojects of the Apache XML
> Project until late 2004. At this time, reflecting the growth in
> the Apache XML project and these communities themselves, Apache
> Xerces became a top-level Project of the Apache Software
> Foundation. Apache Xerces still shares much infrastructure with
> the Apache XML project and the other former 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 composed of a number of subprojects
> which fit into one of two categories:
>
> a) An XML parser implementation in some particular programming
> language. There may be multiple parsers for a given
> language, if the API's the parsers support are sufficiently
> dissimilar. At the time of writing, there is one parser for
> each of Java, C/C++ and Perl.
> b) A set of components serving some purpose not directly
> pertinent to XML parsing, but which are used in related
> applications and are tightly bound, usually through internal
> API's, to one (or more) of the parser subprojects.
>
> 4.4 Product. Some deliverable (usually a binary or source
> package) that a subproject releases to the public. Subprojects
> may have multiple products.
>
> 4.5 Contributor. Anyone who makes a contribution to the development
> of the Apache Xerces project or a subproject.
>
> 4.6 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
> 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.
>
> 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 When a new subproject proposal is submitted to the PMC, it
> may be accepted by a two-thirds vote of the PMC.
>
> 6.2 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 In order to ensure that all code contained in the Apache
> Xerces project's code repository is free of licensing,
> intellectual property and patent issues, any developer wishing
> to contribute a new feature to Xerces must either sign:
>
> a) If contributing as an individual, sign the "Individual
> Contributor License Agreement (CLA)"
> (http://www.apache.org/licenses/icla.txt) and file a copy with
> the Secretary of the Corporation; or
> b) If making the contribution as part of their employment
> responsibilities, sign the "Corporate CLA (CCLA)",
> (http://www.apache.org/licenses/cla-corporate.txt) and file a
> copy with the Secretary of the Corporation.
>
> 7.3 If the contribution in question is a small bugfix, the
> contributor need not sign a CLA, but need only provide the
> following information, attaching it to the communication
> containing the patch:
>
> a) Name and employer
> b) Are you the author of the code being conributed?
> c) Do you have the right to grant the copyright and patent
> licenses for the contribution that are set forth in the ASF v.2.0
> license (http://www.apache.org/licenses/LICENSE-2.0)?
> d) Does your employer have any rights to code that you have
> written, for example, through your contract for employment? If
> so, has your employer given you permission to contribute the code
> on its behalf or waived its rights in the code?
> e) Are you aware of any third-party licenses or other
> restrictions (such as related patents or trademarks) that could
> apply to your contribution? If so, what are they?
>
> 7.4 Contributors 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.
>
> 8.2 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.
>
> 8.3 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.4 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.5 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.
>
> 8.6 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 -- A xerces.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
> 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.
>
> 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; see sections 7.2 and 7.3.
>
> 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 should 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.
>
>
> Neil Graham
> Manager, XML Parser Development
> IBM Toronto Lab
> Phone: 905-413-3519, T/L 969-3519
> E-mail: neilg@ca.ibm.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-user-help@xml.apache.org
>
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Neil, thanks for all the hard work you've put in to get us to this point.
+1 from me.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Neil Graham/Toronto/IBM@IBMCA wrote on 11/14/2004 11:21:54 PM:
> Hello all Xerces developers and XML PMC'ers,
>
> I think we're finally at the point where we can vote to transform Xerces
> into a top-level project of the Apache Software Foundation. The text of
> the motion, to which I give my +1, is as follows:
>
> The Xerces community recommends to the Apache Software Foundation Board
> that:
>
> 1. The top-level Xerces project contain the existing Xerces-J,
> Xerces-C and Xerces-P subprojects of the Apache XML project
>
> 2. The initial committers for this project be the existing committers of
> the Xerces-C, Xerces-J and Xerces-P subprojects
>
> 3. The initial PMC members for this project be:
>
> Andy Clark
> Michael Glavassevich
> Neil Graham
> Berin Lautenbach
> Gareth Reakes
> Jason Stewart
>
> thus representing each of Xerces-J, Xerces-C and Xerces-P.
>
> 4. The initial PMC Chairperson be Gareth Reakes.
>
> 5. The mission statement and charter for the new project will be as
> follows:
>
> ================================
> 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 and closely related technologies
> 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 and closely related technologies 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 code base which formed the foundations of both the
> Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
> was originally donated to Apache by IBM in 1999. Xerces-Perl
> came into existence as a subproject of the Apache XML project
> after the Xerces-C++ community had already matured to a
> significant extent. All three were subprojects of the Apache XML
> Project until late 2004. At this time, reflecting the growth in
> the Apache XML project and these communities themselves, Apache
> Xerces became a top-level Project of the Apache Software
> Foundation. Apache Xerces still shares much infrastructure with
> the Apache XML project and the other former 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 composed of a number of subprojects
> which fit into one of two categories:
>
> a) An XML parser implementation in some particular programming
> language. There may be multiple parsers for a given
> language, if the API's the parsers support are sufficiently
> dissimilar. At the time of writing, there is one parser for
> each of Java, C/C++ and Perl.
> b) A set of components serving some purpose not directly
> pertinent to XML parsing, but which are used in related
> applications and are tightly bound, usually through internal
> API's, to one (or more) of the parser subprojects.
>
> 4.4 Product. Some deliverable (usually a binary or source
> package) that a subproject releases to the public. Subprojects
> may have multiple products.
>
> 4.5 Contributor. Anyone who makes a contribution to the development
> of the Apache Xerces project or a subproject.
>
> 4.6 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
> 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.
>
> 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 When a new subproject proposal is submitted to the PMC, it
> may be accepted by a two-thirds vote of the PMC.
>
> 6.2 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 In order to ensure that all code contained in the Apache
> Xerces project's code repository is free of licensing,
> intellectual property and patent issues, any developer wishing
> to contribute a new feature to Xerces must either sign:
>
> a) If contributing as an individual, sign the "Individual
> Contributor License Agreement (CLA)"
> (http://www.apache.org/licenses/icla.txt) and file a copy with
> the Secretary of the Corporation; or
> b) If making the contribution as part of their employment
> responsibilities, sign the "Corporate CLA (CCLA)",
> (http://www.apache.org/licenses/cla-corporate.txt) and file a
> copy with the Secretary of the Corporation.
>
> 7.3 If the contribution in question is a small bugfix, the
> contributor need not sign a CLA, but need only provide the
> following information, attaching it to the communication
> containing the patch:
>
> a) Name and employer
> b) Are you the author of the code being conributed?
> c) Do you have the right to grant the copyright and patent
> licenses for the contribution that are set forth in the ASF v.2.0
> license (http://www.apache.org/licenses/LICENSE-2.0)?
> d) Does your employer have any rights to code that you have
> written, for example, through your contract for employment? If
> so, has your employer given you permission to contribute the code
> on its behalf or waived its rights in the code?
> e) Are you aware of any third-party licenses or other
> restrictions (such as related patents or trademarks) that could
> apply to your contribution? If so, what are they?
>
> 7.4 Contributors 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.
>
> 8.2 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.
>
> 8.3 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.4 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.5 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.
>
> 8.6 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 -- A xerces.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
> 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.
>
> 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; see sections 7.2 and 7.3.
>
> 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 should 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.
>
>
> Neil Graham
> Manager, XML Parser Development
> IBM Toronto Lab
> Phone: 905-413-3519, T/L 969-3519
> E-mail: neilg@ca.ibm.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-user-help@xml.apache.org
>
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Shane Curcuru <sh...@yahoo.com>.
+1 on Neil's motion below.
Yay!
--- Neil Graham <ne...@ca.ibm.com> wrote:
> Hello all Xerces developers and XML PMC'ers,
>
> I think we're finally at the point where we can vote to transform
> Xerces
> into a top-level project of the Apache Software Foundation. The text
> of
> the motion, to which I give my +1, is as follows:
>
> The Xerces community recommends to the Apache Software Foundation
> Board
> that:
>
> 1. The top-level Xerces project contain the existing Xerces-J,
> Xerces-C and Xerces-P subprojects of the Apache XML project
>
> 2. The initial committers for this project be the existing committers
> of
> the Xerces-C, Xerces-J and Xerces-P subprojects
>
> 3. The initial PMC members for this project be:
>
> Andy Clark
> Michael Glavassevich
> Neil Graham
> Berin Lautenbach
> Gareth Reakes
> Jason Stewart
>
> thus representing each of Xerces-J, Xerces-C and Xerces-P.
>
> 4. The initial PMC Chairperson be Gareth Reakes.
>
> 5. The mission statement and charter for the new project will be as
> follows:
... etc.
=====
- Shane
<eof .sig="Go Sox! And Come to ApacheCon!" />
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Neil, thanks for all the hard work you've put in to get us to this point.
+1 from me.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Neil Graham/Toronto/IBM@IBMCA wrote on 11/14/2004 11:21:54 PM:
> Hello all Xerces developers and XML PMC'ers,
>
> I think we're finally at the point where we can vote to transform Xerces
> into a top-level project of the Apache Software Foundation. The text of
> the motion, to which I give my +1, is as follows:
>
> The Xerces community recommends to the Apache Software Foundation Board
> that:
>
> 1. The top-level Xerces project contain the existing Xerces-J,
> Xerces-C and Xerces-P subprojects of the Apache XML project
>
> 2. The initial committers for this project be the existing committers of
> the Xerces-C, Xerces-J and Xerces-P subprojects
>
> 3. The initial PMC members for this project be:
>
> Andy Clark
> Michael Glavassevich
> Neil Graham
> Berin Lautenbach
> Gareth Reakes
> Jason Stewart
>
> thus representing each of Xerces-J, Xerces-C and Xerces-P.
>
> 4. The initial PMC Chairperson be Gareth Reakes.
>
> 5. The mission statement and charter for the new project will be as
> follows:
>
> ================================
> 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 and closely related technologies
> 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 and closely related technologies 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 code base which formed the foundations of both the
> Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
> was originally donated to Apache by IBM in 1999. Xerces-Perl
> came into existence as a subproject of the Apache XML project
> after the Xerces-C++ community had already matured to a
> significant extent. All three were subprojects of the Apache XML
> Project until late 2004. At this time, reflecting the growth in
> the Apache XML project and these communities themselves, Apache
> Xerces became a top-level Project of the Apache Software
> Foundation. Apache Xerces still shares much infrastructure with
> the Apache XML project and the other former 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 composed of a number of subprojects
> which fit into one of two categories:
>
> a) An XML parser implementation in some particular programming
> language. There may be multiple parsers for a given
> language, if the API's the parsers support are sufficiently
> dissimilar. At the time of writing, there is one parser for
> each of Java, C/C++ and Perl.
> b) A set of components serving some purpose not directly
> pertinent to XML parsing, but which are used in related
> applications and are tightly bound, usually through internal
> API's, to one (or more) of the parser subprojects.
>
> 4.4 Product. Some deliverable (usually a binary or source
> package) that a subproject releases to the public. Subprojects
> may have multiple products.
>
> 4.5 Contributor. Anyone who makes a contribution to the development
> of the Apache Xerces project or a subproject.
>
> 4.6 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
> 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.
>
> 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 When a new subproject proposal is submitted to the PMC, it
> may be accepted by a two-thirds vote of the PMC.
>
> 6.2 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 In order to ensure that all code contained in the Apache
> Xerces project's code repository is free of licensing,
> intellectual property and patent issues, any developer wishing
> to contribute a new feature to Xerces must either sign:
>
> a) If contributing as an individual, sign the "Individual
> Contributor License Agreement (CLA)"
> (http://www.apache.org/licenses/icla.txt) and file a copy with
> the Secretary of the Corporation; or
> b) If making the contribution as part of their employment
> responsibilities, sign the "Corporate CLA (CCLA)",
> (http://www.apache.org/licenses/cla-corporate.txt) and file a
> copy with the Secretary of the Corporation.
>
> 7.3 If the contribution in question is a small bugfix, the
> contributor need not sign a CLA, but need only provide the
> following information, attaching it to the communication
> containing the patch:
>
> a) Name and employer
> b) Are you the author of the code being conributed?
> c) Do you have the right to grant the copyright and patent
> licenses for the contribution that are set forth in the ASF v.2.0
> license (http://www.apache.org/licenses/LICENSE-2.0)?
> d) Does your employer have any rights to code that you have
> written, for example, through your contract for employment? If
> so, has your employer given you permission to contribute the code
> on its behalf or waived its rights in the code?
> e) Are you aware of any third-party licenses or other
> restrictions (such as related patents or trademarks) that could
> apply to your contribution? If so, what are they?
>
> 7.4 Contributors 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.
>
> 8.2 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.
>
> 8.3 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.4 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.5 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.
>
> 8.6 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 -- A xerces.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
> 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.
>
> 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; see sections 7.2 and 7.3.
>
> 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 should 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.
>
>
> Neil Graham
> Manager, XML Parser Development
> IBM Toronto Lab
> Phone: 905-413-3519, T/L 969-3519
> E-mail: neilg@ca.ibm.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-user-help@xml.apache.org
>
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Neil Graham <ne...@ca.ibm.com>.
Hi all,
Here's Jason's +1, sent to me privately:
----- Forwarded by Neil Graham/Toronto/IBM on 11/17/2004 09:18 AM -----
"Jason E. Stewart" <ja...@openinformatics.com> wrote on 11/17/2004
08:00:45 AM:
> Neil Graham <ne...@ca.ibm.com> writes:
>
> > Hi Jason. Meant to CC you; would particularly like your +1 since I've
got
> > you on the PMC... Without you we wouldn't be able to migrate
Xerces-P, so
> > hope you're willing!
>
> Hey Neil,
>
> Please forward to the appropriate list.
>
> I'm happy to participate - just swamped with an email migration issue
> currently.
>
> +1
>
> jas.
Cheers,
Neil
Neil Graham
Manager, XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: neilg@ca.ibm.com
Neil Graham/Toronto/IBM@IBMCA
11/14/2004 11:21 PM
Please respond to
xerces-j-dev
To
xerces-c-dev@xml.apache.org, xerces-j-dev@xml.apache.org,
pmc@xml.apache.org
cc
xerces-j-user@xml.apache.org
Subject
[VOTE]: motion to transform Xerces into a top-level project
Hello all Xerces developers and XML PMC'ers,
I think we're finally at the point where we can vote to transform Xerces
into a top-level project of the Apache Software Foundation. The text of
the motion, to which I give my +1, is as follows:
The Xerces community recommends to the Apache Software Foundation Board
that:
1. The top-level Xerces project contain the existing Xerces-J,
Xerces-C and Xerces-P subprojects of the Apache XML project
2. The initial committers for this project be the existing committers of
the Xerces-C, Xerces-J and Xerces-P subprojects
3. The initial PMC members for this project be:
Andy Clark
Michael Glavassevich
Neil Graham
Berin Lautenbach
Gareth Reakes
Jason Stewart
thus representing each of Xerces-J, Xerces-C and Xerces-P.
4. The initial PMC Chairperson be Gareth Reakes.
5. The mission statement and charter for the new project will be as
follows:
================================
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 and closely related technologies
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 and closely related technologies 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 code base which formed the foundations of both the
Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
was originally donated to Apache by IBM in 1999. Xerces-Perl
came into existence as a subproject of the Apache XML project
after the Xerces-C++ community had already matured to a
significant extent. All three were subprojects of the Apache XML
Project until late 2004. At this time, reflecting the growth in
the Apache XML project and these communities themselves, Apache
Xerces became a top-level Project of the Apache Software
Foundation. Apache Xerces still shares much infrastructure with
the Apache XML project and the other former 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 composed of a number of subprojects
which fit into one of two categories:
a) An XML parser implementation in some particular programming
language. There may be multiple parsers for a given
language, if the API's the parsers support are sufficiently
dissimilar. At the time of writing, there is one parser for
each of Java, C/C++ and Perl.
b) A set of components serving some purpose not directly
pertinent to XML parsing, but which are used in related
applications and are tightly bound, usually through internal
API's, to one (or more) of the parser subprojects.
4.4 Product. Some deliverable (usually a binary or source
package) that a subproject releases to the public. Subprojects
may have multiple products.
4.5 Contributor. Anyone who makes a contribution to the development
of the Apache Xerces project or a subproject.
4.6 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
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.
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 When a new subproject proposal is submitted to the PMC, it
may be accepted by a two-thirds vote of the PMC.
6.2 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 In order to ensure that all code contained in the Apache
Xerces project's code repository is free of licensing,
intellectual property and patent issues, any developer wishing
to contribute a new feature to Xerces must either sign:
a) If contributing as an individual, sign the "Individual
Contributor License Agreement (CLA)"
(http://www.apache.org/licenses/icla.txt) and file a copy with
the Secretary of the Corporation; or
b) If making the contribution as part of their employment
responsibilities, sign the "Corporate CLA (CCLA)",
(http://www.apache.org/licenses/cla-corporate.txt) and file a
copy with the Secretary of the Corporation.
7.3 If the contribution in question is a small bugfix, the
contributor need not sign a CLA, but need only provide the
following information, attaching it to the communication
containing the patch:
a) Name and employer
b) Are you the author of the code being conributed?
c) Do you have the right to grant the copyright and patent
licenses for the contribution that are set forth in the ASF v.2.0
license (http://www.apache.org/licenses/LICENSE-2.0)?
d) Does your employer have any rights to code that you have
written, for example, through your contract for employment? If
so, has your employer given you permission to contribute the code
on its behalf or waived its rights in the code?
e) Are you aware of any third-party licenses or other
restrictions (such as related patents or trademarks) that could
apply to your contribution? If so, what are they?
7.4 Contributors 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.
8.2 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.
8.3 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.4 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.5 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.
8.6 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 -- A xerces.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
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.
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; see sections 7.2 and 7.3.
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 should 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.
Neil Graham
Manager, XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: neilg@ca.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by David Cargill <ca...@ca.ibm.com>.
+1.
Thanks Neil.
Regards,
David A. Cargill
XML Parser Development
IBM Toronto Lab
(905) 413-2371, tie 969
cargilld@ca.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Neil Graham <ne...@ca.ibm.com>.
Hi all,
Here's Jason's +1, sent to me privately:
----- Forwarded by Neil Graham/Toronto/IBM on 11/17/2004 09:18 AM -----
"Jason E. Stewart" <ja...@openinformatics.com> wrote on 11/17/2004
08:00:45 AM:
> Neil Graham <ne...@ca.ibm.com> writes:
>
> > Hi Jason. Meant to CC you; would particularly like your +1 since I've
got
> > you on the PMC... Without you we wouldn't be able to migrate
Xerces-P, so
> > hope you're willing!
>
> Hey Neil,
>
> Please forward to the appropriate list.
>
> I'm happy to participate - just swamped with an email migration issue
> currently.
>
> +1
>
> jas.
Cheers,
Neil
Neil Graham
Manager, XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: neilg@ca.ibm.com
Neil Graham/Toronto/IBM@IBMCA
11/14/2004 11:21 PM
Please respond to
xerces-j-dev
To
xerces-c-dev@xml.apache.org, xerces-j-dev@xml.apache.org,
pmc@xml.apache.org
cc
xerces-j-user@xml.apache.org
Subject
[VOTE]: motion to transform Xerces into a top-level project
Hello all Xerces developers and XML PMC'ers,
I think we're finally at the point where we can vote to transform Xerces
into a top-level project of the Apache Software Foundation. The text of
the motion, to which I give my +1, is as follows:
The Xerces community recommends to the Apache Software Foundation Board
that:
1. The top-level Xerces project contain the existing Xerces-J,
Xerces-C and Xerces-P subprojects of the Apache XML project
2. The initial committers for this project be the existing committers of
the Xerces-C, Xerces-J and Xerces-P subprojects
3. The initial PMC members for this project be:
Andy Clark
Michael Glavassevich
Neil Graham
Berin Lautenbach
Gareth Reakes
Jason Stewart
thus representing each of Xerces-J, Xerces-C and Xerces-P.
4. The initial PMC Chairperson be Gareth Reakes.
5. The mission statement and charter for the new project will be as
follows:
================================
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 and closely related technologies
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 and closely related technologies 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 code base which formed the foundations of both the
Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
was originally donated to Apache by IBM in 1999. Xerces-Perl
came into existence as a subproject of the Apache XML project
after the Xerces-C++ community had already matured to a
significant extent. All three were subprojects of the Apache XML
Project until late 2004. At this time, reflecting the growth in
the Apache XML project and these communities themselves, Apache
Xerces became a top-level Project of the Apache Software
Foundation. Apache Xerces still shares much infrastructure with
the Apache XML project and the other former 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 composed of a number of subprojects
which fit into one of two categories:
a) An XML parser implementation in some particular programming
language. There may be multiple parsers for a given
language, if the API's the parsers support are sufficiently
dissimilar. At the time of writing, there is one parser for
each of Java, C/C++ and Perl.
b) A set of components serving some purpose not directly
pertinent to XML parsing, but which are used in related
applications and are tightly bound, usually through internal
API's, to one (or more) of the parser subprojects.
4.4 Product. Some deliverable (usually a binary or source
package) that a subproject releases to the public. Subprojects
may have multiple products.
4.5 Contributor. Anyone who makes a contribution to the development
of the Apache Xerces project or a subproject.
4.6 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
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.
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 When a new subproject proposal is submitted to the PMC, it
may be accepted by a two-thirds vote of the PMC.
6.2 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 In order to ensure that all code contained in the Apache
Xerces project's code repository is free of licensing,
intellectual property and patent issues, any developer wishing
to contribute a new feature to Xerces must either sign:
a) If contributing as an individual, sign the "Individual
Contributor License Agreement (CLA)"
(http://www.apache.org/licenses/icla.txt) and file a copy with
the Secretary of the Corporation; or
b) If making the contribution as part of their employment
responsibilities, sign the "Corporate CLA (CCLA)",
(http://www.apache.org/licenses/cla-corporate.txt) and file a
copy with the Secretary of the Corporation.
7.3 If the contribution in question is a small bugfix, the
contributor need not sign a CLA, but need only provide the
following information, attaching it to the communication
containing the patch:
a) Name and employer
b) Are you the author of the code being conributed?
c) Do you have the right to grant the copyright and patent
licenses for the contribution that are set forth in the ASF v.2.0
license (http://www.apache.org/licenses/LICENSE-2.0)?
d) Does your employer have any rights to code that you have
written, for example, through your contract for employment? If
so, has your employer given you permission to contribute the code
on its behalf or waived its rights in the code?
e) Are you aware of any third-party licenses or other
restrictions (such as related patents or trademarks) that could
apply to your contribution? If so, what are they?
7.4 Contributors 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.
8.2 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.
8.3 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.4 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.5 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.
8.6 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 -- A xerces.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
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.
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; see sections 7.2 and 7.3.
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 should 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.
Neil Graham
Manager, XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: neilg@ca.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Sandy Gao <sa...@ca.ibm.com>.
+1
Many thanks to Neil for putting this together.
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
sandygao@ca.ibm.com
Neil Graham/Toronto/IBM@IBMCA
11/14/2004 11:21 PM
Please respond to
xerces-j-dev
To
xerces-c-dev@xml.apache.org, xerces-j-dev@xml.apache.org,
pmc@xml.apache.org
cc
xerces-j-user@xml.apache.org
Subject
[VOTE]: motion to transform Xerces into a top-level project
Hello all Xerces developers and XML PMC'ers,
I think we're finally at the point where we can vote to transform Xerces
into a top-level project of the Apache Software Foundation. The text of
the motion, to which I give my +1, is as follows:
The Xerces community recommends to the Apache Software Foundation Board
that:
1. The top-level Xerces project contain the existing Xerces-J,
Xerces-C and Xerces-P subprojects of the Apache XML project
2. The initial committers for this project be the existing committers of
the Xerces-C, Xerces-J and Xerces-P subprojects
3. The initial PMC members for this project be:
Andy Clark
Michael Glavassevich
Neil Graham
Berin Lautenbach
Gareth Reakes
Jason Stewart
thus representing each of Xerces-J, Xerces-C and Xerces-P.
4. The initial PMC Chairperson be Gareth Reakes.
5. The mission statement and charter for the new project will be as
follows:
================================
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 and closely related technologies
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 and closely related technologies 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 code base which formed the foundations of both the
Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
was originally donated to Apache by IBM in 1999. Xerces-Perl
came into existence as a subproject of the Apache XML project
after the Xerces-C++ community had already matured to a
significant extent. All three were subprojects of the Apache XML
Project until late 2004. At this time, reflecting the growth in
the Apache XML project and these communities themselves, Apache
Xerces became a top-level Project of the Apache Software
Foundation. Apache Xerces still shares much infrastructure with
the Apache XML project and the other former 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 composed of a number of subprojects
which fit into one of two categories:
a) An XML parser implementation in some particular programming
language. There may be multiple parsers for a given
language, if the API's the parsers support are sufficiently
dissimilar. At the time of writing, there is one parser for
each of Java, C/C++ and Perl.
b) A set of components serving some purpose not directly
pertinent to XML parsing, but which are used in related
applications and are tightly bound, usually through internal
API's, to one (or more) of the parser subprojects.
4.4 Product. Some deliverable (usually a binary or source
package) that a subproject releases to the public. Subprojects
may have multiple products.
4.5 Contributor. Anyone who makes a contribution to the development
of the Apache Xerces project or a subproject.
4.6 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
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.
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 When a new subproject proposal is submitted to the PMC, it
may be accepted by a two-thirds vote of the PMC.
6.2 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 In order to ensure that all code contained in the Apache
Xerces project's code repository is free of licensing,
intellectual property and patent issues, any developer wishing
to contribute a new feature to Xerces must either sign:
a) If contributing as an individual, sign the "Individual
Contributor License Agreement (CLA)"
(http://www.apache.org/licenses/icla.txt) and file a copy with
the Secretary of the Corporation; or
b) If making the contribution as part of their employment
responsibilities, sign the "Corporate CLA (CCLA)",
(http://www.apache.org/licenses/cla-corporate.txt) and file a
copy with the Secretary of the Corporation.
7.3 If the contribution in question is a small bugfix, the
contributor need not sign a CLA, but need only provide the
following information, attaching it to the communication
containing the patch:
a) Name and employer
b) Are you the author of the code being conributed?
c) Do you have the right to grant the copyright and patent
licenses for the contribution that are set forth in the ASF v.2.0
license (http://www.apache.org/licenses/LICENSE-2.0)?
d) Does your employer have any rights to code that you have
written, for example, through your contract for employment? If
so, has your employer given you permission to contribute the code
on its behalf or waived its rights in the code?
e) Are you aware of any third-party licenses or other
restrictions (such as related patents or trademarks) that could
apply to your contribution? If so, what are they?
7.4 Contributors 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.
8.2 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.
8.3 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.4 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.5 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.
8.6 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 -- A xerces.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
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.
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; see sections 7.2 and 7.3.
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 should 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.
Neil Graham
Manager, XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: neilg@ca.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Sandy Gao <sa...@ca.ibm.com>.
+1
Many thanks to Neil for putting this together.
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
sandygao@ca.ibm.com
Neil Graham/Toronto/IBM@IBMCA
11/14/2004 11:21 PM
Please respond to
xerces-j-dev
To
xerces-c-dev@xml.apache.org, xerces-j-dev@xml.apache.org,
pmc@xml.apache.org
cc
xerces-j-user@xml.apache.org
Subject
[VOTE]: motion to transform Xerces into a top-level project
Hello all Xerces developers and XML PMC'ers,
I think we're finally at the point where we can vote to transform Xerces
into a top-level project of the Apache Software Foundation. The text of
the motion, to which I give my +1, is as follows:
The Xerces community recommends to the Apache Software Foundation Board
that:
1. The top-level Xerces project contain the existing Xerces-J,
Xerces-C and Xerces-P subprojects of the Apache XML project
2. The initial committers for this project be the existing committers of
the Xerces-C, Xerces-J and Xerces-P subprojects
3. The initial PMC members for this project be:
Andy Clark
Michael Glavassevich
Neil Graham
Berin Lautenbach
Gareth Reakes
Jason Stewart
thus representing each of Xerces-J, Xerces-C and Xerces-P.
4. The initial PMC Chairperson be Gareth Reakes.
5. The mission statement and charter for the new project will be as
follows:
================================
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 and closely related technologies
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 and closely related technologies 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 code base which formed the foundations of both the
Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
was originally donated to Apache by IBM in 1999. Xerces-Perl
came into existence as a subproject of the Apache XML project
after the Xerces-C++ community had already matured to a
significant extent. All three were subprojects of the Apache XML
Project until late 2004. At this time, reflecting the growth in
the Apache XML project and these communities themselves, Apache
Xerces became a top-level Project of the Apache Software
Foundation. Apache Xerces still shares much infrastructure with
the Apache XML project and the other former 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 composed of a number of subprojects
which fit into one of two categories:
a) An XML parser implementation in some particular programming
language. There may be multiple parsers for a given
language, if the API's the parsers support are sufficiently
dissimilar. At the time of writing, there is one parser for
each of Java, C/C++ and Perl.
b) A set of components serving some purpose not directly
pertinent to XML parsing, but which are used in related
applications and are tightly bound, usually through internal
API's, to one (or more) of the parser subprojects.
4.4 Product. Some deliverable (usually a binary or source
package) that a subproject releases to the public. Subprojects
may have multiple products.
4.5 Contributor. Anyone who makes a contribution to the development
of the Apache Xerces project or a subproject.
4.6 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
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.
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 When a new subproject proposal is submitted to the PMC, it
may be accepted by a two-thirds vote of the PMC.
6.2 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 In order to ensure that all code contained in the Apache
Xerces project's code repository is free of licensing,
intellectual property and patent issues, any developer wishing
to contribute a new feature to Xerces must either sign:
a) If contributing as an individual, sign the "Individual
Contributor License Agreement (CLA)"
(http://www.apache.org/licenses/icla.txt) and file a copy with
the Secretary of the Corporation; or
b) If making the contribution as part of their employment
responsibilities, sign the "Corporate CLA (CCLA)",
(http://www.apache.org/licenses/cla-corporate.txt) and file a
copy with the Secretary of the Corporation.
7.3 If the contribution in question is a small bugfix, the
contributor need not sign a CLA, but need only provide the
following information, attaching it to the communication
containing the patch:
a) Name and employer
b) Are you the author of the code being conributed?
c) Do you have the right to grant the copyright and patent
licenses for the contribution that are set forth in the ASF v.2.0
license (http://www.apache.org/licenses/LICENSE-2.0)?
d) Does your employer have any rights to code that you have
written, for example, through your contract for employment? If
so, has your employer given you permission to contribute the code
on its behalf or waived its rights in the code?
e) Are you aware of any third-party licenses or other
restrictions (such as related patents or trademarks) that could
apply to your contribution? If so, what are they?
7.4 Contributors 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.
8.2 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.
8.3 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.4 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.5 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.
8.6 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 -- A xerces.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
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.
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; see sections 7.2 and 7.3.
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 should 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.
Neil Graham
Manager, XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: neilg@ca.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Sandy Gao <sa...@ca.ibm.com>.
+1
Many thanks to Neil for putting this together.
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
sandygao@ca.ibm.com
Neil Graham/Toronto/IBM@IBMCA
11/14/2004 11:21 PM
Please respond to
xerces-j-dev
To
xerces-c-dev@xml.apache.org, xerces-j-dev@xml.apache.org,
pmc@xml.apache.org
cc
xerces-j-user@xml.apache.org
Subject
[VOTE]: motion to transform Xerces into a top-level project
Hello all Xerces developers and XML PMC'ers,
I think we're finally at the point where we can vote to transform Xerces
into a top-level project of the Apache Software Foundation. The text of
the motion, to which I give my +1, is as follows:
The Xerces community recommends to the Apache Software Foundation Board
that:
1. The top-level Xerces project contain the existing Xerces-J,
Xerces-C and Xerces-P subprojects of the Apache XML project
2. The initial committers for this project be the existing committers of
the Xerces-C, Xerces-J and Xerces-P subprojects
3. The initial PMC members for this project be:
Andy Clark
Michael Glavassevich
Neil Graham
Berin Lautenbach
Gareth Reakes
Jason Stewart
thus representing each of Xerces-J, Xerces-C and Xerces-P.
4. The initial PMC Chairperson be Gareth Reakes.
5. The mission statement and charter for the new project will be as
follows:
================================
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 and closely related technologies
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 and closely related technologies 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 code base which formed the foundations of both the
Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
was originally donated to Apache by IBM in 1999. Xerces-Perl
came into existence as a subproject of the Apache XML project
after the Xerces-C++ community had already matured to a
significant extent. All three were subprojects of the Apache XML
Project until late 2004. At this time, reflecting the growth in
the Apache XML project and these communities themselves, Apache
Xerces became a top-level Project of the Apache Software
Foundation. Apache Xerces still shares much infrastructure with
the Apache XML project and the other former 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 composed of a number of subprojects
which fit into one of two categories:
a) An XML parser implementation in some particular programming
language. There may be multiple parsers for a given
language, if the API's the parsers support are sufficiently
dissimilar. At the time of writing, there is one parser for
each of Java, C/C++ and Perl.
b) A set of components serving some purpose not directly
pertinent to XML parsing, but which are used in related
applications and are tightly bound, usually through internal
API's, to one (or more) of the parser subprojects.
4.4 Product. Some deliverable (usually a binary or source
package) that a subproject releases to the public. Subprojects
may have multiple products.
4.5 Contributor. Anyone who makes a contribution to the development
of the Apache Xerces project or a subproject.
4.6 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
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.
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 When a new subproject proposal is submitted to the PMC, it
may be accepted by a two-thirds vote of the PMC.
6.2 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 In order to ensure that all code contained in the Apache
Xerces project's code repository is free of licensing,
intellectual property and patent issues, any developer wishing
to contribute a new feature to Xerces must either sign:
a) If contributing as an individual, sign the "Individual
Contributor License Agreement (CLA)"
(http://www.apache.org/licenses/icla.txt) and file a copy with
the Secretary of the Corporation; or
b) If making the contribution as part of their employment
responsibilities, sign the "Corporate CLA (CCLA)",
(http://www.apache.org/licenses/cla-corporate.txt) and file a
copy with the Secretary of the Corporation.
7.3 If the contribution in question is a small bugfix, the
contributor need not sign a CLA, but need only provide the
following information, attaching it to the communication
containing the patch:
a) Name and employer
b) Are you the author of the code being conributed?
c) Do you have the right to grant the copyright and patent
licenses for the contribution that are set forth in the ASF v.2.0
license (http://www.apache.org/licenses/LICENSE-2.0)?
d) Does your employer have any rights to code that you have
written, for example, through your contract for employment? If
so, has your employer given you permission to contribute the code
on its behalf or waived its rights in the code?
e) Are you aware of any third-party licenses or other
restrictions (such as related patents or trademarks) that could
apply to your contribution? If so, what are they?
7.4 Contributors 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.
8.2 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.
8.3 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.4 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.5 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.
8.6 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 -- A xerces.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
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.
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; see sections 7.2 and 7.3.
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 should 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.
Neil Graham
Manager, XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: neilg@ca.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Shane Curcuru <sh...@yahoo.com>.
+1 on Neil's motion below.
Yay!
--- Neil Graham <ne...@ca.ibm.com> wrote:
> Hello all Xerces developers and XML PMC'ers,
>
> I think we're finally at the point where we can vote to transform
> Xerces
> into a top-level project of the Apache Software Foundation. The text
> of
> the motion, to which I give my +1, is as follows:
>
> The Xerces community recommends to the Apache Software Foundation
> Board
> that:
>
> 1. The top-level Xerces project contain the existing Xerces-J,
> Xerces-C and Xerces-P subprojects of the Apache XML project
>
> 2. The initial committers for this project be the existing committers
> of
> the Xerces-C, Xerces-J and Xerces-P subprojects
>
> 3. The initial PMC members for this project be:
>
> Andy Clark
> Michael Glavassevich
> Neil Graham
> Berin Lautenbach
> Gareth Reakes
> Jason Stewart
>
> thus representing each of Xerces-J, Xerces-C and Xerces-P.
>
> 4. The initial PMC Chairperson be Gareth Reakes.
>
> 5. The mission statement and charter for the new project will be as
> follows:
... etc.
=====
- Shane
<eof .sig="Go Sox! And Come to ApacheCon!" />
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Ankit Pasricha <an...@ca.ibm.com>.
+1
Thanks
Ankit Pasricha
XML Parser Development
IBM Toronto Lab
8200 Warden Avenue, Ontario L6G 1C7
Phone: (905) 413 4941
Neil Graham/Toronto/IBM@IBMCA
11/14/2004 11:21 PM
Please respond to
xerces-j-dev@xml.apache.org
To
xerces-c-dev@xml.apache.org, xerces-j-dev@xml.apache.org,
pmc@xml.apache.org
cc
xerces-j-user@xml.apache.org
Subject
[VOTE]: motion to transform Xerces into a top-level project
Hello all Xerces developers and XML PMC'ers,
I think we're finally at the point where we can vote to transform Xerces
into a top-level project of the Apache Software Foundation. The text of
the motion, to which I give my +1, is as follows:
The Xerces community recommends to the Apache Software Foundation Board
that:
1. The top-level Xerces project contain the existing Xerces-J,
Xerces-C and Xerces-P subprojects of the Apache XML project
2. The initial committers for this project be the existing committers of
the Xerces-C, Xerces-J and Xerces-P subprojects
3. The initial PMC members for this project be:
Andy Clark
Michael Glavassevich
Neil Graham
Berin Lautenbach
Gareth Reakes
Jason Stewart
thus representing each of Xerces-J, Xerces-C and Xerces-P.
4. The initial PMC Chairperson be Gareth Reakes.
5. The mission statement and charter for the new project will be as
follows:
================================
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 and closely related technologies
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 and closely related technologies 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 code base which formed the foundations of both the
Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
was originally donated to Apache by IBM in 1999. Xerces-Perl
came into existence as a subproject of the Apache XML project
after the Xerces-C++ community had already matured to a
significant extent. All three were subprojects of the Apache XML
Project until late 2004. At this time, reflecting the growth in
the Apache XML project and these communities themselves, Apache
Xerces became a top-level Project of the Apache Software
Foundation. Apache Xerces still shares much infrastructure with
the Apache XML project and the other former 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 composed of a number of subprojects
which fit into one of two categories:
a) An XML parser implementation in some particular programming
language. There may be multiple parsers for a given
language, if the API's the parsers support are sufficiently
dissimilar. At the time of writing, there is one parser for
each of Java, C/C++ and Perl.
b) A set of components serving some purpose not directly
pertinent to XML parsing, but which are used in related
applications and are tightly bound, usually through internal
API's, to one (or more) of the parser subprojects.
4.4 Product. Some deliverable (usually a binary or source
package) that a subproject releases to the public. Subprojects
may have multiple products.
4.5 Contributor. Anyone who makes a contribution to the development
of the Apache Xerces project or a subproject.
4.6 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
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.
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 When a new subproject proposal is submitted to the PMC, it
may be accepted by a two-thirds vote of the PMC.
6.2 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 In order to ensure that all code contained in the Apache
Xerces project's code repository is free of licensing,
intellectual property and patent issues, any developer wishing
to contribute a new feature to Xerces must either sign:
a) If contributing as an individual, sign the "Individual
Contributor License Agreement (CLA)"
(http://www.apache.org/licenses/icla.txt) and file a copy with
the Secretary of the Corporation; or
b) If making the contribution as part of their employment
responsibilities, sign the "Corporate CLA (CCLA)",
(http://www.apache.org/licenses/cla-corporate.txt) and file a
copy with the Secretary of the Corporation.
7.3 If the contribution in question is a small bugfix, the
contributor need not sign a CLA, but need only provide the
following information, attaching it to the communication
containing the patch:
a) Name and employer
b) Are you the author of the code being conributed?
c) Do you have the right to grant the copyright and patent
licenses for the contribution that are set forth in the ASF v.2.0
license (http://www.apache.org/licenses/LICENSE-2.0)?
d) Does your employer have any rights to code that you have
written, for example, through your contract for employment? If
so, has your employer given you permission to contribute the code
on its behalf or waived its rights in the code?
e) Are you aware of any third-party licenses or other
restrictions (such as related patents or trademarks) that could
apply to your contribution? If so, what are they?
7.4 Contributors 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.
8.2 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.
8.3 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.4 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.5 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.
8.6 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 -- A xerces.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
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.
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; see sections 7.2 and 7.3.
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 should 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.
Neil Graham
Manager, XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: neilg@ca.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Elena Litani <el...@ca.ibm.com>.
Here is my +1.
--
Elena Litani / IBM Toronto
Neil Graham/Toronto/IBM@IBMCA
11/14/2004 11:21 PM
Please respond to
xerces-j-dev
To
xerces-c-dev@xml.apache.org, xerces-j-dev@xml.apache.org,
pmc@xml.apache.org
cc
xerces-j-user@xml.apache.org
Subject
[VOTE]: motion to transform Xerces into a top-level project
Hello all Xerces developers and XML PMC'ers,
I think we're finally at the point where we can vote to transform Xerces
into a top-level project of the Apache Software Foundation. The text of
the motion, to which I give my +1, is as follows:
The Xerces community recommends to the Apache Software Foundation Board
that:
1. The top-level Xerces project contain the existing Xerces-J,
Xerces-C and Xerces-P subprojects of the Apache XML project
2. The initial committers for this project be the existing committers of
the Xerces-C, Xerces-J and Xerces-P subprojects
3. The initial PMC members for this project be:
Andy Clark
Michael Glavassevich
Neil Graham
Berin Lautenbach
Gareth Reakes
Jason Stewart
thus representing each of Xerces-J, Xerces-C and Xerces-P.
4. The initial PMC Chairperson be Gareth Reakes.
5. The mission statement and charter for the new project will be as
follows:
================================
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 and closely related technologies
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 and closely related technologies 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 code base which formed the foundations of both the
Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
was originally donated to Apache by IBM in 1999. Xerces-Perl
came into existence as a subproject of the Apache XML project
after the Xerces-C++ community had already matured to a
significant extent. All three were subprojects of the Apache XML
Project until late 2004. At this time, reflecting the growth in
the Apache XML project and these communities themselves, Apache
Xerces became a top-level Project of the Apache Software
Foundation. Apache Xerces still shares much infrastructure with
the Apache XML project and the other former 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 composed of a number of subprojects
which fit into one of two categories:
a) An XML parser implementation in some particular programming
language. There may be multiple parsers for a given
language, if the API's the parsers support are sufficiently
dissimilar. At the time of writing, there is one parser for
each of Java, C/C++ and Perl.
b) A set of components serving some purpose not directly
pertinent to XML parsing, but which are used in related
applications and are tightly bound, usually through internal
API's, to one (or more) of the parser subprojects.
4.4 Product. Some deliverable (usually a binary or source
package) that a subproject releases to the public. Subprojects
may have multiple products.
4.5 Contributor. Anyone who makes a contribution to the development
of the Apache Xerces project or a subproject.
4.6 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
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.
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 When a new subproject proposal is submitted to the PMC, it
may be accepted by a two-thirds vote of the PMC.
6.2 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 In order to ensure that all code contained in the Apache
Xerces project's code repository is free of licensing,
intellectual property and patent issues, any developer wishing
to contribute a new feature to Xerces must either sign:
a) If contributing as an individual, sign the "Individual
Contributor License Agreement (CLA)"
(http://www.apache.org/licenses/icla.txt) and file a copy with
the Secretary of the Corporation; or
b) If making the contribution as part of their employment
responsibilities, sign the "Corporate CLA (CCLA)",
(http://www.apache.org/licenses/cla-corporate.txt) and file a
copy with the Secretary of the Corporation.
7.3 If the contribution in question is a small bugfix, the
contributor need not sign a CLA, but need only provide the
following information, attaching it to the communication
containing the patch:
a) Name and employer
b) Are you the author of the code being conributed?
c) Do you have the right to grant the copyright and patent
licenses for the contribution that are set forth in the ASF v.2.0
license (http://www.apache.org/licenses/LICENSE-2.0)?
d) Does your employer have any rights to code that you have
written, for example, through your contract for employment? If
so, has your employer given you permission to contribute the code
on its behalf or waived its rights in the code?
e) Are you aware of any third-party licenses or other
restrictions (such as related patents or trademarks) that could
apply to your contribution? If so, what are they?
7.4 Contributors 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.
8.2 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.
8.3 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.4 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.5 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.
8.6 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 -- A xerces.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
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.
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; see sections 7.2 and 7.3.
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 should 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.
Neil Graham
Manager, XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: neilg@ca.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Ankit Pasricha <an...@ca.ibm.com>.
+1
Thanks
Ankit Pasricha
XML Parser Development
IBM Toronto Lab
8200 Warden Avenue, Ontario L6G 1C7
Phone: (905) 413 4941
Neil Graham/Toronto/IBM@IBMCA
11/14/2004 11:21 PM
Please respond to
xerces-j-dev@xml.apache.org
To
xerces-c-dev@xml.apache.org, xerces-j-dev@xml.apache.org,
pmc@xml.apache.org
cc
xerces-j-user@xml.apache.org
Subject
[VOTE]: motion to transform Xerces into a top-level project
Hello all Xerces developers and XML PMC'ers,
I think we're finally at the point where we can vote to transform Xerces
into a top-level project of the Apache Software Foundation. The text of
the motion, to which I give my +1, is as follows:
The Xerces community recommends to the Apache Software Foundation Board
that:
1. The top-level Xerces project contain the existing Xerces-J,
Xerces-C and Xerces-P subprojects of the Apache XML project
2. The initial committers for this project be the existing committers of
the Xerces-C, Xerces-J and Xerces-P subprojects
3. The initial PMC members for this project be:
Andy Clark
Michael Glavassevich
Neil Graham
Berin Lautenbach
Gareth Reakes
Jason Stewart
thus representing each of Xerces-J, Xerces-C and Xerces-P.
4. The initial PMC Chairperson be Gareth Reakes.
5. The mission statement and charter for the new project will be as
follows:
================================
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 and closely related technologies
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 and closely related technologies 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 code base which formed the foundations of both the
Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
was originally donated to Apache by IBM in 1999. Xerces-Perl
came into existence as a subproject of the Apache XML project
after the Xerces-C++ community had already matured to a
significant extent. All three were subprojects of the Apache XML
Project until late 2004. At this time, reflecting the growth in
the Apache XML project and these communities themselves, Apache
Xerces became a top-level Project of the Apache Software
Foundation. Apache Xerces still shares much infrastructure with
the Apache XML project and the other former 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 composed of a number of subprojects
which fit into one of two categories:
a) An XML parser implementation in some particular programming
language. There may be multiple parsers for a given
language, if the API's the parsers support are sufficiently
dissimilar. At the time of writing, there is one parser for
each of Java, C/C++ and Perl.
b) A set of components serving some purpose not directly
pertinent to XML parsing, but which are used in related
applications and are tightly bound, usually through internal
API's, to one (or more) of the parser subprojects.
4.4 Product. Some deliverable (usually a binary or source
package) that a subproject releases to the public. Subprojects
may have multiple products.
4.5 Contributor. Anyone who makes a contribution to the development
of the Apache Xerces project or a subproject.
4.6 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
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.
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 When a new subproject proposal is submitted to the PMC, it
may be accepted by a two-thirds vote of the PMC.
6.2 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 In order to ensure that all code contained in the Apache
Xerces project's code repository is free of licensing,
intellectual property and patent issues, any developer wishing
to contribute a new feature to Xerces must either sign:
a) If contributing as an individual, sign the "Individual
Contributor License Agreement (CLA)"
(http://www.apache.org/licenses/icla.txt) and file a copy with
the Secretary of the Corporation; or
b) If making the contribution as part of their employment
responsibilities, sign the "Corporate CLA (CCLA)",
(http://www.apache.org/licenses/cla-corporate.txt) and file a
copy with the Secretary of the Corporation.
7.3 If the contribution in question is a small bugfix, the
contributor need not sign a CLA, but need only provide the
following information, attaching it to the communication
containing the patch:
a) Name and employer
b) Are you the author of the code being conributed?
c) Do you have the right to grant the copyright and patent
licenses for the contribution that are set forth in the ASF v.2.0
license (http://www.apache.org/licenses/LICENSE-2.0)?
d) Does your employer have any rights to code that you have
written, for example, through your contract for employment? If
so, has your employer given you permission to contribute the code
on its behalf or waived its rights in the code?
e) Are you aware of any third-party licenses or other
restrictions (such as related patents or trademarks) that could
apply to your contribution? If so, what are they?
7.4 Contributors 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.
8.2 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.
8.3 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.4 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.5 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.
8.6 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 -- A xerces.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
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.
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; see sections 7.2 and 7.3.
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 should 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.
Neil Graham
Manager, XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: neilg@ca.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Neil Delima <nd...@ca.ibm.com>.
Here's my +1.
Thanks,
Neil.
Neil Graham/Toronto/IBM@IBMCA wrote on 11/14/2004 11:21:54 PM:
> Hello all Xerces developers and XML PMC'ers,
>
> I think we're finally at the point where we can vote to transform Xerces
> into a top-level project of the Apache Software Foundation. The text of
> the motion, to which I give my +1, is as follows:
>
> The Xerces community recommends to the Apache Software Foundation Board
> that:
>
> 1. The top-level Xerces project contain the existing Xerces-J,
> Xerces-C and Xerces-P subprojects of the Apache XML project
>
> 2. The initial committers for this project be the existing committers of
> the Xerces-C, Xerces-J and Xerces-P subprojects
>
> 3. The initial PMC members for this project be:
>
> Andy Clark
> Michael Glavassevich
> Neil Graham
> Berin Lautenbach
> Gareth Reakes
> Jason Stewart
>
> thus representing each of Xerces-J, Xerces-C and Xerces-P.
>
> 4. The initial PMC Chairperson be Gareth Reakes.
>
> 5. The mission statement and charter for the new project will be as
> follows:
>
> ================================
> 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 and closely related technologies
> 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 and closely related technologies 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 code base which formed the foundations of both the
> Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
> was originally donated to Apache by IBM in 1999. Xerces-Perl
> came into existence as a subproject of the Apache XML project
> after the Xerces-C++ community had already matured to a
> significant extent. All three were subprojects of the Apache XML
> Project until late 2004. At this time, reflecting the growth in
> the Apache XML project and these communities themselves, Apache
> Xerces became a top-level Project of the Apache Software
> Foundation. Apache Xerces still shares much infrastructure with
> the Apache XML project and the other former 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 composed of a number of subprojects
> which fit into one of two categories:
>
> a) An XML parser implementation in some particular programming
> language. There may be multiple parsers for a given
> language, if the API's the parsers support are sufficiently
> dissimilar. At the time of writing, there is one parser for
> each of Java, C/C++ and Perl.
> b) A set of components serving some purpose not directly
> pertinent to XML parsing, but which are used in related
> applications and are tightly bound, usually through internal
> API's, to one (or more) of the parser subprojects.
>
> 4.4 Product. Some deliverable (usually a binary or source
> package) that a subproject releases to the public. Subprojects
> may have multiple products.
>
> 4.5 Contributor. Anyone who makes a contribution to the development
> of the Apache Xerces project or a subproject.
>
> 4.6 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
> 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.
>
> 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 When a new subproject proposal is submitted to the PMC, it
> may be accepted by a two-thirds vote of the PMC.
>
> 6.2 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 In order to ensure that all code contained in the Apache
> Xerces project's code repository is free of licensing,
> intellectual property and patent issues, any developer wishing
> to contribute a new feature to Xerces must either sign:
>
> a) If contributing as an individual, sign the "Individual
> Contributor License Agreement (CLA)"
> (http://www.apache.org/licenses/icla.txt) and file a copy with
> the Secretary of the Corporation; or
> b) If making the contribution as part of their employment
> responsibilities, sign the "Corporate CLA (CCLA)",
> (http://www.apache.org/licenses/cla-corporate.txt) and file a
> copy with the Secretary of the Corporation.
>
> 7.3 If the contribution in question is a small bugfix, the
> contributor need not sign a CLA, but need only provide the
> following information, attaching it to the communication
> containing the patch:
>
> a) Name and employer
> b) Are you the author of the code being conributed?
> c) Do you have the right to grant the copyright and patent
> licenses for the contribution that are set forth in the ASF v.2.0
> license (http://www.apache.org/licenses/LICENSE-2.0)?
> d) Does your employer have any rights to code that you have
> written, for example, through your contract for employment? If
> so, has your employer given you permission to contribute the code
> on its behalf or waived its rights in the code?
> e) Are you aware of any third-party licenses or other
> restrictions (such as related patents or trademarks) that could
> apply to your contribution? If so, what are they?
>
> 7.4 Contributors 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.
>
> 8.2 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.
>
> 8.3 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.4 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.5 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.
>
> 8.6 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 -- A xerces.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
> 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.
>
> 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; see sections 7.2 and 7.3.
>
> 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 should 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.
>
>
> Neil Graham
> Manager, XML Parser Development
> IBM Toronto Lab
> Phone: 905-413-3519, T/L 969-3519
> E-mail: neilg@ca.ibm.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
Re: [VOTE]: motion to transform Xerces into a top-level project
Posted by Neil Delima <nd...@ca.ibm.com>.
Here's my +1.
Thanks,
Neil.
Neil Graham/Toronto/IBM@IBMCA wrote on 11/14/2004 11:21:54 PM:
> Hello all Xerces developers and XML PMC'ers,
>
> I think we're finally at the point where we can vote to transform Xerces
> into a top-level project of the Apache Software Foundation. The text of
> the motion, to which I give my +1, is as follows:
>
> The Xerces community recommends to the Apache Software Foundation Board
> that:
>
> 1. The top-level Xerces project contain the existing Xerces-J,
> Xerces-C and Xerces-P subprojects of the Apache XML project
>
> 2. The initial committers for this project be the existing committers of
> the Xerces-C, Xerces-J and Xerces-P subprojects
>
> 3. The initial PMC members for this project be:
>
> Andy Clark
> Michael Glavassevich
> Neil Graham
> Berin Lautenbach
> Gareth Reakes
> Jason Stewart
>
> thus representing each of Xerces-J, Xerces-C and Xerces-P.
>
> 4. The initial PMC Chairperson be Gareth Reakes.
>
> 5. The mission statement and charter for the new project will be as
> follows:
>
> ================================
> 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 and closely related technologies
> 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 and closely related technologies 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 code base which formed the foundations of both the
> Xerces-Java and Xerces-C++ subprojects of the Apache XML Project
> was originally donated to Apache by IBM in 1999. Xerces-Perl
> came into existence as a subproject of the Apache XML project
> after the Xerces-C++ community had already matured to a
> significant extent. All three were subprojects of the Apache XML
> Project until late 2004. At this time, reflecting the growth in
> the Apache XML project and these communities themselves, Apache
> Xerces became a top-level Project of the Apache Software
> Foundation. Apache Xerces still shares much infrastructure with
> the Apache XML project and the other former 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 composed of a number of subprojects
> which fit into one of two categories:
>
> a) An XML parser implementation in some particular programming
> language. There may be multiple parsers for a given
> language, if the API's the parsers support are sufficiently
> dissimilar. At the time of writing, there is one parser for
> each of Java, C/C++ and Perl.
> b) A set of components serving some purpose not directly
> pertinent to XML parsing, but which are used in related
> applications and are tightly bound, usually through internal
> API's, to one (or more) of the parser subprojects.
>
> 4.4 Product. Some deliverable (usually a binary or source
> package) that a subproject releases to the public. Subprojects
> may have multiple products.
>
> 4.5 Contributor. Anyone who makes a contribution to the development
> of the Apache Xerces project or a subproject.
>
> 4.6 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
> 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.
>
> 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 When a new subproject proposal is submitted to the PMC, it
> may be accepted by a two-thirds vote of the PMC.
>
> 6.2 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 In order to ensure that all code contained in the Apache
> Xerces project's code repository is free of licensing,
> intellectual property and patent issues, any developer wishing
> to contribute a new feature to Xerces must either sign:
>
> a) If contributing as an individual, sign the "Individual
> Contributor License Agreement (CLA)"
> (http://www.apache.org/licenses/icla.txt) and file a copy with
> the Secretary of the Corporation; or
> b) If making the contribution as part of their employment
> responsibilities, sign the "Corporate CLA (CCLA)",
> (http://www.apache.org/licenses/cla-corporate.txt) and file a
> copy with the Secretary of the Corporation.
>
> 7.3 If the contribution in question is a small bugfix, the
> contributor need not sign a CLA, but need only provide the
> following information, attaching it to the communication
> containing the patch:
>
> a) Name and employer
> b) Are you the author of the code being conributed?
> c) Do you have the right to grant the copyright and patent
> licenses for the contribution that are set forth in the ASF v.2.0
> license (http://www.apache.org/licenses/LICENSE-2.0)?
> d) Does your employer have any rights to code that you have
> written, for example, through your contract for employment? If
> so, has your employer given you permission to contribute the code
> on its behalf or waived its rights in the code?
> e) Are you aware of any third-party licenses or other
> restrictions (such as related patents or trademarks) that could
> apply to your contribution? If so, what are they?
>
> 7.4 Contributors 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.
>
> 8.2 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.
>
> 8.3 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.4 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.5 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.
>
> 8.6 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 -- A xerces.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
> 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.
>
> 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; see sections 7.2 and 7.3.
>
> 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 should 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.
>
>
> Neil Graham
> Manager, XML Parser Development
> IBM Toronto Lab
> Phone: 905-413-3519, T/L 969-3519
> E-mail: neilg@ca.ibm.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>