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 refers to the Eclipse voting process for committers: Development_Resources/HOWTO/Nominating_and_Electing_a_New_Committer#How_Do_We_Hold_The_Election.3F.
PMC members do not participate in votes on their own project(s) but will simply abstain from such votes explicitly. It is up to the discretion of each PMC member to determine which votes to abstain from. However, it is good practice that PMC members abstain from votes on any of the projects they are an active committer on or for which they are project lead.
New members get nominated and voted in by the current (IoT) PMC members.
The current list of members is:
- Benjamin Cabé
- Ian Craggs
- Kai Hudalla
- Jens Reimann
- David Woodard
- Julien Vermillard
- Kai Kreuzer
The IoT PMC needs to review newly filed CQs on IPzilla based on the Eclipse Foundation's Guidelines for the Review of Third Party Dependencies.
First of all, the IoT PMC does not put any constraints on dependencies that projects can use in addition to the ones outlined in the Eclipse Legal Process. This mainly affects license compatibility and requirements regarding code provenance etc.
When a committer creates a CQ in IPzilla he indicates a preference for the CQ's designation as a pre-req or a works-with dependency. Any IoT PMC member may immediately approve a CQ with a designation of pre-req which piggy-backs another pre-req CQ that has already been approved.
In all other cases the first (and most important) task of the IoT PMC is therefore to determine whether the author's preference is appropriate or not. In order to do so, the PMC members interact with the project members via IPzilla's comment functionality (i.e. in the context of the CQ) in order to get all information relevant for determining the CQ's appropriate designation. Based on the outcome, the IoT PMC approves or rejects the CQ based on the following table:
|pre-req||incompatible||Other||discuss and vote|
The process for discuss and vote is as follows:
- The PMC members cast their vote directly in the CQ
- THIS IS NEW: If after 72 hours (incl. weekends) a majority of the PMC members has voted +1 with no member voting -1, then the vote concludes successfully. This process allows CQs to be approved as quickly as possible while still providing all PMC members with a chance to raise concerns or put in their veto.
- Otherwise, if the vote is not unanimous then the PMC discusses until a consensus is found and established by a vote (Following the standard voting procedure).
- The CQ's designation is adjusted according to the result of the discussion in IPzilla and the PMC's approval or disapproval of the CQ is recorded in IPzilla by the PMC member that initiated the discussion on the CQ.
The process for approve works-with is as follows:
- Any of the PMC members assess the appropriateness of the dependency's designation as works-with. In simple cases this will be obvious, in other cases this will require interaction with the project committer(s).
- Once the correct designation is determined, the CQ's designation is adjusted accordingly and the PMC's approval or disapproval of the CQ is recorded in IPzilla by the PMC member that initiated the discussion on the CQ.
If there exists a previous approval for a works-with/pre-req dependency and the project's request is equal to that request (same version, like a piggyback), then any PMC member may simply approve the CQ on behalf of the PMC immediately, if he thinks this approach is reasonable.
For initial code contributions or changes from people new to the project or the Eclipse Foundation, the PMC briefly checks for common mistakes new project members often make, e.g. missing copyright headers, incorrect bundle/module naming etc. Please refer to the Eclipse Project Handbook for details regarding the specific requirements.
For subsequent patches/PRs the PMC's main objective is to make sure that the proposed changes match the project's scope.
- Releases are +1ed by the PMC by holding a vote
- Review security related topics
- The project must have reviewed the Eclipse security guidelines. We simply ask, or point people towards it.
- 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 released, a link to the corresponding committer-only bugzilla issue is enough.
- If the release has known security issues, which will not get fixed in this release, then 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 had to be fixed".
- The PMC approves all requests of projects to move to GitHub, we simply give the formal +1.
- The PMC does generally NOT approve requests for project-specific Github organisations. By default, all Eclipse IoT projects on Github should be part of https://github.com/eclipse. If a project has a severe issue, which can only be suitably addressed by a dedicated Github organisation, this must be discussed with and approved by the PMC.