| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
| <HTML> |
| <HEAD> |
| <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=windows-1252"> |
| <TITLE>Eclipse Data Tools Project</TITLE> |
| <STYLE> |
| <!-- |
| TD P { margin-left: 0.12in; color: #000000; font-family: "arial", "helvetica", "geneva"; font-size: 10pt } |
| P { margin-left: 0.12in; color: #000000; font-family: "arial", "helvetica", "geneva"; font-size: 10pt } |
| A:link { color: #0000ee } |
| A:visited { color: #551a8b } |
| --> |
| </STYLE> |
| </HEAD> |
| <BODY LANG="en-US" TEXT="#000000" LINK="#0000ee" VLINK="#551a8b" BGCOLOR="#ffffff" DIR="LTR"> |
| <P STYLE="margin-bottom: 0in"> |
| </P> |
| <TABLE WIDTH=100% BORDER=0 CELLPADDING=2 CELLSPACING=5> |
| <TR> |
| <TD WIDTH=60%> |
| <P ALIGN=LEFT><B><FONT SIZE=6><FONT FACE="Verdana, Arial, Helvetica, sans-serif">Data |
| Tools Project</FONT></FONT></B><BR><FONT SIZE=1><FONT FACE="Arial, Helvetica, sans-serif"><FONT COLOR="#8080ff">Project |
| Charter</FONT></FONT></FONT></P> |
| </TD> |
| <TD WIDTH=40%> |
| <P><IMG SRC="DTP_Proposal/Idea.jpg" NAME="Graphic1" ALIGN=MIDDLE HSPACE=50 WIDTH=120 HEIGHT=86 BORDER=0></P> |
| </TD> |
| </TR> |
| </TABLE> |
| <P>This project proposal is in the <A HREF="http://www.eclipse.org/org/documents/Eclipse Development Process 2003_11_09 FINAL.pdf">Proposal |
| Phase</A> and is posted here to solicit community feedback, |
| additional project participation, and ways the project can be |
| leveraged from the Eclipse membership-at-large. You are invited to |
| comment on and/or join the project. Please send all feedback to the |
| <I>dtp_newsgroup</I> or the <I>dtp_mailing_list</I> mailing list.</P> |
| <TABLE WIDTH=100% BORDER=0 CELLPADDING=2 CELLSPACING=0> |
| <COL WIDTH=252*> |
| <COL WIDTH=4*> |
| <TR> |
| <TD COLSPAN=2 WIDTH=100% VALIGN=TOP BGCOLOR="#0080c0"> |
| <P ALIGN=LEFT><FONT COLOR="#ffffff"><FONT FACE="Arial, Helvetica"><B>The |
| Eclipse Data Tools Project Top-Level Project Charter</B></FONT></FONT></P> |
| </TD> |
| </TR> |
| <TR> |
| <TD WIDTH=99%> |
| <P><B>Overview<BR><BR></B>This document describes the composition |
| and organization of the project, roles and responsibilities of the |
| participants, and development process for the project for the Data |
| Tools Project (DTP).</P> |
| <P>DTP starts with key data management frameworks designed both |
| for use and extensibility. These frameworks include location and |
| management of database drivers, and configurations for access to |
| particular database instances. Once a connection is successfully |
| made, the next task often is to explore the database – |
| tables, stored procedures, triggers, and so on – making |
| changes as required. Some of these operations might be carried out |
| by GUI actions, others directly through commands. Users – |
| both developers and administrators – typically will create, |
| edit, and test SQL for these commands. Assistance in editing SQL |
| through code completion, formatting, and dialect specialization, |
| greatly enhances productivity. Further, the ability to execute or |
| debug commands, both SQL and stored procedures, rounds out the |
| rapid development process that Eclipse supports so well. Finally, |
| bridging chasms, whether between relational structures, objects, |
| or XML, presents challenges that data management tooling should |
| address. To meet these needs, DTP includes a broad set of core and |
| tooling components, enabling a diverse set of plug-in offerings |
| specific to particular database technologies and supported by the |
| DTP ecosystem.</P> |
| <P><B>Mission<BR><BR></B>The mission of the Data Tools Project is |
| to build useful tools and a generic, extensible, standards-based |
| tool platform upon which software providers can create |
| specialized, differentiated offerings for developing with and |
| administering database systems.</P> |
| <P><B>Scope<BR><BR></B>The Data Tools Project encompasses a common |
| foundation of frameworks and services for database tooling |
| products. The project scope also includes database tooling |
| products themselves for exemplary purposes and/or to validate the |
| underlying platform.</P> |
| <P>The project will be further limited to providing infrastructure |
| for tooling proper, in contrast to infrastructure related to the |
| application run-time. We will typically use a simple litmus test |
| to set the boundary between tooling and run-time. Application |
| artifacts, once developed, have no execution dependencies on the |
| relevant tooling framework, while the converse would be true for |
| run-time frameworks. In keeping with our objective of maximizing |
| vendor-neutrality, where multiple frameworks exist in the market |
| for a given functional domain, we will develop tooling based on a |
| common abstraction (or superset) to the extent feasible.</P> |
| <P>The ultimate objective of the project is to provide highly |
| reusable and extensible tooling that allows developers to produce |
| applications with increasing development efficiency. The tooling |
| foundation the project will deliver will support these values by |
| enforcing appropriate separations of concern in application |
| architecture, raising the level of technical abstraction in |
| application development and enabling repeatability in development |
| processes. These values, however, will be achieved incrementally |
| over time. Early deliverables will focus on an extensible |
| foundation supporting the most widely used database standards and |
| technologies.</P> |
| <P>In addition, we expect the Data Tools Project to produce |
| functional requirements that are more appropriately satisfied |
| through the Eclipse Project or other Eclipse foundational |
| projects. Areas in which we might expect to see these elaborated |
| requirements would be in working with multi-language support or |
| debugging procedures on remote database servers. In such case, the |
| Data Tools Project PMC will coordinate the corresponding Project |
| PMCs the design and implementation of the corresponding |
| contribution.</P> |
| <P>The Data Tools area is a vast domain, yet there are a fairly |
| small number of foundational requirements for developing with and |
| administering database systems. Similar to all tooling, users |
| expect a consistent, highly usable environment that is easy to |
| configure - a tool set in which the challenges of application |
| development are due to the inherent challenges of the problem |
| domain, not to the complexity of the tools themselves. As such, |
| the top-level project initially has six projects divided into two |
| major areas: Basic Connectivity and Data-centric Development. |
| </P> |
| <P>In the Basic Connectivity area, the Data Tools Project |
| initially has three projects: Database Connectivity, SQL |
| Development Tools, and Database Administration. In the |
| Data-centric Development area, the Data Tools Project has an |
| additional three initial projects: Object/Relational Mapping, |
| XML/Relational Mapping, and Extract-Transform-Load. The goal is to |
| provide frameworks with well-defined APIs and extension points, as |
| well as exemplary implementations targeted at well-known open |
| source runtime environments while enabling an ecosystem of |
| complementary open source and commercial projects to create |
| components specialized to particular databases. Additional |
| projects related to DTP will be added as community interest |
| demands, and resources become available.</P> |
| <P><I>Database Connectivity</I></P> |
| <P>The Database Connectivity project consists of core frameworks |
| and components for data tooling including: Driver Management, |
| Connection Profile Framework, and Database Explorer. Access to the |
| appropriate database drivers is a prerequisite for programmatic |
| interaction with databases. The Driver Management Framework (DMF) |
| supplies an Eclipse preference page enabling users to create |
| driver definitions based on supplied templates. The Connection |
| Profile Framework (CPF) is the foundation upon which specific |
| connection types are created. The connection types, called |
| “Connection Profiles” (CP), are contributed to the CPF |
| through extension points. The CPs are the connection providers |
| through which other DTP tooling accesses database instances. The |
| Database Explorer (DE) is an Eclipse view for browsing CP |
| instances: databases, tables, stored procedures, drag and drop |
| data, and so on - constrained only by the CP itself.</P> |
| <P><I>SQL Development Tools</I></P> |
| <P>The SQL Development Tools (SDT) project provides a development |
| environment similar to Eclipse JDT by leverages the Database |
| Connectivity frameworks to edit, execute, and debug procedural |
| objects (stored procedures, triggers and functions) and SQL |
| statements. The project consists of an SQL Editor Framework and an |
| SQL Execution and Debugger Framework.</P> |
| <P><I>Database Administration</I></P> |
| <P>This Database Administration project provides a framework to |
| support generic administration functionality. This project |
| encompasses administration tools for tasks such as database |
| creation and DDL support; schema generation, reverse engineering |
| and migration; data loading and unloading; performance monitoring, |
| analysis and tuning; etc. Additionally, the tooling supports SQL |
| execution plans which are vital for database tuning.</P> |
| <P><I>Object/Relational Mapping</I></P> |
| <P>The Data Tools project will work with the Eclipse |
| membership-at-large to select ORM base technologies and then |
| create supporting tools that are integrated with the DTP base. |
| </P> |
| <P><I>XML/Relational Mapping </I> |
| </P> |
| <P>The prevalence and importance of XML in modern application |
| development necessitates XML/Relational Mapping (XRM) tools . The |
| Data Tools project will work with the Eclipse membership-at-large |
| to provide both key and supporting XRM components.</P> |
| <P><I>Extract-Transform-Load </I> |
| </P> |
| <P>A very common developer requirement is to load and transfer |
| data between databases, either straight across or in the complex |
| domain of transforming the data. The Data Tools project will |
| provide core components and exemplary tools in this area. We |
| anticipate that specialized extract and load endpoints will be key |
| areas of community and ecosystem extensions to the Data Tools |
| Project.</P> |
| <P>In the spirit of Eclipse, the Data Tool Project components will |
| be vendor neutral, the development process agile, and community |
| involvement level will be fostered to provide a rich ecosystem |
| benefiting the entire Eclipse membership-at-large. Expanding the |
| project to include new projects will require a revision to this |
| charter as per the Eclipse Development Process.</P> |
| <P><B>Project Management Committee<BR></B><BR>The Projects under |
| this Charter are managed by a group known as the Project |
| Management Committee (the "PMC").<BR><BR>PMCs are |
| expected to ensure that: |
| </P> |
| <UL> |
| <LI><P STYLE="margin-bottom: 0in">All Projects operate |
| effectively by providing leadership to guide the Project's |
| overall direction and by removing obstacles, solving problems, |
| and resolving conflicts. |
| </P> |
| <LI><P STYLE="margin-bottom: 0in">All Project plans, technical |
| documents and reports are publicly available. |
| </P> |
| <LI><P>All Projects operate using open source rules of |
| engagement: meritocracy, transparency, and open participation. |
| These principles work together. Anyone can participate in a |
| Project. This open interaction, from answering questions to |
| reporting bugs to making code contributions to creating designs, |
| enables everyone to recognize and utilize the contributions. |
| </P> |
| </UL> |
| <P>The PMC has the following responsibilities:</P> |
| <UL> |
| <LI><P STYLE="margin-bottom: 0in">Providing the leadership and |
| vision to guide the Project's overall direction in a manner |
| consistent with the Eclipse Foundation Architectural Roadmap. |
| </P> |
| <LI><P STYLE="margin-bottom: 0in">Providing assistance and |
| support to the developers and researchers working on the Project |
| by removing obstacles, solving problems, and resolving conflicts. |
| </P> |
| <LI><P STYLE="margin-bottom: 0in">Ensuring that Project plans are |
| produced. |
| </P> |
| <LI><P STYLE="margin-bottom: 0in">Recommending new Projects to |
| the EMO. |
| </P> |
| <LI><P STYLE="margin-bottom: 0in">Recommending the initial set of |
| Project committers for each new Project overseen by the PMC, and |
| establishing the procedures consistent with this Charter for |
| voting in new committers. |
| </P> |
| <LI><P STYLE="margin-bottom: 0in">Helping to ensure that the |
| Projects overseen by the PMC have enough contributors, and |
| working to fill vacancies in roles. |
| </P> |
| <LI><P STYLE="margin-bottom: 0in">Producing "how to get |
| involved" guidelines to help new potential contributors get |
| started. |
| </P> |
| <LI><P STYLE="margin-bottom: 0in">Coordinating relationships with |
| other Eclipse Foundation Projects. |
| </P> |
| <LI><P STYLE="margin-bottom: 0in">Facilitating code or other |
| donations by individuals or companies. |
| </P> |
| <LI><P STYLE="margin-bottom: 0in">Making recommendations to the |
| Eclipse Foundation Board regarding contributions proposed under |
| licenses other than the EPL. |
| </P> |
| <LI><P STYLE="margin-bottom: 0in">Working with the EMO and |
| Committers to ensure in-bound contributions are made in |
| accordance with the Eclipse Foundation IP Policy. |
| </P> |
| <LI><P>Acting as a focal point for the community in representing |
| the Projects it oversees. |
| </P> |
| </UL> |
| <P>The PMC Lead is appointed by the Board. The initial PMC is |
| selected by the PMC Lead. Thereafter, to become a member of the |
| PMC, an individual must be nominated by another member of the PMC, |
| and unanimously approved by all PMC members. |
| </P> |
| <P>In the unlikely event that a member of the PMC becomes |
| disruptive to the process or ceases to contribute for an extended |
| period, the member may be removed by unanimous vote of remaining |
| PMC members. PMC members may resign at any time by delivering |
| notice of their resignation to the PMC Lead. |
| </P> |
| <P>The PMC is responsible for producing and maintaining the |
| Project Charter. Development must conform to any rules or |
| processes outlined in the Charter, so a change to the development |
| process may necessitate a change to the Charter. Changes to the |
| Charter are approved by the Board. |
| </P> |
| <P>The work of the PMC is shared by the PMC members. All PMC |
| members are expected to contribute actively. In particular, PMC |
| members are expected to take responsibility for overseeing certain |
| areas of work in the Project, and reporting to the PMC on these |
| areas. |
| </P> |
| <P>Active participation in the user newsgroups and the appropriate |
| developer mailing lists is a responsibility of all PMC members, |
| and is critical to the success of the Project. PMC members are |
| required to monitor the main Project mailing list, and the |
| developer mailing lists for all Projects and components they are |
| overseeing. |
| </P> |
| <P><B>Requirements Group</B></P> |
| <P>The Requirements Group is formed at the discretion of the PMC. |
| The Requirements Group gathers requirements for the project and |
| communicates them to all members of the Project, including the |
| PMC. The Requirements Group will accomplish its objectives by |
| working closely with the development teams and the PMC. |
| </P> |
| <P><B>Architecture Group</B></P> |
| <P>The Architecture Group is formed at the discretion of the PMC. |
| The Architecture Group is responsible for development, |
| articulation and maintenance of the Project Architecture, as well |
| as for providing an explicit description of the architecture and |
| communicating this description to all members of the Project, and |
| for releasing it as part of the project deliverables. The |
| Architecture Group will accomplish its objectives by working |
| closely with the development teams and the PMC. |
| </P> |
| <P><B>Project Planning Group</B></P> |
| <P>The Planning Group is formed at the discretion of the PMC. The |
| Planning Group assists the PMC in establishing the Project plan in |
| conjunction with available Project resources, coordinating |
| relationships between Project participants and with other Eclipse |
| projects. The Planning Group helps to ensure that projects have |
| enough contributors, filling vacancies in roles and facilitating |
| code or other donations by individuals or companies. The Planning |
| Group will accomplish its objectives by working closely with the |
| development teams and the PMC. |
| </P> |
| <P><B>Roles<BR></B><BR>The Projects under this Charter are |
| operated as meritocracies -- the more you contribute, and the |
| higher the quality of your contribution, the more you are allowed |
| to do. However with this comes increased responsibility. |
| </P> |
| <P><I>Users</I><BR>Users are the people who use the products that |
| the Project produces. People in this role aren't contributing |
| code, but they are using the products, reporting bugs, and making |
| feature requests and suggestions. Users are encouraged to |
| participate through the user newsgroup(s), asking questions, |
| providing suggestions, and helping other users. Users are also |
| encouraged to report problem reports using the bug tracking |
| system. |
| </P> |
| <P><I>Developers</I><BR>Users who contribute code or documentation |
| become developers. Developers are the people who contribute code, |
| fixes, documentation, or other work that goes into the product. |
| Developers are also encouraged to participate in the user |
| newsgroup(s), and should monitor the developer mailing list |
| associated with their area of contribution. When appropriate, |
| developers may also contribute to development design discussions |
| related to their area of contribution. Developers are expected to |
| be proactive in reporting problems in the bug tracking system. |
| </P> |
| <P><I>Committers</I><BR>Developers who give frequent and valuable |
| contributions to a Project, or component of a Project (in the case |
| of large Projects), can have their status promoted to that of a |
| "Committer" for that Project or component respectively. |
| A Committer has write access to the source code repository for the |
| associated Project (or component), and gains voting rights |
| allowing them to affect the future of the Project (or component). |
| </P> |
| <P>In order for a Developer to become a Committer on a particular |
| Project overseen by the PMC, another Committer for the same |
| Project (or component as appropriate) can nominate that Developer |
| or the Developer can ask to be nominated. Once a Developer is |
| nominated, the Committers for the Project (or component) will |
| vote. If there are at least 3 positive votes and no negative |
| votes, the Developer is recommended to the PMC for commit |
| privileges. If the PMC also approves and the Developer signs the |
| Committer Agreement established by the EMO (wherein, at the very |
| least, the Developer agrees to abide by the Eclipse Intellectual |
| Property Policy), the Developer is converted into a Committer and |
| given write access to the source code repository for that Project |
| (or component). Becoming a Committer is a privilege that is earned |
| by contributing and showing discipline and good judgment. It is a |
| responsibility that should be neither given nor taken lightly. |
| </P> |
| <P>At times, Committers may go inactive for a variety of reasons. |
| The decision making process of the Project relies on active |
| committers who respond to discussions and votes in a constructive |
| and timely manner. The PMC is responsible for ensuring the smooth |
| operation of the Project. A Committer that is disruptive, does not |
| participate actively, or has been inactive for an extended period |
| may have his or her commit status removed by the PMC. |
| </P> |
| <P>Active participation in the user newsgroup and the appropriate |
| developer mailing lists is a responsibility of all Committers, and |
| is critical to the success of the Project. Committers are required |
| to monitor and contribute to the user newsgroup. |
| </P> |
| <P>Committers are required to monitor the developer mailing list |
| associated with all Projects and components for which they have |
| commit privileges. This is a condition of being granted commit |
| rights to the Project or component. It is mandatory because |
| committers must participate in votes (which in some cases require |
| a certain minimum number of votes) and must respond to the mailing |
| list in a timely fashion in order to facilitate the smooth |
| operation of the Project. When a Committer is granted commit |
| rights they will be added to the appropriate mailing lists. A |
| Committer must not be unsubscribed from a developer mailing list |
| unless their associated commit privileges are also removed. |
| </P> |
| <P>Committers are required to track, participate in, and vote on, |
| relevant discussions in their associated Projects and components. |
| There are three voting responses: +1 (yes), -1 (no, or veto), and |
| 0 (abstain). |
| </P> |
| <P>Committers are responsible for proactively reporting problems |
| in the bug tracking system, and annotating problem reports with |
| status information, explanations, clarifications, or requests for |
| more information from the submitter. Committers are responsible |
| for updating problem reports when they have done work related to |
| the problem. |
| </P> |
| <P><B>Projects<BR></B><BR>The work under this Top Level Project is |
| further organized into Projects. New Projects must be significant |
| works consistent with the mission of the Top Level Project, be |
| recommended by the PMC, and confirmed by the EMO. Projects can be |
| discontinued by decision of the Board. |
| </P> |
| <P>When a new Project is created, the PMC nominates a Project lead |
| to act as the technical leader and nominates the initial set of |
| Committers for the Project, and these nominations are approved by |
| the EMO. Project leads are accountable to the PMC for the success |
| of their Project. |
| </P> |
| <P><B>Project Components</B> |
| </P> |
| <P>The PMC may decide to divide a Project further into components. |
| If a Project is divided into components, commit privileges are |
| normally granted at the component level, and the committers for a |
| given component vote on issues specific to that component. |
| Components are established and discontinued by the PMC. When the |
| PMC creates a component it appoints a component lead to act as the |
| technical leader and names the initial set of Committers for the |
| component. The component lead is designated as a committer for the |
| Project and represents the component in discussions and votes |
| pertaining to the Project as a whole. Component Committers do not |
| participate in votes at the level of the Project as a whole, |
| unless they are also the component lead. |
| </P> |
| <P><B>Ports<BR></B><BR>For components that contain |
| platform-specific code, it may be advantageous to allow developers |
| to work on a port of the component to a new platform without |
| requiring that they already be committers for the component. In |
| this case the main code base is known as the component "core", |
| and the port code base is known as a component "port". |
| The decision to set up a port is made by the PMC. When a new port |
| of a component is created, the PMC appoints a Port Lead, and an |
| initial set of committers who will have commit and voting |
| privileges specifically for the port. The port is done under the |
| auspices of the core component, and all committers for the core |
| component automatically also have commit and voting privileges on |
| the port. Normally the Component Lead will also be the Port Lead.</P> |
| <P><B>Coordinated Release Cycles<BR></B><BR>All projects and |
| components under this Project will have coordinated release plans, |
| milestone dates, freeze cycles, builds, and ship dates. These |
| projects will be coordinated by a group consisting of the project |
| leads, the component leads from these projects, and the members of |
| the PMC assisted by the members of the Planning Committee. |
| </P> |
| <P><B>Infrastructure<BR></B><BR>The PMC works with the EMO to |
| ensure the required infrastructure for the Project. The Project |
| infrastructure will include, at minimum: |
| </P> |
| <UL> |
| <LI><P STYLE="margin-bottom: 0in">Bug Database - Bugzilla-like |
| database for tracking bugs and feature requests. |
| </P> |
| <LI><P STYLE="margin-bottom: 0in">Source Repository - One or more |
| CVS repositories containing both the master source code and |
| documentation for the projects. |
| </P> |
| <LI><P STYLE="margin-bottom: 0in">Website - A Web site will |
| contain information about the project, including documentation, |
| downloads of releases, and this charter. |
| </P> |
| <LI><P STYLE="margin-bottom: 0in">General Mailing List - Mailing |
| list for development discussions pertaining to the project as a |
| whole or that cross projects. This mailing list is open to the |
| public. |
| </P> |
| <LI><P STYLE="margin-bottom: 0in">Project Mailing Lists - |
| Development mailing list for technical discussions and committer |
| voting related to the project. These mailing lists are open to |
| the public. |
| </P> |
| <LI><P STYLE="margin-bottom: 0in">Component Mailing Lists - |
| Development mailing list for technical discussions and committer |
| voting related to the component. This mailing list is open to the |
| public. |
| </P> |
| <LI><P>Newsgroup - A newsgroup where users, developers, and |
| committers can interact regarding general questions and issues |
| about the project. |
| </P> |
| </UL> |
| <P><B>Development Process<BR></B><BR>Each Project lead must |
| produce a development plan for the release cycle, and the |
| development plan must be approved by the PMC and by a majority of |
| Committers of the Project. |
| </P> |
| <P>Each Project must identify, and make available on its web site, |
| the requirements and prioritizations it is working against in the |
| current release cycle. In addition, each Project must post a |
| release plan showing the date and content of the next major |
| release, including any major milestones, and must keep this plan |
| up to date. |
| </P> |
| <P>The Committers of a Project or component decide which changes |
| may be committed to the master code base of a Project or component |
| respectively. Three +1 ('yes' votes) with no -1 ('no' votes or |
| vetoes) are needed to approve a code change. Vetoes must be |
| followed by an explanation for the veto within 24 hours or the |
| veto becomes invalid. All votes are conducted via the developer |
| mailing list associated with the Project or component. |
| </P> |
| <P>Special rules may be established by the PMC for Projects or |
| components with fewer than three Committers. For efficiency, some |
| code changes from some contributors (e.g. feature additions, bug |
| fixes) may be approved in advance, or approved in principle based |
| on an outline of the work, in which case they may be committed |
| first and changed as needed, with conflicts resolved by majority |
| vote of the Committers of the Project or component, as applicable. |
| More restrictive rules for releasing changes may be established by |
| the PMC near the end of release cycles or for maintenance streams. |
| </P> |
| <P>The master copy of the code base must reside on the Project web |
| site where it is accessible to all users, developers and |
| committers. Committers must check their changes and new work into |
| the master code base as promptly as possible (subject to any |
| check-in voting rules that may be in effect) in order to foster |
| collaboration among widely distributed groups and so that the |
| latest work is always available to everyone. The PMC is |
| responsible for working with the Eclipse Foundation to establish a |
| release engineering and build process to ensure that builds can be |
| reliably produced on a regular and frequent basis from the master |
| code base and made available for download from the Project web |
| site. |
| </P> |
| <P>The PMC is responsible for establishing the level of testing |
| appropriate for each Project, and approving the test plans. |
| </P> |
| <P>All development technical discussions are conducted using the |
| development mailing lists. If discussions are held offline, then a |
| summary must be posted to the mailing list to keep the other |
| committers informed. |
| </P> |
| <P><B>Licensing<BR></B><BR>All contributions to Projects under |
| this Charter must adhere to the Eclipse Foundation Intellectual |
| Property Policy.</P> |
| <P> </P> |
| </TD> |
| <TD WIDTH=1% VALIGN=TOP></TD> |
| </TR> |
| </TABLE> |
| <P><BR><BR> |
| </P> |
| </BODY> |
| </HTML> |
