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. The Polarsys charter describes the goals, vision and governance of Polarsys as well as the membership fees and members rights and duties. 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 "Project Management Committee" of the Eclipse Standard Top-Level Chapter and in "4.6 Leaders" of the Eclipse Development Process.
Beyond these general duties, the Polarsys Top-Level Project Lead(s) is responsible for applying Polarsys Steering Committee's and Architecture Committee's decisions and recommendations about the organization and operations of the Top-Level Project. The Polarsys Top-Level Project Lead(s) also report(s) to them.
Project Planning Committees
Polarsys aims at setting up a strong coordination and collaboration between the various actors of its open source projects. Beyond the usual PMC coordinating the developers, a new mean associating not only the development teams, but also other stakeholders like industrial users or involved researchers is therefore needed: this is the role of the PPC, as defined in the Polarsys charter, section Project Planning Committees.
But in no way PPC replace PMC:
- PMC are connected to one Project or to one Top-Level Project, while PPC are most of the time managing a complete functional stack (e.g. a PPC can take care of a specific modeling stack covered by several PMC).
- PMC are involved in the day to day management of projects, and PPC pay attention to more abstract concerns, like gathering various user's needs (functional needs, but also release deadlines and contents), defining medium/long term development plans, discussing innovation, maintenance, efforts and means, etc.
PPC are a privileged mean for developers to get return of experience from their users. Of course, the involved Project lead(s) are permanent guests in PPC meetings.
Add elements about relationship with Polarsys Steering/Architecture 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]
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
This Charter inherits all terms not otherwise defined herein from the Eclipse Standard Charter v1.1. This includes, but is not limited to, sections on the Program Management Committee, Roles, Project Organization, The Development Process, and Licensing.