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

Difference between revisions of "Project Management Infrastructure Redesign 2011"

(→‎Overview and Design)
(→‎Technology)
 
(4 intermediate revisions by the same user not shown)
Line 32: Line 32:
 
=Technology=
 
=Technology=
  
−
==Drupal==
+
Moved to [[Project Management Infrastructure/Technology Choices]].
−
 
+
−
Drupal 7.2 is used for initial implementation.
+
−
 
+
−
==LDAP==
+
−
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}}.
+
  
 
=Themes=
 
=Themes=
−
The following themes will guide the development of the new Project Management Infrastructure:
 
  
−
* Trust committers to do the right thing;
+
Moved to [[Project Management Infrastructure]].
−
* Once and only once (avoid repeating information);
+
−
* Everything is undoable (i.e. revision tracking); and
+
−
* Do the simplest thing that can possibly work (avoid complexity)
+
−
 
+
−
We assume that committers will always endeavour to do the right thing. Specifically, we give committers leeway to do what they think is right. This, in combination with revision tracking means that mistakes can be easily undone. A committer may, for example, make ill-informed changes to a project's scope that is later reversed by the project lead or PMC.
+
−
 
+
−
It would be easy to get mired in multiple layers of approvals for various activities, or complex logic to prevent committers from shooting themselves in the proverbial foot. But such complexity makes the cost of later change and ongoing maintenance prohibitively high.
+
−
 
+
−
Note that we make a distinction between committers and general users. We do not--as a general rule--trust the general population to do the right thing. For completeness, we include with the definition of "committers" all those users with roles that permit them access to the project (including project leads, pmc members, EMO staff, etc.)
+
  
 
=Requirements and Implementation=
 
=Requirements and Implementation=
  
−
Requirements for the new Project Management Infrastructure are detailed in Eclipse Bugzilla (note that requirements are still be added at this time). Eclipse Bugzilla {{Bug|363868}}, ''Reimplement the Project Management Infrastructure/Developer Portal'', provides the root for the initial effort; all features and functionality planned for the initial release are captured as subtasks.
+
Moved to [[Project Management Infrastructure/Development]].
  
 
=Overview and Design=
 
=Overview and Design=
Line 65: Line 48:
 
=Structure=
 
=Structure=
  
−
The application code is laid out in a directory structure containing several custom modules (details TBD). The system can be manifested directly from these modules. Modules are self-contained, are self-configuring, and self-updatable.
+
Moved to [[Project Management Infrastructure/Development]].
−
 
+
−
An installation profile for projects.eclipse.org automates the initial installation and configuration of the system, along with bootstrap data for eclipse.org projects.
+
  
 
=Application Lifecycle Management=
 
=Application Lifecycle Management=
  
−
The Project Management Infrastructure is not itself an Eclipse project.
+
Moved to [[Project Management Infrastructure/Development]].
−
 
+
−
While under development, the system is deployed in two different configurations: one for eclipse.org and one for Polarsys. A major design point is to permit multiple separate deployments with customization ("Foundation in a box").
+
−
 
+
−
==Source Control==
+
−
 
+
−
Drupal presents some interesting source control management issues; it is possible to "code" much of a Drupal-based site without ever writing actual code. Many of the development tools provided for Drupal facilitate the construction of elements that exist directly in the database. When those tools are used--such as the Content Construction Toolkit (CCK)--the results are converted into code and included in the code tree. The code tree is committed into Git.
+
−
 
+
−
The main Git repository is currently private to employees of the Eclipse Foundation. This will change as development progresses.
+
−
 
+
−
==Build and Release==
+
−
 
+
−
Releases are tagged using standard three-part Eclipse version numbering strategy. The first number, the ''major'' version is updated for significant milestones (or when significant API breakage occurs); the second number, or ''minor'' version is updated with each release that adds or changes functionality; and the third number, or ''service'' version is updated for bugfix or service releases.
+
−
 
+
−
Builds are generated by tagging and then extracting (via <code>git archive</code>) the state of the system.  ''We need to visit this decision as we do not actually use these builds as part of our deployment.''
+
−
 
+
−
==Deployment==
+
−
 
+
−
* Deploy first to staging servers for testing;
+
−
* When tests pass, deploy to production servers;
+
−
* Deploy directly from git (i.e. <code>git pull</code>);
+
−
* Deployment to both projects.eclipse.org and polarsys.org
+
  
 
=Schedule=
 
=Schedule=

Latest revision as of 16:25, 17 April 2012

This effort is being tracked by Bug 243223.

Note that this document is not intended to be all inclusive. The combination of this document, the existing Developer Portal Use Cases, and the Eclipse Development Process form a more complete picture.

Problem Statement

Current infrastructure (i.e. The Developer Portal) is inadequate.

Data concerning projects, people, organizations, members, and more is spread across multiple, separate data sources. This makes querying across data challenging. In some cases, data is replicated from one database to another to facilitate some queries while providing an added layer of protection. The database that contains committer information, the so-called "Foundation" database, is kept separate from other systems to provide an added layer of protection against private data being compromised. Bits of that database are replicated into an "Eclipse" database for access from the public website.

Portal is separate from the the resources being managed; this requires a context switch to use. The content displayed in the project summary pages, for example, comes from the portal. When a committer notices that the data in the project summary is incorrect, they must switch into the portal to make the change. 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 as it is separated from where and how the description is used, and requires multiple steps with multiple tools to complete. As a result, descriptions tend to be poorly specified, and rarely maintained.

Too much information is not included in or managed by the portal. Project proposals, review documentation, IP logs, are all separate.

Technology Choices

Moved to Project Management Infrastructure/Technology Choices.

Roles

  • EMO(ED) - EMO Executive Directory (i.e. Mike)
  • EMO(PM) - EMO Project Manager (i.e. Wayne)
  • EMO(LC) - EMO Legal Council (i.e. Janet)
  • EMO(IP) - EMO Intellectual Property Team
  • Proposer
  • Committer

Communication Channels

The communication channels used by the system are expected to change with time as technologies and communities evolve. Favoured technologies of the day are Twitter, RSS, and the eclipse.proposals forum.

Technology

Moved to Project Management Infrastructure/Technology Choices.

Themes

Moved to Project Management Infrastructure.

Requirements and Implementation

Moved to Project Management Infrastructure/Development.

Overview and Design

Moved to Project Management Infrastructure/Overview and Design.

Structure

Moved to Project Management Infrastructure/Development.

Application Lifecycle Management

Moved to Project Management Infrastructure/Development.

Schedule

April 2/2012 - Phase I beta-testing for projects.eclipse.org and PolarSys. Support for maintaining and disseminating project and release information, project proposals, and committer and project lead elections.

May 21/2012 - Phase II beta-testing for projects.eclipse.org and PolarSys. Support for user dashboard, email notification, simultaneous release tracking,

July 2/2012 - Go-live for Eclipse.org

References and Links

Retrieved from "https://wiki.eclipse.org/index.php?title=Project_Management_Infrastructure_Redesign_2011&oldid=298291"

This page was last modified 16:25, 17 April 2012 by Eclipsepedia anonymous user Unnamed Poltroon.

Back to the top