Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "IoT/PMC"
< IoT
(First version) |
(Fixed some typos, some re-phrasing, added some questions) |
||
| Line 5: | Line 5: | ||
---- | ---- | ||
| − | Every now and then the following sections will refer to "voting", unless noted otherwise this | + | 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. | |
== Members == | == Members == | ||
| − | + | New members get nominated and voted in by the current (IoT) PMC members. | |
| − | + | The current list of members is: | |
* Benjamin Cabé | * Benjamin Cabé | ||
| Line 21: | Line 21: | ||
* Julien Vermillard | * Julien Vermillard | ||
| − | == | + | == Reviewing CQs == |
* 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 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. | + | * 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. (What does "trying a simple vote" mean? What is a "failed vote"? Kai H.) |
| − | * | + | * The PMC needs to approve (or reject) newly filed CQs on IPZilla. In most cases the subject of the CQ will not be controversial so any PMC member may conclude the CQ by means of indicating approval or rejection (+1/-1) on IPZilla. However, in cases where a PMC member has concerns regarding the CQ or would like to get some clarification from the issuer of the CQ, then that particular PMC member who has started the conversation is responsible for concluding the PMC's review of the CQ. This way we make sure that the concerns or open questions of PMC members get addressed before a CQ is concluded. |
== Releases == | == Releases == | ||
| Line 31: | Line 31: | ||
* Releases are +1ed by the PMC by holding a vote | * Releases are +1ed by the PMC by holding a vote | ||
* Review security related topics | * Review security related topics | ||
| − | ** The project must have reviewed the Eclipse security guidelines | + | ** The project must have reviewed the Eclipse security guidelines (How do we know they have? Kai H.) |
** 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 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 | + | ** 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 those must be listed as well | + | ** 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 | + | ** 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". |
| − | {{Note|Security issues|A security issue is either | + | {{Note|Security issues|A security issue is either "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 == | == Project == | ||
| − | * | + | * The PMC approves all requests of projects to move to GitHub, we simply give the formal +1. |
Revision as of 02:58, 28 March 2017
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.
Contents
Members
New members get nominated and voted in by the current (IoT) PMC members.
The current list of members is:
- Benjamin Cabé
- Kai Hudalla
- Kai Kreuzer
- Jens Reimann
- Julien Vermillard
Reviewing CQs
- 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. (What does "trying a simple vote" mean? What is a "failed vote"? Kai H.)
- The PMC needs to approve (or reject) newly filed CQs on IPZilla. In most cases the subject of the CQ will not be controversial so any PMC member may conclude the CQ by means of indicating approval or rejection (+1/-1) on IPZilla. However, in cases where a PMC member has concerns regarding the CQ or would like to get some clarification from the issuer of the CQ, then that particular PMC member who has started the conversation is responsible for concluding the PMC's review of the CQ. This way we make sure that the concerns or open questions of PMC members get addressed before a CQ is concluded.
Releases
- Releases are +1ed by the PMC by holding a vote
- Review security related topics
- The project must have reviewed the Eclipse security guidelines (How do we know they have? Kai H.)
- 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 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".
Security issues
A security issue is either "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 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
- The PMC approves all requests of projects to move to GitHub, we simply give the formal +1.