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.
Project Management Infrastructure/Technology Choices
Drupal 7.2 is used for initial implementation.
The new system will use LDAP for user authentication and for some aspects of authorization. This implementation will be based on work being done in bug 364605 that intends to standardize the entire eclipse.org infrastructure on the LDAP (Bugzilla-based authentication is used for most eclipse.org properties; LDAP is currently only used for committer authentication).
LDAP groups are used for project-based authorization. Users who have committer access to a project are members of an LDAP group that corresponds to the project. This group membership is bound to Drupal authentication via Drupal "organic groups" functionality. Additional authorization schemes are required to handle PMC-access to projects and other corner cases. For more information, see bug 363614.
Project management is essentially a document-management and workflow problem. Several solutions exist in this area.
The Eclipse Foundation currently uses Drupal for Eclipse Marketplace, Eclipse Live, and the EclipseCon Website. Several Eclipse Foundation employees are already well-versed in Drupal development, and finding temporary resources with the necessary skills in the local area should be relatively easy and cost-effective. Drupal is based on PHP, a language that is known to most of the Eclipse Foundation staff, and is currently in wide deployment by the Eclipse Foundation.
Perhaps one of the features that weighs most heavily in Drupal's favour is the size of the community behind it (which measures in the hundreds of thousands) and the hundreds (perhaps thousands) of plugins that are available to extend it. The availability of plugins, combined with the relative ease with which Drupal can be extended means that the overall amount of custom code that needs to be maintained should be relatively small (as compared to other solutions that may require more customization).
There are several other options that have been considered, including a handful of Eclipse-based solutions (which would allow us to "eat our own dogfood"). After careful consideration, however, we have determined that we do not have the resources to implement these solutions.