Open Stack

Stefano Maffulli wrote:
> Hello folks,
> 
> 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

I would regroup devstack, QA, Infra and Release management into the same
"support" group. Not sure there is much value in presenting them distinctly.

> 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?

Interesting to note that most of those extra projects should disappear
soon, as they get consumed by other projects (for example
sahara-dashboard going into horizon). In the mean time, I think they can
go to your "other" category. That's how they are classified in
programs.yaml.


> 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

All "other". To avoid creating so many subcategories in "other", I would
not have any subcategory there and just lump them all in the same
category. That's about as relevant as lumping all integrated projects
work into the same "integrated" category, anyway.

Cheers,

-- 
Thierry Carrez (ttx)