Re: [VOTE]: motion to transform Xerces into a top-level project as a member of the "federation" of XML projects
Neil Graham <[email protected]>
| Newsgroups | gmane.text.xml.general |
|---|---|
| Message-ID | <OFAB212882.2EC5B1E5-ON85256E9B.0061B324__20061.1093933277$1085164099@ca.ibm.com> |
Hi Andy and all, I've now rolled some of the points that we seem to have consensus on into the original charter I suggested back at the beginning of April. I've posted it on the Wiki page [*] where Berin had kindly placed his reworking of that document. I'm also attaching a diff of my original suggestion to the modified one, in case that makes review easier for people: (See attached file: charter-changes.txt) If we can get agreement on that, then I for one would be cool for actually voting on the resolution Berin drafted for us (which I've included below, with a few modifications, chief among them an attempt at specifying the composition of the PMC based on who it seems to me are the active committers these days). I haven't tried to fill in the field for PMC Chair though. :) As always, feedback more than appreciated! Cheers, Neil [*]: http://nagoya.apache.org/wiki/apachewiki.cgi?XMLProjectPages/XercesCharterDiscussion ************* Draft Motion on Xerces ************** WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to XML parsers, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Xerces PMC", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Xerces PMC be and hereby is responsible for the creation and maintenance of open-source software related to XML parsing and closely related technologies based on software licensed to the Foundation; and be it further RESOLVED, that the office of "Vice President, Xerces" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Xerces PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Xerces PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Xerces PMC: * Neeraj Bajaj <[email protected]> * James Berry <[email protected]> * Andy Clark <[email protected]> * Sandy Gao <[email protected]> * Michael Glavassevich <[email protected]> * Neil Graham <[email protected]> * Kohsuke Kawaguchi <[email protected]> * Elena Litani <[email protected]> * Alberto Massari <[email protected]> * Khaled Noaman <[email protected]> * K.Venugopal Rao <[email protected]> * Gareth Reakes <[email protected]> * Jason Stewart <[email protected]> * PeiYong Zhang <[email protected]> NOW, THEREFORE, BE IT FURTHER RESOLVED, that REPLACE WITH CHAIR be and hereby is appointed to the office of Vice President, Xerces, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Xerces PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Xerces Project; and be it further RESOLVED, that the initial Xerces PMC be and hereby is tasked with the migration and rationalization of the Apache XML PMC Xerces subproject; and be it further RESOLVED, that all responsibility pertaining to the XML Xerces sub-project and encumbered upon the Apache XML PMC are hereafter discharged. Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [email protected] Andy Clark <[email protected] To: [email protected] et> cc: [email protected], [email protected], [email protected] Subject: Re: [VOTE]: motion to transform Xerces into a top-level project as a member 05/12/2004 01:44 of the "federation" of XML projects PM Please respond to pmc Neil Graham wrote: >>So "Xerces" would be the project whereas "Xerces-J" would >>be a product release of Xerces in Java. An example sub-project >>would be "HTML" which, again, would have products based on the >>implementation language. They would be bundled together for >>organizational reasons, not for releases. > > Conceptually, the only difficulty I'd have with this is that it's no longer > crystal clear what the commonality between the subprojects is. I'd thought It's not clear to *you*, is what you mean. It's perfectly clear to me. ;) > that the "Xerces" TLP would be all about Apache's offerings related > specifically to XML parsing first, and perhaps very closely related > technologies second. That sounds exactly like what I'm proposing through my use of the terms "project" and "sub-project". Parsing is the project and things related to parsing are sub-projects. Products is the way that the implementations are separated from each other within the project. So someone comes to the website looking for XML parsers and they go the the Xerces Project. Then they decide what language they need, Java, so they download the Xerces-J product. Next, they want to be able to parse HTML, so they look at the Xerces HTML sub-project. There they see that there is an implementation in Java for use with the XML parser they just downloaded. In this situation, of course there are things that need to be broken out of Xerces-J as it stands today. But once that is done, they are each developed and packaged separately. It's primarily the website organization that reflects the hierarchy and relationships between these separate things. >>I'm specifically trying to organize the Xerces TLP so that >>I can formally donate NekoHTML to the Xerces project for the >>Xerces-J product. > > I'd been guessing that. :) I'm asked on a regular basis if/when it will be merged into Xerces-J so this is a perfect opportunity to do that. > * project: the top level project (TLP), charged with XML parsing > and closely allied technologies > * sub-project: either > o an XML parser implementation in a particular language, or > o a "tools" subproject containing useful products that are > tightly bound, usually by nonstandard API's, to one of the other > subprojects But this puts dependent products at the same level as the parser. You would think they would be *under* the parser because of the dependency. > The tools subproject could contain products from as many languages as there > were parsers. I'm also fine with removing the restriction that we have one > parser per language; we may want a Xerces-J-Pull at some point. Well, that was certainly one of my biggest problems with the original draft. > Once again, I'd love to call on other folks from Xerces-land. Andy and I > are having a good time talking among ourselves, but it's tough to gauge the > consensus of a community when you only ever hear two voices... It does seem rather quiet around here. I'm surprised that noone else has added their ideas to the discussion. Perhaps they're scared of me. ;) -- Andy Clark * [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
charter-changes.txt
(application/octet-stream, 7.5 KB)
--- charter-original.txt 2004-05-21 13:33:40.899953800 -0400
+++ charter.txt 2004-05-21 13:38:17.970731800 -0400
@@ -2,8 +2,8 @@
==============
1.1 Apache Xerces is a collaborative software development project
dedicated to providing robust, full-featured, commercial-quality, and
-freely available XML parsers on a wide variety of platforms supporting
-several languages. This
+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
@@ -20,7 +20,7 @@
knowledge. The ability to transform raw data into usable information
has great potential to improve the functionality and use of
information systems. We intend to build freely available XML
-parsers in order to engender such improvements.
+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).
@@ -50,10 +50,11 @@
=========
3.1 The Apache Xerces project was originally part of the Apache XML Project.
In early 2004, reflecting the growth both in the Apache
-XML project and in Apache Xerces, Apache Xerces became a formal
-project of the Apache Software Foundation. However, Apache Xerces still
+XML project and in Apache Xerces, Apache Xerces became a top-level
+Project of the Apache Software Foundation. However, Apache Xerces still
shares much infrastructure with the Apache XML project and the
-other subprojects of Apache XML that have become projects in their own right.
+other former subprojects of Apache XML that have become projects in
+their own right.
4 TERMS
=======
@@ -63,14 +64,26 @@
4.2 The Project. The Apache Xerces Project; intended
to refer to the source code, website and community that are Apache Xerces.
-4.3 Subproject. Apache Xerces is comprised of a number of subprojects,
-corresponding to each of the languages for which a parser has been
-produced. Currently, there are parsers for Java, C/C++ and Perl.
+4.3 Subproject. Apache Xerces is comprised of a number of subprojects
+which fit into one of two categories:
-4.4 Contributor. Anyone who makes a contribution to the development
+a) An XML parser implementation in some particular programming
+ language. There may 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) Componentry that is not an XML parser, but involves related
+ applications and is tightly bound, usually through internal
+ API's, to one 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.5 Committer. Apache Xerces has a set of committers. Committers
+4.6 Committer. Apache Xerces has a set of committers. Committers
are contributors who have read/write access to the source code
repository.
@@ -139,13 +152,10 @@
6 SUBPROJECTS
=============
-6.1 Apache Xerces is composed of subprojects; a subproject is
-responsible for an XML parser implementation in a particular language.
-
-6.2 A new subproject proposal is submitted to the PMC, and then accepted
-by a two-thirds vote.
+6.1 When a new subproject proposal is submitted to the PMC, it
+may be accepted by a two-thirds vote of the PMC.
-6.3 A subproject may be removed by unanimous vote of the PMC, subject to the
+6.2 A subproject may be removed by unanimous vote of the PMC, subject to the
approval of the ASF board.
7 CONTRIBUTORS
@@ -164,14 +174,18 @@
have read/write access to the source code repository. New committers
are added when a contributor is nominated by a committer, approved by
at least 50 percent of the active committers for that subproject with no
-opposing votes, and files a signed Contributor License Agreement with the Secretary of the Corporation. In most cases, new committers will already be participating in the development process by submitting suggestions
-and/or fixes via the bug report page or mailing lists.
+opposing votes, and files a signed Contributor License Agreement
+with the Secretary of the Corporation. In most cases, new
+committers will already be participating in the development
+process by submitting suggestions and/or fixes via the bug report
+page or mailing lists.
8.2 Although committers have write access to all Apache Xerces subprojects,
they are only permitted to make changes to the subprojects to which they
have been elected committers. A committer may be elected to multiple
-subprojects, but, except that no new access need be granted,
-the process is the same as for any other contributor.
+subprojects, but, except that no new access need be grantedand
+the CLA need not be updated, the process is the same as for any
+other contributor.
8.3 For the purposes of voting, committers will be classed as "active" or
"inactive". Only active committers will be included in the totals used to
@@ -189,8 +203,8 @@
8.5 An inactive status will not prevent a committer committing new code
changes or posting to the mailing lists. Either of these activities will
-automatically re-activate the committer for the purposes of voting, and necessitate
-their addition to the PMC mailing list.
+automatically re-activate the committer for the purposes of
+voting, and necessitate their addition to the PMC mailing list.
9 INFRASTRUCTURE
================
@@ -229,18 +243,22 @@
same terms. All contributed files must contain the full text of the ASF
Source Code License.
-10.2 When a committer is considering integrating a contribution from a contributor who has no CLA on file with the Corporation, it is the responsibility of the committer, in consultation with the PMC, to conduct due diligence on the pedigree of the contribution under consideration.
+10.2 When a committer is considering integrating a contribution
+from a contributor who has no CLA on file with the Corporation,
+it is the responsibility of the committer, in consultation with
+the PMC, to conduct due diligence on the pedigree of the
+contribution under consideration.
11 THE DEVELOPMENT PROCESS
==========================
11.1 The development process is intentionally lightweight; like other
Apache projects, the committers decide which changes may be committed
to the repository. Three +1 ('yes' votes) with no -1 ('no' votes or
-vetoes) are needed to approve a significant code change. For efficiency, some code
-changes from some contributors (e.g. feature additions, bug fixes) may
-be approved in advance, in which case they may be committed first and
-changed as needed, with conflicts resolved by majority vote of the
-committers.
+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
==========================