Skip to main content

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.

Jump to: navigation, search

EPP/Obsolete/EPP Committer and Maintainer Policy

< EPP
Warning2.png
Note: The contents of this page is obsolete, the policy text has been moved to the project's CONTRIBUTING.md file.


EPP Committer and Maintainer Policy

In EPP, the "maintainer" of a package is a committer in EPP. Partially so they can do work on their package, and also so that can participate in project discussions and decisions that effect the project or whole set of EPP packages.

Historical note: in 2010, the current set of committers were "seeded" by making all current maintainers committers. Prior to that, there was only one active committer, the Project Lead, Markus Knauer, which was less than ideal for many reasons. Now that time has passed, it was thought best to document the EPP project's policy on making new people committers and maintainers of packages (either new packages, or transfer "ownership" of an existing package). In particular, it was decided to follow "the Orbit model" of committership and package "owner".

If someone is a committer on another Eclipse project, and they state they are interested in contributing and maintaining an EPP package (or, transferring ownership of an existing EPP package), that history with other Eclipse projects suffices for them to be nominated and voted-in as a committer. This differs from most other projects where, for good reason, a person must (usually) have a history of contributions to that specific project, not just Eclipse in general. There still could be reasons an existing committer would note "no" (-1) for a nomination, for example, "no, I am the current maintainer and I do not agree to this!" ... or some other fairly large issue. Normally people do not vote "0" just because they have no first hand knowledge of a person's committer history (as they might on other projects), but vote "+1" if basic criteria are met, to be welcoming and supportive of new people coming in.

Normally, as with most other Eclipse projects, unless a committer explicitly "resigns" there would be no automatic removal of a committer just because package responsibility is transferred, except eventually the usual "inactive" reasons would apply ... if someone is no longer responsible for maintaining a package and has not been active on mailing lists, etc., for a period of 6 months or so, the Project Lead can remove them via Eclipse Portal for "inactivity". And, of course, committers should explicitly resign, when appropriate, such as they are changing responsibilities and know they have no interest or time to be involved.

Back to the top