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 "Project Management Infrastructure Redesign 2011"
| Line 17: | Line 17: | ||
The Eclipse Foundation currently uses Drupal for [http://markeplace.eclipse.org Eclipse Marketplace], [http://live.eclipse.org Eclipse Live], and the [http://www.eclipsecon.org 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. | The Eclipse Foundation currently uses Drupal for [http://markeplace.eclipse.org Eclipse Marketplace], [http://live.eclipse.org Eclipse Live], and the [http://www.eclipsecon.org 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. | 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. | ||
| Line 23: | Line 25: | ||
|+Technology comparison | |+Technology comparison | ||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
| − | ! !! Language !! In-house Resources !! Community Size !! | + | ! !! Language !! In-house Resources !! Community Size !! Pros !! Cons |
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
| Line 31: | Line 33: | ||
| 100,000's | | 100,000's | ||
| | | | ||
| − | * | + | * Large number of skilled resources available |
| + | * Deployed by 1,000's of organizations | ||
* Hundreds of plug-ins available to leverage in favour of writing custom code | * Hundreds of plug-ins available to leverage in favour of writing custom code | ||
** Integration with Facebook, Twitter, etc. | ** Integration with Facebook, Twitter, etc. | ||
| + | ** Access information via RESTful webservices | ||
| + | * Build-in (no-brainer) database support | ||
| + | * Integrated Development tools + Eclipse/PDT | ||
| + | * Existing IT Infrastructure support | ||
| + | | | ||
| + | * Drupal-specific data structures and formats. | ||
| + | |- style="vertical-align:top;" | ||
| + | ! [http://www.eclipse.org/skalli Skalli] | ||
| + | | Java | ||
| + | | 1 | ||
| + | | 1 | ||
| + | | | ||
| + | * OSGi-based solution | ||
| + | * Dogfooding solution | ||
| + | * Eclipse-based development tools available | ||
| + | * Leverage existing Eclipse technologies (EMF, workflow projects, SOA, EclipseLink, etc.) | ||
| + | * Project developers have expressed interest in implementing some Eclipse Foundation processes (though with no specific commitments) | ||
| + | | | ||
| + | * New project, very small community | ||
| + | * No resources available | ||
| + | ** Ramp up time for new developers is relatively long. | ||
| + | ** Good quality Java-savvy developers are relatively difficult to find. | ||
| + | ** Virtually impossible to find developers familiar with Skalli itself | ||
| + | * Integration opportunities with existing Eclipse technologies remain largely unexplored | ||
| + | * No existing IT Infrastructure support | ||
|} | |} | ||
Revision as of 10:50, 20 July 2011
This effort is being tracked by Bug 243223.
Problem Statement
Current infrastructure (i.e. The Developer Portal) is inadequate.
Multiple, separate data sources.
Portal is separate from the the resources being managed. Requires a context switch to use. Most committers have difficulty (or outright refuse) to make that context switch.
Some management tasks are spread out. Specifying a description for a project, for example, requires that an HTML file be created in the project directory (requires CVS check-in), and then the specification of a URL in the portal. Very difficult to maintain. Very separated from where and how the description is used. As a result, descriptions tend to be poorly specified, and maintained.
Too much information is not included in or managed by the portal. Project proposals, review documentation, IP logs, are all separate.
Technology Choices
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.
| Language | In-house Resources | Community Size | Pros | Cons | |
|---|---|---|---|---|---|
| Drupal | PHP | 5 | 100,000's |
|
|
| Skalli | Java | 1 | 1 |
|
|