Community
Participate
Working Groups
The current Developer Portal has reached the end of its life and it's time to initiate a whole new effort to reimplement the infrastructure that we use to manage projects, committers, etc. There are some fundamental flaws in the current implementation that we need to overcome with this new effort. For example: * Multiple, separate data sources. We currently have three databases that contain our data: the "Foundation" database maintains information about projects, people, organizations, and the relationships between them; the "Eclipse" database contains copies of some Foundation data (it was created to provide additional separation between the outside world and the private information contained in the Foundation database, but that separation has broken down over time); and the "Portal" database which keeps portal-specific information like project metadata. With all of these data sources separated, there is some redundancy and occasional inconsistency; and queries that span data sources are more difficult than necessary. * The Developer Portal is separate from the the resources being managed. This 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. This is 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 and--oftentimes--managed manually (the associated processes are error prone and often managed inconsistently). * Even information that is managed by the Portal is oftentimes inconsistent. Releases and reviews are, for example, represented separately with no direct connections. Making connections between the two requires clumsy guesses at the relationships based on naming and usage conventions. * The underlying technology is limited in terms of ability to support useful innovations like rich text fields. * Portal paradigm is limiting. Not all features can fit into tidy component boxes. * The current implementation is entirely proprietary with no community support. Finding skilled resources is impossible. Leveraging existing technology (i.e. search technology, rich text editing) is non-trivial. The new implementation, to be built using Drupal 7, will free to reimplement key systems and data sources as necessary. The "Eclipse" database will be eliminated. The Foundation and Portal databases will be combined and modified as required. This bug will serve as a parent for bugs pertaining to the initial implementation of the new infrastructure. General discussion should be made here, but specific discussion pertaining to individual features should take place in the relevant subtasks (which I will spend time over the next few days and weeks creating). Related discussion: http://waynebeaton.wordpress.com/2011/10/25/eclipse-project-management-infrastructure/ http://waynebeaton.wordpress.com/2011/11/09/eclipse-project-management-infrastructure-technology-choice/
Initial implementation is complete and rolled out. Marking as FIXED. Additional functionality will be tracked by other bugs.
