Latest revision as of 13:49, 3 December 2013

Background

Our current dashboard is here:

http://dash.eclipse.org/dash/commits/web-app/

This is all based on some in-house code that was written a very long time ago. It was initially concerned exclusively with CVS activity and has been extended to support SVN and Git. We have since removed CVS. We currently do nothing with every other source of data.

You'll notice that it allows for some very dynamic querying. You can dig down into relatively detailed information, like number of commits by individuals affiliated with a specific company in a specific time-frame. I don't believe that we need 1:1 matching of functionality, but it would be good to be able to permit relatively easy drill-down functionality.

A committer is considered "active" if they have made at least one commit in the last three months. A committer is considered "participating" if they have made at least one commit in the last six months.

Where possible, we need to associate activity with member company affiliation.

Forges

We have three separate forges, Eclipse, PolarSys, and LocationTech. Each of these forges has its own repositories, bugzilla instance, mailing list domain, forums, etc. We may add additional forges in the future.

Projects

Eclipse Foundation forges host multiple projects. Eclipse projects are structured hierarchically. At the top of the hierarchy is a collection of "top level" projects, each having zero or more subprojects. Some subprojects have subprojects of their own. The project nesting level never goes more than three levels deep. The Eclipse forge has several top-level projects; LocationTech and PolarSys each have one. All top-level projects have subprojects. Some subprojects have their own subprojects.

Each project has its own resources. Some are dedicated and some are potentially shared.

A project has:

• exactly one group of committers;
• its own Bugzilla Product and component (we're phasing out project-specific components);
• zero or more Git repositories;
• at most one SVN repository;
• zero or more mailing lists (Mailman);
• zero or more forums (FudForum);
• a download directory;
• zero or more jobs on the shared Hudson instance;
• a dedicated Hudson instance (HIPP)

Project resources are generally project-specific, but there are cases where projects share resources like mailing lists and downloads. Some projects, for example, opt to roll their downloads into the parent project's downloads. In this event, distinguishing the downloads sourced from a particular subproject is is not generally possible.

Sources of Data

The central authority regarding the sources of data is the Project Management Infrastructure (PMI). Most of the data managed by the PMI is provided by project members themselves. A project may, for example, opt to not include a Git repository in their official list. We generally discourage this, but if a project so-opts, we honour that decision.

Project Metadata

We have a currently-undocumented project metadata API that provides forge-specific project metadata:

• http://projects.eclipse.org/json/projects/all
• http://polarsys.org/json/projects/all
• http://locationtech.org/json/projects/all

If necessary, we can roll these three queries into a single query that runs across all forges; in that event, we'd make the forge-associations explicit in the project metadata API output.

Below is a example of the data provided by this API. This example only shows a single project and only relevant data (much more data is provided, including, for example, the project description).

{
    "projects": {
        "technology.egit": {
            "bugzilla": [
                {
                    "component": "", 
                    "create_url": "https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit", 
                    "product": "EGit", 
                    "query_url": "https://bugs.eclipse.org/bugs/buglist.cgi?product=EGit"
                }
            ],
            "dev_list": {
                "email": "egit-dev@eclipse.org", 
                "name": "egit-dev", 
                "url": "https://dev.eclipse.org/mailman/listinfo/egit-dev"
            }, 
            "forums": [
                {
                    "description": "Questions and technical discussions about how to use the Git team provider (EGit)", 
                    "name": "eclipse.egit", 
                    "url": "http://www.eclipse.org/forums/eclipse.egit"
                }
            ], 
            "id": [
                {
                    "value": "technology.egit"
                }
            ],
            "mailing_lists": [
                {
                    "email": "egit-build@eclipse.org", 
                    "name": "egit-build", 
                    "url": "https://dev.eclipse.org/mailman/listinfo/egit-build"
                }
            ], 
            "marketplace": [
                {
                    "attributes": [], 
                    "title": "EGit in Eclipse Marketplace", 
                    "url": "http://marketplace.eclipse.org/node/1336"
                }
            ], 
            "parent_project": [
                {
                    "id": "technology"
                }
            ], 
            "source_repo": [
                {
                    "name": "egit", 
                    "path": "/gitroot/egit/egit.git", 
                    "type": "git", 
                    "url": "http://git.eclipse.org/c/egit/egit.git"
                }, 
                {
                    "name": "egit-github", 
                    "path": "/gitroot/egit/egit-github.git", 
                    "type": "git", 
                    "url": "http://git.eclipse.org/c/egit/egit-github.git"
                }, 
                {
                    "name": "egit-pde", 
                    "path": "/gitroot/egit/egit-pde.git", 
                    "type": "git", 
                    "url": "http://git.eclipse.org/c/egit/egit-pde.git"
                }
            ], 
            "state": [
                {
                    "value": "Regular"
                }
            ]
        }
    }
}

The content is generated directly from live data. The nature of the data is, I believe, evident from the structure itself. As we move forward with the dashboard implementation, we will stabilize and fully document this API.

Projects have an identifierthat captures the location of the project in the hierarchy. The EGit project, for example, is identified by "technology.egit" which indicates that it is a subproject of the "Technology" top-level project. The identifier can change when a project moves (the "EMF Store" project recently changed position in the project hierarchy from modeling.emft.emf-store to modeling.emfstore); in this case, the project is the same, it just has a different identifier.

If it is helpful, we can further disambiguate projects by including the forge identity in the identifier. We can, for example, use identifiers like "eclipse.technology.egit" and "locationtech.technology.udig").

We can provide the project data in other forms as necessary.

Mailing Lists

We use standard Mailman to for mailing lists. Direct access to MBOX files is possible only from within the Eclipse Foundation intranet.

Forums

We use FudForum for project forums.

Issues

We use Bugzilla for issue/bug tracking. We do not currently implement the Bugzilla RPC API. Direct access to the MySQL database running Bugzilla is possible from within the Eclipse Foundation intranet.

Source Code

Most projects use Git. We have some older projects in the Eclipse Forge that still use SVN, but the use of SVN is deprecated. All source code repositories are publicly accessible.

Some projects are starting to use GitHub as their primary source code management tool.

Project Membership

The identity of the developers who have commit access to the the project is not included in the project metadata API. The project metadata API is public; due to privacy concerns, we do not include committer information (which contains email addresses and company affiliations) via public API. We have a second API that can only be accessed from within the Eclipse Foundation infrastructure.

TBD

General

Must-have Features

• Automatic detection and inclusion of new sources of data

Forge Dashboard

Each of the separate forges needs its own independent dashboard. We'd also like a consolidated dashboard view. There is no specific requirement that forge-specific dashboards be provided by separate implementations; we do, however, need to be able to view and access forge-specific data separately.

• Liveliness assessment

Project Dashboard

Must-have Features

• Project-specific data
  • Ability to browse metrics for individual projects
• Top-level Project Overview
  • A top-level project can quickly review the liveliness of all nested projects
  • Consolidated rendering of all metrics for each project
• Embeddable charts for project pages (e.g. https://projects.eclipse.org/projects/technology.egit)
  • Lifetime commit activity
  • Individual commit activity (active contributors)
  • Company commit activity (member companies with active contributors)
  • Lifetime forum/mailing list activity
  • Bugzilla activity

Nice-to-have Features

• Identify contributor links between projects
  • Projects are considered contributor-related if they share contributors (i.e. if one or more contributors contribute to both projects)
  • For any given project, identify all contributor-related projects.

IP Logs

We also use data collected by Dash to populate our IP Logs. e.g.

https://eclipse.org/projects/ip_log.php?id=rt.ecf We use dash data to determine the active committers (past and present). Basically any project committer who has ever made a single commit appears in the "active" table; all others appear in the "never active" table. The "Contributors and their Contributions" section is populated from the Git repositories and Bugzilla. For Git, we include contributions made by non-committers. From Bugzilla, we identify bug attachments marked with the iplog+ flag.

I'd also like to add some aggregation charts.

Does it make sense to include downloads and builds into the metrics gathering? e.g. gather Hudson build statistics, or include the currency of downloads in the livliness considerations?