This document defines standard terms for Eclipse Top Level Project Charters. It is intended that the Charters for Top Level Projects reference this document rather than inheriting by copy-and-paste.
Polarsys is an Industry Working Group created in the framework of the Eclipse Foundation to address specific needs for the development and long-term availability of tools in the context of the architecture and development of critical and embedded systems.
As stated in the section about Component Management of Polarsys in the Charter, Polarsys will either:
- reference existing Open Source projects (available as plain Eclipse projects from the Eclipse Foundation or even other OSS projects),
- or host more specific Open Source projects on the Polarsys infrastructure.
The Polarsys Top Level Project is the umbrella under which the specific Polarsys components and technologies will be hosted.
Of course, the mission of Polarsys is not to gather any new technologies that could be eventually applied to Embedded System design and development. Components with a larger potential audience than critical and embedded systems will be directed to the most relevant Eclipse project instead. For example, some components from the Eclipse Modeling Project like Papyrus, Acceleo or other components like the CDT are very important components for Polarys. But they will neither move nor be duplicated into Polarsys. Some complementary assets (specific functional tests, extra documentation, etc.) may nevertheless be hosted in Polarsys if needed.
It is noteworthy that the Polarsys TLP will host projects licensed either under the EPL or any other licenses approved by the IWG and the Eclipse Foundation Board of Directors, such as BSD-like and LGPL. See the Licensing section of this proposal.
The Polarsys projects and components are organized according to a two-level architecture.
- Polarsys Technology Level (PTL): this level contains projects and components with a technical scope, such as domain management (e.g., persistence, collaborative work), transformation technology (e.g., model transformation, reverse engineering, refactoring), or interoperability.
- Polarsys Engineering Level (PEL): this level contains projects and components with a system, software or hardware engineering scope, such as requirement engineering, change management, simulation, architecture, or IVV (integration, verification, validation).
Companies or communities of interest can complete the Polarsys Engineering Level by a Business Level composed of business-specific components.
Polarsys adds a cross level:
- Polarsys Service Framework (PSF): this level contains all the projects and components to develop Polarsys services, such as release engineering for building Polarsys components or the definition of the Polarsys quality kits. This level is positioned upon the Eclipse infrastructure which provides services standard or adapted to Polarsys (e.g., Hudson/Buckminister for continuous integration, Bugzilla for change management, file download, mailing list).
Project Management Committee
The Projects under this Charter are managed by a group known as the Project Management Committee (the "PMC"). The PMC's duties are described in "4.6 Leaders" of the Eclipse Development Process. 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. Because of the diversity amongst individual projects, PMC members are not expected to maintain anything other than general currency with projects outside their assigned technical areas. 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.
[Maurice Heitz] this text should be reworked, it seems to me related to projects (see project organisation), rather than to TLP? Why not create a TLP Management Committee and describe the dedicated management activities (ontop and separated from project management activities) [Pierre Gaufillet] I guess the TLP should be managed by the steering committee and/org the architecture board.
Project Planning Committees
Explain their role and how they interact with the PMC. [Pierre Gaufillet]
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.
Users are the people who use the output from the Project. Output will typically consist of software in form of extensible frameworks and exemplary tools. Software in this context means intellectual property in electronic form, including source and binary code, documentation, courseware, reports and whitepapers.
Users who contribute software, documentation, or other materially useful content become developers. Developers are 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.
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. See "4.7 Committers and Contributors" of the Eclipse Development Process for the process and responsibilities that entails. At times, Committers may become inactive for a variety of reasons. The decision making process of the Project relies on active committers who respond to discussions and vote in a constructive and timely manner. The PMC is responsible for ensuring the smooth operation of the Project. A Committer who is disruptive, does not participate actively, or has been inactive for an extended period may have his or her commit status revoked by the PMC. 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. Committers are required to monitor the mailing lists 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 revoked. 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). 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.
The work under this Top Level Project is further organized into Projects. New Projects must be consistent with the mission of the Top Level Project, be recommended by the PMC, and confirmed by the EMO. Projects can be discontinued by recommendation of the PMC, and confirmed by the EMO. 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.
Given the fluid nature of Eclipse Projects, organizational changes are possible, in particular: dividing a Project into components; dividing a Project into two or more independent Projects; and merging two or more Projects into a single Project. In each case, the initiative for the change may come either from within the Project or from the PMC, but the PMC must approve any change, and approval must be confirmed by the EMO. If a Project wishes to divide 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. In cases where new Projects are being created, either by splitting or by merging, the usual procedures as set forth in this Charter are followed. In particular, developers will not necessarily have the same rights after an organizational change that they enjoyed in the previous structure.
As Is. Add elements about relationship with Polarsys Steering Committee.[Pierre Gaufillet]
The PMC works with the EMO to ensure the required infrastructure for the Project. The Project infrastructure will include, at minimum: Bug Database - Bugzilla database for tracking bugs and feature requests. Source Repository -- One or more CVS repositories containing all the software for the Projects. Website - A website will contain information about the Project, including documentation, reports and papers, courseware, downloads of releases, and this Charter. General Mailing List - Mailing list for discussions pertaining to the Project as a whole or that cross Projects. This mailing list is open to the public. Project Mailing Lists - Mailing list for technical discussions related to the Project. This mailing list is open to the public. Component Mailing Lists - Mailing list for technical discussions related to the component. This mailing list is open to the public. Newsgroups - Newsgroups where users, developers, and committers can interact regarding general questions and issues about the project. The newsgroup is open to the public.
Add here specific Polarsys infrastructure : catalog, quality assessment, functional testing, VLTS.[Raphaël Faudou] Couldn't we have a special project dedicated to the infrastructure support of projects [Maurice Heitz]
The Development Process
The development process of the Polarsys project conforms to the standard project development process described here.
All contributions to Projects under this Charter must be done according to the Eclipse Foundation's IP due diligence process in order to provide clean open source software released under EPL or any other licenses approved by the IWG Steering Committee and the Eclipse Foundation Board of Directors.
As of this proposal, the list of accepted licenses includes the EPL, BSD-like licenses like the Apache License and the LGPL.
Glossary of Terms
- CDT Eclipse C/C++ Development Tooling
- EMO Eclipse Management Organisation
- IWG Industry Working Group
- PMC Project Management Committee
- PSF Polarsys Service Framework
- PSC Polarsys Sterring Committee
- PTL Polarsys Technology Level : projects and components with a technical scope, such as transformation technology or interoperability.
- PEL Polarsys Engineering Level :projects and components with a system, software or hardware engineering scope
- TLP Top Level Project
- TLPP TLP Proposal
- VLTS Very Long Term Support