Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Project Management Infrastructure Redesign 2011"

Line 25: Line 25:
 
|+Technology comparison
 
|+Technology comparison
 
|- style="vertical-align:top;"
 
|- style="vertical-align:top;"
!   !! Language !! In-house Resources !! Community Size !! Pros !! Cons
+
!   !! Language !! Existing Resources !! Community Size !! Pros !! Cons
  
 
|- style="vertical-align:top;"
 
|- style="vertical-align:top;"
Line 31: Line 31:
 
| PHP
 
| PHP
 
| 5
 
| 5
| 100,000's
+
| 100,000s
 
|  
 
|  
 
* Large number of skilled resources available
 
* Large number of skilled resources available
* Deployed by 1,000's of organizations
+
* Deployed by 1,000s 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.  
Line 43: Line 43:
 
|
 
|
 
* Drupal-specific data structures and formats.
 
* Drupal-specific data structures and formats.
 +
* Not dogfooding; perception in the community
  
 
|- style="vertical-align:top;"
 
|- style="vertical-align:top;"
Line 50: Line 51:
 
| 1
 
| 1
 
|  
 
|  
* OSGi-based solution
+
* "Dogfooding" solution
* Dogfooding solution
+
 
* Eclipse-based development tools available
 
* Eclipse-based development tools available
 
* Leverage existing Eclipse technologies (EMF, workflow projects, SOA, EclipseLink, etc.)
 
* 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)
 
* Project developers have expressed interest in implementing some Eclipse Foundation processes (though with no specific commitments)
 +
* Opportunity to fully control the database structure
 
|
 
|
 
* New project, very small community
 
* New project, very small community
* No resources available
+
* No skilled resources available
 
** Ramp up time for new developers is relatively long.
 
** Ramp up time for new developers is relatively long.
 
** Good quality Java-savvy developers are relatively difficult to find.
 
** Good quality Java-savvy developers are relatively difficult to find.
 
** Virtually impossible to find developers familiar with Skalli itself
 
** Virtually impossible to find developers familiar with Skalli itself
 
* Integration opportunities with existing Eclipse technologies remain largely unexplored  
 
* Integration opportunities with existing Eclipse technologies remain largely unexplored  
 +
* No existing IT Infrastructure support
 +
 +
|- style="vertical-align:top;"
 +
! [http://www.eclipse.org/aprcot Apricot]
 +
| Java
 +
| 1
 +
| 10s?
 +
|
 +
* "Dogfooding" solution
 +
* Eclipse-based development tools available
 +
* Leverage existing Eclipse technologies (EMF, workflow projects, SOA, EclipseLink, etc.)
 +
|
 +
* New project, relatively small (but focused) community
 +
* Unknown availability of skilled resources available
 +
** Assumed to be no skilled Apricot developers available in the local area.
 +
** Ramp up time for new developers is relatively long.
 +
** Good quality Java-savvy developers are relatively difficult to find.
 
* No existing IT Infrastructure support
 
* No existing IT Infrastructure support
  
 
|}
 
|}

Revision as of 10:58, 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.

Technology comparison
  Language Existing Resources Community Size Pros Cons
Drupal PHP 5 100,000s
  • Large number of skilled resources available
  • Deployed by 1,000s of organizations
  • Hundreds of plug-ins available to leverage in favour of writing custom code
    • 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.
  • Not dogfooding; perception in the community
Skalli Java 1 1
  • "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)
  • Opportunity to fully control the database structure
  • New project, very small community
  • No skilled 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
Apricot Java 1 10s?
  • "Dogfooding" solution
  • Eclipse-based development tools available
  • Leverage existing Eclipse technologies (EMF, workflow projects, SOA, EclipseLink, etc.)
  • New project, relatively small (but focused) community
  • Unknown availability of skilled resources available
    • Assumed to be no skilled Apricot developers available in the local area.
    • Ramp up time for new developers is relatively long.
    • Good quality Java-savvy developers are relatively difficult to find.
  • No existing IT Infrastructure support

Back to the top