Re: [openstack-dev] [metrics] How to group activity in git/gerrit repositories

2014-06-18 Thread Thierry Carrez 
Stefano Maffulli wrote:
> On 06/16/2014 12:25 PM, Ilya Shakhat wrote:
>> Most of groups are created from the official programs
>> .yaml. Every program turns into item in the module
>> list (colored in violet), for example 'Nova Compute' is a group
>> containing 'nova', 'python-novaclient' and 'nova-specs'. Every type of
>> repo (integrated, incubated and others) turns into the project type, for
>> example 'integrated' type would contain all modules for a chosen release.
> 
> Thanks for clarifying that, I suspected that was the case. I don't think
> it makes much sense to count the *-specs repositories together with code
> in the program but probably they don't move the needle that much. In any
> case, I'm having specs not counted on Activity Board.

It all depends on the analysis you want to make, but counting -specs in
the same bucket as main code is not completely weird. Before specs
existed we would just have extra review iterations (or additional
patches) due to lack of upfront design. Now we formally design first,
but that's an integral part of feature development and it involves the
same group of people.

> I also am not fully convinced that the clients and their parent project
> should be counted together as I suspect different set of people work on
> them and they have different behavior. Again, the difference may be too
> small to justify adding complexity to the reports but I would like to
> see that difference quantified precisely first.

People working on clients are arguably a subset of people working on
main code, but they live under the same roof with the same big daddy. We
have been considering moving all client projects under a specific client
tools program though, so having a way to analyze their behavior
separately surely will help as a data point.

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [metrics] How to group activity in git/gerrit repositories

2014-06-17 Thread Jeremy Stanley 
On 2014-06-17 17:32:25 -0700 (-0700), Stefano Maffulli wrote:
[...]
> On the infra program, how do you separate OpenStack-related
> contributions to a repository like - repo: openstack-infra/gerrit, which
> is a fork of upstream gerrit, from the commits of upstream, non
> openstack people? In the past we've simply excluded from the count all
> the forks but wondered if there is a better way.

If you query gerrit for them, you will get results for any commits
which correspond to a change we added on the fork and no results
from the commits which were imported from the upstream project. Also
the git notes on commits we added will include identifying details
such as the URL to review.openstack.org, which should help to
differentiate them.
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [metrics] How to group activity in git/gerrit repositories

2014-06-17 Thread Stefano Maffulli 
On 06/16/2014 12:25 PM, Ilya Shakhat wrote:
> Most of groups are created from the official programs
> .yaml. Every program turns into item in the module
> list (colored in violet), for example 'Nova Compute' is a group
> containing 'nova', 'python-novaclient' and 'nova-specs'. Every type of
> repo (integrated, incubated and others) turns into the project type, for
> example 'integrated' type would contain all modules for a chosen release.

Thanks for clarifying that, I suspected that was the case. I don't think
it makes much sense to count the *-specs repositories together with code
in the program but probably they don't move the needle that much. In any
case, I'm having specs not counted on Activity Board.

I also am not fully convinced that the clients and their parent project
should be counted together as I suspect different set of people work on
them and they have different behavior. Again, the difference may be too
small to justify adding complexity to the reports but I would like to
see that difference quantified precisely first.

> Also Stackalytics has a few custom project types
> ,
> for example 'infra' is every project under 'openstack-infra' git, or
> 'documentation' which is the group 'documentation' from programs.yaml.

On the infra program, how do you separate OpenStack-related
contributions to a repository like - repo: openstack-infra/gerrit, which
is a fork of upstream gerrit, from the commits of upstream, non
openstack people? In the past we've simply excluded from the count all
the forks but wondered if there is a better way.

/stef

-- 
Ask and answer questions on https://ask.openstack.org

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [metrics] How to group activity in git/gerrit repositories

2014-06-17 Thread Daniel Izquierdo 

On 17/06/14 23:53, Daniel Izquierdo wrote:

On 16/06/14 21:25, Ilya Shakhat wrote:

Let me explain how Stackalytics grouping works.

Thanks for the clarification here.

Stefano, given that it's simple to group projects, a


Sorry about this incomplete email u_u. I was trying to wrap up ideas but 
well... fat trigger finger



Daniel.




Most of groups are created from the official programs 
.yaml. Every program turns into item in the 
module list (colored in violet), for example 'Nova Compute' is a 
group containing 'nova', 'python-novaclient' and 'nova-specs'. Every 
type of repo (integrated, incubated and others) turns into the 
project type, for example 'integrated' type would contain all modules 
for a chosen release.


Also Stackalytics has a few custom project types 
, 
for example 'infra' is every project under 'openstack-infra' git, or 
'documentation' which is the group 'documentation' from 
programs.yaml. Custom module groups 
 
are also possible, but actually used for stackforge projects only. 
Currently there's no group for python clients, but it would be very 
easy to add such group.


Thanks,
Ilya

2014-06-16 21:57 GMT+04:00 Stefano Maffulli >:


On Fri 13 Jun 2014 10:51:24 AM PDT, Stangel, Dan wrote:
> 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

It's a very neat grouping. It seems to me that the clients are
grouped
with their parent git/gerrit repo (nova with python-novaclient, under
'Compute' program) and Nova is shown alone. I don't see the python
clients individual repositories or grouped: is that correct?

For the quarterly reports I will need granularity because I believe
that clients have different dynamics than their parent project
(and if
that proves not to be the case, we can remove this complexity
later and
merge data).

can you share a concrete example of how you group things?

--
Ask and answer questions on https://ask.openstack.org

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Daniel Izquierdo Cortazar, PhD
Chief Data Officer
-
"Software Analytics for your peace of mind"
www.bitergia.com
@bitergia


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Daniel Izquierdo Cortazar, PhD
Chief Data Officer
-
"Software Analytics for your peace of mind"
www.bitergia.com
@bitergia

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [metrics] How to group activity in git/gerrit repositories

2014-06-17 Thread Daniel Izquierdo 

On 16/06/14 21:25, Ilya Shakhat wrote:

Let me explain how Stackalytics grouping works.

Thanks for the clarification here.

Stefano, given that it's simple to group projects, a


Most of groups are created from the official programs 
.yaml. Every program turns into item in the 
module list (colored in violet), for example 'Nova Compute' is a group 
containing 'nova', 'python-novaclient' and 'nova-specs'. Every type of 
repo (integrated, incubated and others) turns into the project type, 
for example 'integrated' type would contain all modules for a chosen 
release.


Also Stackalytics has a few custom project types 
, 
for example 'infra' is every project under 'openstack-infra' git, or 
'documentation' which is the group 'documentation' from programs.yaml. 
Custom module groups 
 
are also possible, but actually used for stackforge projects only. 
Currently there's no group for python clients, but it would be very 
easy to add such group.


Thanks,
Ilya

2014-06-16 21:57 GMT+04:00 Stefano Maffulli >:


On Fri 13 Jun 2014 10:51:24 AM PDT, Stangel, Dan wrote:
> 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

It's a very neat grouping. It seems to me that the clients are grouped
with their parent git/gerrit repo (nova with python-novaclient, under
'Compute' program) and Nova is shown alone. I don't see the python
clients individual repositories or grouped: is that correct?

For the quarterly reports I will need granularity because I believe
that clients have different dynamics than their parent project (and if
that proves not to be the case, we can remove this complexity
later and
merge data).

can you share a concrete example of how you group things?

--
Ask and answer questions on https://ask.openstack.org

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Daniel Izquierdo Cortazar, PhD
Chief Data Officer
-
"Software Analytics for your peace of mind"
www.bitergia.com
@bitergia

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [metrics] How to group activity in git/gerrit repositories

2014-06-16 Thread Ilya Shakhat 
Let me explain how Stackalytics grouping works.

Most of groups are created from the official programs 
.yaml. Every program turns into item in the module list (colored in
violet), for example 'Nova Compute' is a group containing 'nova',
'python-novaclient' and 'nova-specs'. Every type of repo (integrated,
incubated and others) turns into the project type, for example 'integrated'
type would contain all modules for a chosen release.

Also Stackalytics has a few custom project types
,
for example 'infra' is every project under 'openstack-infra' git, or
'documentation' which is the group 'documentation' from programs.yaml.
Custom module groups

are also possible, but actually used for stackforge projects only.
Currently there's no group for python clients, but it would be very easy to
add such group.

Thanks,
Ilya

2014-06-16 21:57 GMT+04:00 Stefano Maffulli :

> On Fri 13 Jun 2014 10:51:24 AM PDT, Stangel, Dan wrote:
> > 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
>
> It's a very neat grouping. It seems to me that the clients are grouped
> with their parent git/gerrit repo (nova with python-novaclient, under
> 'Compute' program) and Nova is shown alone. I don't see the python
> clients individual repositories or grouped: is that correct?
>
> For the quarterly reports I will need granularity because I believe
> that clients have different dynamics than their parent project (and if
> that proves not to be the case, we can remove this complexity later and
> merge data).
>
> can you share a concrete example of how you group things?
>
> --
> Ask and answer questions on https://ask.openstack.org
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [metrics] How to group activity in git/gerrit repositories

2014-06-16 Thread Stefano Maffulli 
On Fri 13 Jun 2014 10:51:24 AM PDT, Stangel, Dan wrote:
> 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

It's a very neat grouping. It seems to me that the clients are grouped 
with their parent git/gerrit repo (nova with python-novaclient, under 
'Compute' program) and Nova is shown alone. I don't see the python 
clients individual repositories or grouped: is that correct?

For the quarterly reports I will need granularity because I believe 
that clients have different dynamics than their parent project (and if 
that proves not to be the case, we can remove this complexity later and 
merge data).

can you share a concrete example of how you group things?

--
Ask and answer questions on https://ask.openstack.org

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [metrics] How to group activity in git/gerrit repositories

2014-06-13 Thread Stangel, Dan 
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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [metrics] How to group activity in git/gerrit repositories

2014-06-13 Thread Stefano Maffulli 
On 06/13/2014 05:57 AM, Doug Hellmann wrote:
> That section of the file used to be organized in to separate lists 
> for incubated, integrated, and "other" repositories. We changed it 
> when we started tracking the incubation and integration dates. So it 
> seems like just listing them under sahara as "other" would make 
> sense.

If I understand you correctly you'd have for Juno something like:

- OpenStack Software (top level overview):
   - integrated
* nova
* neutron
* cinder
* ...
* sahara
   ** sahara-other
* ...
   - incubated
* ...
   - other
  - clients
* sahara-client
  [... etc]

Looks a bit complicated to me: I wasn't considering that as an option.

It's worth reminding that the objective of the report is to discover,
highlight trends in each program, monitor the efficacy of  actions taken
to fuel our growth, capture early warning signals of distress in the
community. The grouping should be done among repositories and bug
trackers that share common characteristics.

For example, grouping integrated projects is valuable to calculate the
the median time for patches to merge across them all and compare them to
individual repositories. That's why I ask if repos openstack/sahara-*
should go with openstack/sahara and therefore their numbers aggregated
with the other integrated projects gerrit/git repos. Or, as you seem to
suggest, drop them into 'other' as these (ex.
openstack-dev/heat-cfnclient, openstack/ironic-python-agent,
openstack/tuskar-ui, openstack/sahara-image-elements etc) really have
more in common among each other than with their 'parent' project?
Does that make sense?

On 06/13/2014 08:52 AM, Thierry Carrez wrote:
> I would regroup devstack, QA, Infra and Release management into the 
> same "support" group. Not sure there is much value in presenting them
> distinctly.

Quite the other way around: it makes little sense to complicate the
analysis creating a group for these and it's easier to see them
separately. Also, I think there are different sets of people working on
them, it's more interesting to me to see them separately.

Cheers,
stef


PS in the past message I have *erroneously* included a couple of -specs
repositories: we're going to ignore those in our analysis, we're *not*
counting activity in those.

-- 
Ask and answer questions on https://ask.openstack.org

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [metrics] How to group activity in git/gerrit repositories

2014-06-13 Thread Thierry Carrez 
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)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [metrics] How to group activity in git/gerrit repositories

2014-06-13 Thread Doug Hellmann 
On Thu, Jun 12, 2014 at 8:07 PM, 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
>
> 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?

That section of the file used to be organized in to separate lists for
incubated, integrated, and "other" repositories. We changed it when we
started tracking the incubation and integration dates. So it seems
like just listing them under sahara as "other" would make sense.

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

I would think they would go with their parent program, no?

Doug

>
> Let me know what you think (tomorrow office hour, 11am PDT, is a good
> time to chat about this).
>
> Cheers,
> stef
>
> --
> Ask and answer questions on https://ask.openstack.org
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [metrics] How to group activity in git/gerrit repositories

2014-06-12 Thread Stefano Maffulli 
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

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).

Cheers,
stef

-- 
Ask and answer questions on https://ask.openstack.org

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev