Re: [openstack-dev] [metrics] How to group activity in git/gerrit repositories
Stefano Maffulli wrote: On 06/16/2014 12:25 PM, Ilya Shakhat wrote: Most of groups are created from the official programs http://programs.yaml.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
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 http://programs.yaml.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 https://github.com/stackforge/stackalytics/blob/master/etc/default_data.json#L7833-L7879, for example 'infra' is every project under 'openstack-infra' git, or 'documentation' which is the group 'documentation' from programs.yaml. Custom module groups https://github.com/stackforge/stackalytics/blob/master/etc/default_data.json#L7749-L7778 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 stef...@openstack.org mailto:stef...@openstack.org: 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 mailto: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
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 http://programs.yaml.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 https://github.com/stackforge/stackalytics/blob/master/etc/default_data.json#L7833-L7879, for example 'infra' is every project under 'openstack-infra' git, or 'documentation' which is the group 'documentation' from programs.yaml. Custom module groups https://github.com/stackforge/stackalytics/blob/master/etc/default_data.json#L7749-L7778 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 stef...@openstack.org mailto:stef...@openstack.org: 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 mailto: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
On 06/16/2014 12:25 PM, Ilya Shakhat wrote: Most of groups are created from the official programs http://programs.yaml.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 https://github.com/stackforge/stackalytics/blob/master/etc/default_data.json#L7833-L7879, 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
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
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
Let me explain how Stackalytics grouping works. Most of groups are created from the official programs http://programs.yaml .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 https://github.com/stackforge/stackalytics/blob/master/etc/default_data.json#L7833-L7879, for example 'infra' is every project under 'openstack-infra' git, or 'documentation' which is the group 'documentation' from programs.yaml. Custom module groups https://github.com/stackforge/stackalytics/blob/master/etc/default_data.json#L7749-L7778 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 stef...@openstack.org: 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
On Thu, Jun 12, 2014 at 8:07 PM, Stefano Maffulli stef...@openstack.org 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
Re: [openstack-dev] [metrics] How to group activity in git/gerrit repositories
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
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
[openstack-dev] [metrics] How to group activity in git/gerrit repositories
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
