Open Stack

Hi Stef,

On Thu, 2014-06-12 at 17:07 -0700, Stefano Maffulli wrote:
> we're working on a quarterly report of activities in all our git and
> gerrit repositories to understand the dynamics of contributions across
> different dimensions. This report will be similar to what Bitergia
> produced at release time.
> 
> I'd like to discuss more widely the format of how to meaningfully group
> the information presented. One basic need is to have a top level view
> and then drill down based on the release status of each project. A
> suggested classification would be based on the programs.yaml file:
> 
> - OpenStack Software (top level overview):
>    - integrated
>    - incubated
>    - clients
>    - other:
>        devstack
>        deployment
>        common libraries
> - OpenStack Quality Assurance
> - OpenStack Documentation
> - OpenStack Infrastructure
> - OpenStack Release management
> 
> It seems easy but based on that grouping, integrated and incubated git
> repositories are easy to spot in programs.yaml (they have
> integrated-since attribute).
> 
> Let's have the Sahara program as an example:
> 
>   projects:
>     - repo: openstack/sahara
>       incubated-since: icehouse
>       integrated-since: juno
>     - repo: openstack/python-saharaclient
>     - repo: openstack/sahara-dashboard
>     - repo: openstack/sahara-extra
>     - repo: openstack/sahara-image-elements
>     - repo: openstack/sahara-specs
> 
> So, for the OpenStack Software part:
> * openstack/sahara is integrated in juno and incubated since icehouse.
> * Then clients: python-saharaclient is easy to spot. Is it standard and
> accepted practice that all client projects are called
> python-$PROGRAM-NAMEclient?
> * And what about the rest of the sahara-* projects: where would they go?
> with openstack/sahara? or somewhere else, in others? devstack?
> common-libraries?
> 
> Other repositories for which I have no clear classification:
> 
>     - repo: openstack/swift-bench
>     - repo: openstack/django_openstack_auth
>     - repo: openstack/tuskar-ui
>     - repo: openstack/heat-cfntools
>     - repo: openstack/heat-specs
>     - repo: openstack/heat-templates
>     - repo: openstack-dev/heat-cfnclient
>     - repo: openstack/trove-integration
>     - repo: openstack/ironic-python-agent
>     - repo: stackforge/kite
> 
> Any suggestions on how you would like to see these classified: with
> together with the integrated/incubated 'parent' program (sahara with
> sahara-dashboard, sahara-extra etc  or separately under 'other'? Or
> they're all different and we need to look at them one by one?
> 
> Let me know what you think (tomorrow office hour, 11am PDT, is a good
> time to chat about this).

You can also refer to the example of Stackalytics, who have created
their own hierarchy and groupings for metrics reporting:
https://github.com/stackforge/stackalytics/blob/master/etc/default_data.json

I have found this grouping to be pretty logical and useful.

For my own internal metrics, I also rely on the programs.yaml file
organization, and / or the "Programs" wiki page
https://wiki.openstack.org/wiki/Programs where they differ.

Further, I group all the "other" projects that do not clearly fit into a
separate "bucket" grouping, until they either disappear or become
incorporated into other groupings.

Dan