Jump to: navigation, search

Difference between revisions of "Polarsys/TLPProposal"

(Project Management Committee)
(Scope)
 
(43 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= ''DRAFT''  =
 
 
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.
 
 
 
== Overview  ==
 
== Overview  ==
[http://www.polarsys.org Polarsys] is an [http://www.eclipse.org/org/industry-workgroups/industry_wg_process.php Industry Working Group] created in the framework of the [http://www.eclipse.org 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 [http://www.eclipse.org/org/industry-workgroups/polarsys_charter.php Polarsys charter] describes the goals, vision and [http://www.eclipse.org/org/industry-workgroups/polarsys_charter.php#Governance_and_Precedence governance] of Polarsys as well as the [http://www.eclipse.org/org/industry-workgroups/polarsys_charter.php#Membership membership fees] and members rights and duties.
+
The Polarsys Top Level Project (the "Polarsys Project") is an open source software development project hosted by the [http://www.polarsys.org Polarsys] Industry Working Group which is dedicated to providing a robust, full-featured, industrial-quality, and freely available set of development tools addressing specific needs of critical and embedded systems.
  
As stated in the section about [http://www.eclipse.org/org/industry-workgroups/polarsys_charter.php#Component_Management Component Management] of Polarsys in the Charter, Polarsys will either:
+
This document describes the mission, scope, and organization of this Top Level Project and its constituent Projects, as well as the roles and responsibilities of the participants. It inherits all terms not otherwise defined herein from the [http://www.eclipse.org/projects/dev_process/Eclipse_Standard_TopLevel_Charter_v1.1.php 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.
* 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.
+
  
 
== Mission  ==
 
== Mission  ==
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 [http://www.eclipse.org/modeling/ Eclipse Modeling Project] like [http://www.eclipse.org/modeling/mdt/papyrus/ Papyrus], [http://www.eclipse.org/acceleo/ Acceleo] or other components like the [http://www.eclipse.org/cdt/ CDT] are very important components for [http://www.polarsys.org 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.
+
Due to its strong emphasis on safety, reliability and quality, the development of embedded and critical systems is based since the beginning of its history on numerous software tools. But while the life cycle of critical and embedded systems goes from 10 years up to 80 years in the case of aircraft, the tools frequently become obsolete or disappear after less than 15, 10 or even 5 years. Polarsys has been created to take advantage of open source to bridge this gap and to foster innovation in this domain. The mission of the Polarsys Top-Level Project is therefore to host the open source assets of Polarsys.
  
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 [[Polarsys/TLPProposal#Licensing |Licensing section]] of this proposal.
+
The aim is not to host all technologies that can be applied to Embedded Systems design and development. The components with a larger audience than only critical and embedded systems will instead be hosted by a most relevant community. Good examples of this situation are some components from the [http://www.eclipse.org/modeling/ Eclipse Modeling Project] like [http://www.eclipse.org/modeling/mdt/papyrus/ MDT Papyrus], [http://www.eclipse.org/acceleo/ Acceleo] or other development tools like the [http://www.eclipse.org/cdt/ CDT]. They will neither move nor be duplicated into the Polarsys Top-Level Project, but they may be referenced by Polarsys, and some complementary assets (specific functional tests, extra documentation, etc.) may be hosted in Polarsys.
 +
 
 +
Projects hosted by this Top-Level Project can be licensed under either the EPL or any other licenses approved by the Industry Working Group and the Eclipse Foundation Board of Directors, including BSD-like licenses and the LGPL. See the [[Polarsys/TLPProposal#Licensing|Licensing section]] for more information. While most PolarSys projects will probably publish Eclipse features, some others may produce other kinds of component like stand-alone tools and servers.
  
 
== Scope  ==
 
== Scope  ==
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 covers critical and embedded systems development activities, from the early specification stage, down to the implementation and then up to verification and validation, including:
*''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.
+
* Modeling – systems, hardware and software
 
+
* Code analysis – static analysis
Polarsys adds a cross level:
+
* Debugging, tracing and other integration tools
 
+
* Life cycle process support tools – configuration management, change tracking, technical facts management, project reporting
*''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).
+
* Test and verification frameworks, tools targeting embedded software methods, simulation, and early validation
 +
* SoC (System on Chip) simulation and hardware logic (VHDL, SystemC, etc.)
 +
* Embedded components like RTOS, middleware, etc.
  
 
== Project Management Committee  ==
 
== 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.
+
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.  
  
<span style="background-color: #FFFF00">[Maurice Heitz]</span>
+
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.  
''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)''
+
<span style="background-color: #FFFF00">[Pierre Gaufillet]</span>
+
I guess the TLP should be managed by the steering committee and/org the architecture board.
+
  
 
== Project Planning Committees  ==
 
== Project Planning Committees  ==
  
Explain their role and how they interact with the PMC. <span style="background-color: #FFFF00">[Pierre Gaufillet]</span>
+
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 [http://www.eclipse.org/org/industry-workgroups/polarsys_charter.php#Project_Planning_Committees Project Planning Committees].
+
  
== Roles  ==
+
But in no way PPC replace PMC:
  
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.  
+
*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 medium term 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.
  
=== Users  ===
+
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.  
 
+
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.
+
 
+
=== Developers  ===
+
 
+
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.
+
 
+
=== Committers  ===
+
 
+
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.  
+
  
 
== Projects  ==
 
== Projects  ==
 
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.
 
  
 
=== Project Organization  ===
 
=== Project Organization  ===
  
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.  
+
The Polarsys projects and components are organized according to a logical layered architecture:
 +
*''Polarsys Technology Layer - PTL'': this layer contains projects and components with a technical scope, such as domain management (e.g. persistence, team work), transformation technology (e.g. model transformation, reverse engineering, refactoring), or interoperability.
 +
*''Polarsys Engineering Layer - PEL'': this layer contains projects and components with a system, software or hardware engineering scope, such as requirement engineering, change management, simulation, architecture, or Integration, Verification and Validation.
 +
*''Polarsys Service Framework - PSF'': this container hosts all the projects and components used to support Polarsys specific process, such as VLTS release engineering, Quality Assurance or maturity assessment. This layer extends the Eclipse infrastructure which provides standard services  (e.g. Hudson/Buckminister/Tycho for continuous integration, Bugzilla for change management, file downloading area, mailing lists).
  
As Is. Add elements about relationship with Polarsys Steering Committee.<span style="background-color: #FFFF00">[Pierre Gaufillet]</span>
+
Companies or communities that require it can complete the PEL by a Business Layer composed of business-specific components (e.g. requirement engineering for Telecommunications, Simulation for a specific line of products, etc.).
+
  
 
== Infrastructure  ==
 
== Infrastructure  ==
  
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.
+
Beyond the standard Eclipse infrastructure, new services will be developed and deployed including:
 
+
* Catalog of components
Add here specific Polarsys infrastructure&nbsp;: catalog, quality assessment, functional testing, VLTS.<span style="background-color: #FFFF00">[Raphaël Faudou]</span>
+
* Assessment and publication of the component's maturity
''Couldn't  we have a special project dedicated to the infrastructure support of  projects ''<span style="background-color: #FFFF00">[Maurice Heitz]</span>
+
* Assessment and publication of the component's quality
 
+
* Functional testing framework
== The Development Process  ==
+
* VLTS build infrastructure
  
The development process of the Polarsys project conforms to the standard project development process described [http://www.eclipse.org/projects/dev_process/Eclipse_Standard_TopLevel_Charter_v1.1.php#The_Development_Process here].
+
When possible, Polarsys will use the standard Eclipse infrastructure and Polarsys hosted components to implement those services.
  
 
== Licensing  ==
 
== Licensing  ==
  
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.
+
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.
+
As of this proposal, the list of accepted licenses includes the EPL, BSD-like and Apache Licenses, and LGPL.
  
 +
== Glossary  ==
  
== Glossary of Terms ==
+
*'''CDT''' Eclipse C/C++ Development Tooling  
*CDT Eclipse C/C++ Development Tooling
+
*'''IP''' Intellectual Property
*EMO Eclipse Management Organisation
+
*'''IWG''' Industry Working Group  
*IWG Industry Working Group
+
*'''PEL''' Polarsys Engineering Layer: projects and components with a system, software or hardware engineering scope
*PMC Project Management Committee
+
*'''PSF''' Polarsys Service Framework: project and components to support additional Polarsys services
*PSF Polarsys Service Framework
+
*'''PTL''' Polarsys Technology Layer: projects and components with a technical scope, such as transformation technology or interoperability.  
*PSC Polarsys Sterring Committee
+
*'''VLTS''' Very Long Term Support
*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
+

Latest revision as of 23:29, 11 September 2012

Overview

The Polarsys Top Level Project (the "Polarsys Project") is an open source software development project hosted by the Polarsys Industry Working Group which is dedicated to providing a robust, full-featured, industrial-quality, and freely available set of development tools addressing specific needs of critical and embedded systems.

This document describes the mission, scope, and organization of this Top Level Project and its constituent Projects, as well as the roles and responsibilities of the participants. It 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.

Mission

Due to its strong emphasis on safety, reliability and quality, the development of embedded and critical systems is based since the beginning of its history on numerous software tools. But while the life cycle of critical and embedded systems goes from 10 years up to 80 years in the case of aircraft, the tools frequently become obsolete or disappear after less than 15, 10 or even 5 years. Polarsys has been created to take advantage of open source to bridge this gap and to foster innovation in this domain. The mission of the Polarsys Top-Level Project is therefore to host the open source assets of Polarsys.

The aim is not to host all technologies that can be applied to Embedded Systems design and development. The components with a larger audience than only critical and embedded systems will instead be hosted by a most relevant community. Good examples of this situation are some components from the Eclipse Modeling Project like MDT Papyrus, Acceleo or other development tools like the CDT. They will neither move nor be duplicated into the Polarsys Top-Level Project, but they may be referenced by Polarsys, and some complementary assets (specific functional tests, extra documentation, etc.) may be hosted in Polarsys.

Projects hosted by this Top-Level Project can be licensed under either the EPL or any other licenses approved by the Industry Working Group and the Eclipse Foundation Board of Directors, including BSD-like licenses and the LGPL. See the Licensing section for more information. While most PolarSys projects will probably publish Eclipse features, some others may produce other kinds of component like stand-alone tools and servers.

Scope

Polarsys covers critical and embedded systems development activities, from the early specification stage, down to the implementation and then up to verification and validation, including:

  • Modeling – systems, hardware and software
  • Code analysis – static analysis
  • Debugging, tracing and other integration tools
  • Life cycle process support tools – configuration management, change tracking, technical facts management, project reporting
  • Test and verification frameworks, tools targeting embedded software methods, simulation, and early validation
  • SoC (System on Chip) simulation and hardware logic (VHDL, SystemC, etc.)
  • Embedded components like RTOS, middleware, etc.

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 medium term 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.

Projects

Project Organization

The Polarsys projects and components are organized according to a logical layered architecture:

  • Polarsys Technology Layer - PTL: this layer contains projects and components with a technical scope, such as domain management (e.g. persistence, team work), transformation technology (e.g. model transformation, reverse engineering, refactoring), or interoperability.
  • Polarsys Engineering Layer - PEL: this layer contains projects and components with a system, software or hardware engineering scope, such as requirement engineering, change management, simulation, architecture, or Integration, Verification and Validation.
  • Polarsys Service Framework - PSF: this container hosts all the projects and components used to support Polarsys specific process, such as VLTS release engineering, Quality Assurance or maturity assessment. This layer extends the Eclipse infrastructure which provides standard services (e.g. Hudson/Buckminister/Tycho for continuous integration, Bugzilla for change management, file downloading area, mailing lists).

Companies or communities that require it can complete the PEL by a Business Layer composed of business-specific components (e.g. requirement engineering for Telecommunications, Simulation for a specific line of products, etc.).

Infrastructure

Beyond the standard Eclipse infrastructure, new services will be developed and deployed including:

  • Catalog of components
  • Assessment and publication of the component's maturity
  • Assessment and publication of the component's quality
  • Functional testing framework
  • VLTS build infrastructure

When possible, Polarsys will use the standard Eclipse infrastructure and Polarsys hosted components to implement those services.

Licensing

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 and Apache Licenses, and LGPL.

Glossary

  • CDT Eclipse C/C++ Development Tooling
  • IP Intellectual Property
  • IWG Industry Working Group
  • PEL Polarsys Engineering Layer: projects and components with a system, software or hardware engineering scope
  • PSF Polarsys Service Framework: project and components to support additional Polarsys services
  • PTL Polarsys Technology Layer: projects and components with a technical scope, such as transformation technology or interoperability.
  • VLTS Very Long Term Support