Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
IoT/PMC
This is the page of the IoT toplevel project PMC.
There is also the page of the Eclipse IoT working group.
Every now and then the following sections will refer to "voting", unless noted otherwise this references to the Eclipse voting process for committers: Development_Resources/HOWTO/Nominating_and_Electing_a_New_Committer#How_Do_We_Hold_The_Election.3F.
However PMC members don't vote on their own projects, but simply abstain from votes explicitly. Every PMC member knows best which projects those are, but being an active committer or project lead on this project would probably be a reason to abstain.
Contents
Members
Members get nominated and voted in by the current PMC.
Currently the PMC consists of:
- Benjamin Cabé
- Kai Hudalla
- Kai Kreuzer
- Jens Reimann
- Julien Vermillard
Dependencies
- We don't put any additional restrictions on dependencies a project would like to use, aside from requirements the Eclipse Foundation has of course
- We try a simple vote for works-with/pre-requisite dependency requests. The initial request must thus contain a preference (works-with/pre-requisite). If the vote fails we start a discussion.
- Reviewing a CQ in Issuezilla the person giving the first comment should finish up the review (+1/-1) once all comments are addressed.
Releases
- Releases are +1ed by the PMC by holding a vote
- Review security related topics
- The project must have reviewed the Eclipse security guidelines
- The project has to include a link on the main project home page on "how to report a security vulnerability", a properly labeled link to https://eclipse.org/security/ is fine
- The project must state which security issues have been resolved in this release. This also includes issues for which no GitHub or Bugzilla issue exists. If a vulnerability cannot be disclosed before the project is release a link to the committer-only bugzilla issue is enough.
- If the release has known security issues those must be listed as well
- If the release did not fix any security issues, this has to be stated explicitly by something like "No security related issues have to be fixed".
Security issues
A security issue is either a "A weakness of an asset or group of assets that can be exploited by one or more threats." (also see ISO 27005) or a "vulnerability" according to https://cve.mitre.org/about/terminology.html. As of now this includes only security issues in the project's code itself. Issues in shipped dependencies can be disclosed as well, but there is currently no requirement. Unless there is a specific issue raised for that Eclipse project regarding this dependency (e.g. Eclipse Foo Bar is vulnerable to ABC because dependency XZY v1.2.3).
A security issue is either a "A weakness of an asset or group of assets that can be exploited by one or more threats." (also see ISO 27005) or a "vulnerability" according to https://cve.mitre.org/about/terminology.html. As of now this includes only security issues in the project's code itself. Issues in shipped dependencies can be disclosed as well, but there is currently no requirement. Unless there is a specific issue raised for that Eclipse project regarding this dependency (e.g. Eclipse Foo Bar is vulnerable to ABC because dependency XZY v1.2.3).
Project
- All projects are allowed to move to GitHub, we simply give the formal +1