Re: [openstack-dev] [Stackalytics] How to deploy a "stackalytics"

On 2017-05-24 20:47:22 +0800 (+0800), Hanxi Liu wrote: [...] > I want to know if there is some other ways to deploy a > "stackalytics" in my environment. [...] The OpenStack Infrastructure team maintains a Puppet module which we use for deploying and maintaining the http://stackalytics.openstack.o

[openstack-dev] [Stackalytics] How to deploy a "stackalytics"

Hi folks, I got stuck after I installed stackalytics. The stackalytics-dashboard doesn't work. The main process followed the guide[1]. I want to know if there is some other ways to deploy a "stackalytics" in my environment. Stackalytics wiki[2] is the only guide I can find. I'm very appreciate it

Re: [openstack-dev] [stackalytics] user correction seems not effective

ent: Monday, March 20, 2017 8:47:30 AM To: shak...@gmail.com<mailto:shak...@gmail.com> Cc: OpenStack Development Mailing List (not for usage questions); 张玉军 Subject: [openstack-dev] [stackalytics] user correction seems not effective Hi, Ilya I submitted a patch for user correction[1] s

Re: [openstack-dev] [stackalytics] user correction seems not effective

); 张玉军 *Subject:* [openstack-dev] [stackalytics] user correction seems not effective Hi, Ilya I submitted a patch for user correction[1] several months ago. It is supposed to reset the Email list of user `zhangyujun`. But it seems not effective from the response of stackalytics api. cur

Re: [openstack-dev] [stackalytics] user correction seems not effective

usage questions); 张玉军 Subject: [openstack-dev] [stackalytics] user correction seems not effective Hi, Ilya I submitted a patch for user correction[1] several months ago. It is supposed to reset the Email list of user `zhangyujun`. But it seems not effective from the response of stackalytics api.

[openstack-dev] [stackalytics] user correction seems not effective

Hi, Ilya I submitted a patch for user correction[1] several months ago. It is supposed to reset the Email list of user `zhangyujun`. But it seems not effective from the response of stackalytics api. curl http://stackalytics.com/api/1.0/users/zhangyujun {"user": {"launchpad_id": "zhangyujun", "us

Re: [openstack-dev] [stackalytics][neutron] some big tent projects included into 'Neutron Official'

Any update? The issue still seems to be present. On Mon, Nov 28, 2016 at 6:42 AM, Ilya Shakhat wrote: > Hi Ihar, > > This sounds like a bug - the contents of official group should be in sync > with the governance repo. > I'll take a look what went wrong with it. > > Thanks, > Ilya > > 2016-11-26

[openstack-dev] [stackalytics] how to remove obsoleted email address from one id

Stackalytics cores: I reported a bug on ownership of commits in stackalytics months ago[1]. It seems to be caused by obsoleted email address in user default data. In `user_processor`, it merges email addresses from `default_data.json` to runtime storage[2]. It seems removing email address from us

Re: [openstack-dev] [stackalytics][neutron] some big tent projects included into 'Neutron Official'

Hi Ihar, This sounds like a bug - the contents of official group should be in sync with the governance repo. I'll take a look what went wrong with it. Thanks, Ilya 2016-11-26 2:28 GMT+03:00 Ihar Hrachyshka : > Hi all, > > I am looking at http://stackalytics.com/?project_type=openstack&module= >

[openstack-dev] [stackalytics][neutron] some big tent projects included into 'Neutron Official'

Hi all, I am looking at http://stackalytics.com/?project_type=openstack&module=neutron-group and I see some reviews counted for projects that are for long out of neutron stadium (f.e. dragonflow or kuryr or networking-hyperv). How can we get them excluded from the official neutron stats? I’ve

Re: [openstack-dev] [stackalytics]

Roman, There are certainly exist a bug in stackalytics [1]. Current contribution > to different openstack/* projects was counted for deb-* . Now all affected > commit records on stackalytics are removed from deb-* projects, but they > should be moved to proper non-deb projects. Is there any one

[openstack-dev] [stackalytics]

Hi, There are certainly exist a bug in stackalytics [1]. Current contribution to different openstack/* projects was counted for deb-* . Now all affected commit records on stackalytics are removed from deb-* projects, but they should be moved to proper non-deb projects. Is there any one how could

Re: [openstack-dev] [stackalytics] [deb] [packaging] OpenStack contribution stats skewed by deb-* projects

On 09/21/2016 03:44 PM, Ian Cordasco wrote: > Thomas, > > As you already pointed out, where it matters, the analysis of > commits is correct. I'm sure the Stackalytics team has prioritized > this as they see appropriate. I've asked because I would like to attempt to fix it myself, considering Ily

Re: [openstack-dev] [stackalytics] [deb] [packaging] OpenStack contribution stats skewed by deb-* projects

On 2016-09-21 22:04:46 +0200 (+0200), Thierry Carrez wrote: > Thomas Goirand wrote: > > I don't understand why Stackalytics has it wrong, when the electorate > > script for the PTL election is correct. Here's the script for getting > > commits: > > https://github.com/openstack-infra/system-config/b

Re: [openstack-dev] [stackalytics] [deb] [packaging] OpenStack contribution stats skewed by deb-* projects

Thomas Goirand wrote: > I don't understand why Stackalytics has it wrong, when the electorate > script for the PTL election is correct. Here's the script for getting > commits: > https://github.com/openstack-infra/system-config/blob/master/tools/owners.py AFAIK that is because Stackalytics works f

Re: [openstack-dev] [stackalytics] [deb] [packaging] OpenStack contribution stats skewed by deb-* projects

  -Original Message- From: Thomas Goirand Reply: OpenStack Development Mailing List (not for usage questions) Date: September 21, 2016 at 08:40:07 To: OpenStack Development Mailing List (not for usage questions) Subject:  Re: [openstack-dev] [stackalytics] [deb] [packaging] OpenStack

Re: [openstack-dev] [stackalytics] [deb] [packaging] OpenStack contribution stats skewed by deb-* projects

On 09/20/2016 10:30 PM, Ilya Shakhat wrote: > Hi, > > tldr; Commits stats are significantly skewed by deb-* projects > (http://stackalytics.com/?metric=commits&module=packaging-deb-group) > > By default Stackalytics processes commits from project's master branch. > For some "old core" projects th

Re: [openstack-dev] [stackalytics] [deb] [packaging] OpenStack contribution stats skewed by deb-* projects

2016-09-21 14:37 GMT+03:00 Thierry Carrez : > Ilya Shakhat wrote: > > Hi, > > > > tldr; Commits stats are significantly skewed by deb-* projects > > (http://stackalytics.com/?metric=commits&module=packaging-deb-group) > > > > By default Stackalytics processes commits from project's master branch.

Re: [openstack-dev] [stackalytics] [deb] [packaging] OpenStack contribution stats skewed by deb-* projects

Ilya Shakhat wrote: > Hi, > > tldr; Commits stats are significantly skewed by deb-* projects > (http://stackalytics.com/?metric=commits&module=packaging-deb-group) > > By default Stackalytics processes commits from project's master branch. > For some "old core" projects there is configuration to

[openstack-dev] [stackalytics] [deb] [packaging] OpenStack contribution stats skewed by deb-* projects

Hi, tldr; Commits stats are significantly skewed by deb-* projects ( http://stackalytics.com/?metric=commits&module=packaging-deb-group) By default Stackalytics processes commits from project's master branch. For some "old core" projects there is configuration to process stable branches as well.

Re: [openstack-dev] [stackalytics]many projects missing in the "others" category

On 05/03/2016 09:11 AM, joehuang wrote: > Hello, > > Very sad to know that some projects are missing again in the "others" > category. When I want to cite some statistic data for Tricircle core reviewer > nomination, can't find the data for many "others" projects which usually are > listed "oth

Re: [openstack-dev] [stackalytics]many projects missing in the "others" category

AFAIK the Tricircle is one of them. [1] How can we fix it out? [1] http://stackalytics.com/report/contribution/tricircle/90 Cheers, S On Tue, May 3, 2016 at 10:11 PM, joehuang wrote: > Hello, > > Very sad to know that some projects are missing again in the "others" > category. When I want to c

[openstack-dev] [stackalytics]many projects missing in the "others" category

Hello, Very sad to know that some projects are missing again in the "others" category. When I want to cite some statistic data for Tricircle core reviewer nomination, can't find the data for many "others" projects which usually are listed "others" category. Is there any new rule in Stackalytics

Re: [openstack-dev] [stackalytics] Proposal for some code/feature changes

Hi Nikhil, 2016-04-12 5:59 GMT+03:00 Nikhil Komawar : > Hello, > > I was hoping to make some changes to the stackalytics dashboard > specifically of this type [1] following my requested suggestions here > [2]; possibly add a few extra columns for +0s and just Bot +1s. I think > having this info g

[openstack-dev] [stackalytics] Proposal for some code/feature changes

Hello, I was hoping to make some changes to the stackalytics dashboard specifically of this type [1] following my requested suggestions here [2]; possibly add a few extra columns for +0s and just Bot +1s. I think having this info gives much clearer picture of the kind of reviews someone is/wants t

Re: [openstack-dev] [stackalytics] Review metrics: average numbers

Hi Mike, Not 100% sure what you're asking for but have you seen these stats? http://russellbryant.net/openstack-stats/ Alexis (lxsli) -- Nova developer, Hewlett-Packard Limited. Registered Office: Cain Road, Bracknell, Berkshire RG12 1HN. Registered Number: 00690597 England VAT number: GB

Re: [openstack-dev] [stackalytics] [metrics] Review metrics: average numbers

Jesus, thanks for sharing this. Looks like you've got quite comprehensive data analysis tool for code review. Is there a way to get Fuel added somehow.. ? Ilya, > Do you mean to calculate stats not only for open, but also for those that are already closed? Yes. I need to calculate stats for ALL, i

Re: [openstack-dev] [stackalytics] [metrics] Review metrics: average numbers

Hi Mike, > Do I understand right, that average numbers > > here are calculated out of open reviews, not total number of reviews? Average numbers are calculated for reviews within the group. But I'd expect them to be "time since the last vote", not "time when patch proposed" as they do now. > Th

Re: [openstack-dev] [stackalytics] [metrics] Review metrics: average numbers

Hi, Mike, I'm not sure what you are looking for exactly, but maybe you can have a look at the quarterly reports. AFAIK, currently there is none specific to Fuel, but for example for Nova, you have: http://activity.openstack.org/dash/reports/2015-q3/pdf/projects/nova.pd f In page 6, you have "tim

[openstack-dev] [stackalytics] Review metrics: average numbers

Hi stackers, I have a question about Stackalytics. I'm trying to get some more data from code review stats. For Fuel, for instance, http://stackalytics.com/report/reviews/fuel-group/open shows some useful stats. Do I understand right, that average numbers here are calculated out of open reviews, no

Re: [openstack-dev] Stackalytics 0.9: new features and improvements

On 23/10/15 12:26 +0300, Ilya Shakhat wrote: Hi all,  During the last month we've made a number of changes and improvements in Stackalytics that deserve version tag and special announcement. The most important feature is tracking history of official projects list - highly demanded after shift to

Re: [openstack-dev] Stackalytics 0.9: new features and improvements

On 10/23/2015 05:26 AM, Ilya Shakhat wrote: Hi all, During the last month we've made a number of changes and improvements in Stackalytics that deserve version tag and special announcement. The most important feature is tracking history of official projects list - highly demanded after shift to '

[openstack-dev] Stackalytics 0.9: new features and improvements

Hi all, During the last month we've made a number of changes and improvements in Stackalytics that deserve version tag and special announcement. The most important feature is tracking history of official projects list - highly demanded after shift to 'big tent' model. The full list of changes bel

Re: [openstack-dev] [stackalytics] Broken stats after project rename

Hi Jesse, Thanks for letting know. Stackalytics team will fix the issue during the day. --Ilya 2015-09-30 12:19 GMT+03:00 Jesse Pretorius : > Hi everyone, > > After the rename of os-ansible-deployment to openstack-ansible it appears > that all git-related stats (eg: commits) prior to the rename

[openstack-dev] [stackalytics] Broken stats after project rename

Hi everyone, After the rename of os-ansible-deployment to openstack-ansible it appears that all git-related stats (eg: commits) prior to the rename have been lost. http://stackalytics.com/?metric=commits&module=openstack-ansible Can anyone assist with rectifying this? -- Jesse Pretorius IRC: o

Re: [openstack-dev] [Stackalytics] Complementary projects

On 06/19/2015 11:40 AM, Jay Pipes wrote: > On 06/19/2015 10:31 AM, Joe Gordon wrote: >> On Jun 19, 2015 3:56 PM, "Jay Pipes" > > wrote: >> > >> > On 06/19/2015 09:19 AM, Ilya Shakhat wrote: >> >> >> >> Some reasons of having complementary projects in Stackalytics: >>

Re: [openstack-dev] [Stackalytics] Complementary projects

On 06/19/2015 10:31 AM, Joe Gordon wrote: On Jun 19, 2015 3:56 PM, "Jay Pipes" mailto:jaypi...@gmail.com>> wrote: > > On 06/19/2015 09:19 AM, Ilya Shakhat wrote: >> >> Some reasons of having complementary projects in Stackalytics: >> * to compare efforts in other communities with OpenStack

Re: [openstack-dev] [Stackalytics] Complementary projects

On Jun 19, 2015 3:56 PM, "Jay Pipes" wrote: > > On 06/19/2015 09:19 AM, Ilya Shakhat wrote: >> >> Some reasons of having complementary projects in Stackalytics: >> * to compare efforts in other communities with OpenStack - just to >> feed curiosity on what is larger OpenStack or Kubernetes? >>

Re: [openstack-dev] [Stackalytics] Complementary projects

On 06/19/2015 09:19 AM, Ilya Shakhat wrote: Some reasons of having complementary projects in Stackalytics: * to compare efforts in other communities with OpenStack - just to feed curiosity on what is larger OpenStack or Kubernetes? * to light interest to contribute to projects that OpenStack

Re: [openstack-dev] [Stackalytics] Complementary projects

Some reasons of having complementary projects in Stackalytics: * to compare efforts in other communities with OpenStack - just to feed curiosity on what is larger OpenStack or Kubernetes? * to light interest to contribute to projects that OpenStack depends on, like OVS and Ansible. * to keep an

Re: [openstack-dev] [Stackalytics] Complementary projects

Paul Belanger wrote: > I am wondering the reason for the complementary projects listing[1] in > Stackalytics? Specifically, why does stackalytics-processor import > docker and cloudfoundry projects into the stats? > > [1] http://stackalytics.com/?project_type=complementary&metric=commits It's no

[openstack-dev] [Stackalytics] Complementary projects

Greetings, I am wondering the reason for the complementary projects listing[1] in Stackalytics? Specifically, why does stackalytics-processor import docker and cloudfoundry projects into the stats? [1] http://stackalytics.com/?project_type=complementary&metric=commits __

[openstack-dev] Stackalytics 0.6 released!

Hi Stackers, More then a year ago Mirantis announced Stackalytics as a public resource for the OpenStack community. Initially it was an internal tool for our performance tracking, but later resource became de-facto standard for measuring contribution statistics. We've started with several POCs on

Re: [openstack-dev] [stackalytics] Pull request on default_data.json (addition of a domain)

Tom, Thanks for the link & tips, I'll try with these instructions. Best regards, Yuko -Original Message- From: Tom Fifield [mailto:t...@openstack.org] Sent: Thursday, February 27, 2014 11:16 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [stackalyt

Re: [openstack-dev] [stackalytics] Pull request on default_data.json (addition of a domain)

Hi Fukuda san, You will probably receive an automated message like this soon, but: stackforge/stackalytics uses Gerrit for code review, and does not accept pull requests on github. To commit your change, you will need to follow the instructions on the OpenStack Gerrit Workflow: https://wiki.

[openstack-dev] [stackalytics] Pull request on default_data.json (addition of a domain)

Hi, I want to add the domain of my email address onto the stackalytics "default_data.json" file. I have made the necessary additions, and created "patch-1". Can someone with the credentials approve and merge? (my ID is fukuday) Thanks in advance, Yuko _

Re: [openstack-dev] Stackalytics 0.4 released! [metrics]

On 12/12/2013 07:49 AM, Ilya Shakhat wrote: > Stackalytics team is happy to announce the release of version 0.4. [...] Good job Ilya, congratulations on the release. I may not be able to join the meeting (too early for me) so I leave here some feedback for you. I like the new punchcards in the pe

Re: [openstack-dev] Stackalytics 0.4 released!

Hello , On Thu, Dec 12, 2013 at 10:11 PM, Monty Taylor wrote: > > > On 12/12/2013 04:49 PM, Ilya Shakhat wrote: >> Hello everyone! >> >> Stackalytics team is happy to announce the release of version 0.4. This >> release is completely dedicated to different types of reports. We added >> highly dem

Re: [openstack-dev] Stackalytics 0.4 released!

On 12/12/2013 04:49 PM, Ilya Shakhat wrote: > Hello everyone! > > Stackalytics team is happy to announce the release of version 0.4. This > release is completely dedicated to different types of reports. We added > highly demanded top reviewers chart acknowledged as an essential tool > for findin

[openstack-dev] Stackalytics 0.4 released!

Hello everyone! Stackalytics team is happy to announce the release of version 0.4. This release is completely dedicated to different types of reports. We added highly demanded top reviewers chart acknowledged as an essential tool for finding most active reviewers (ex. http://stackalytics.com/repor

Re: [openstack-dev] [stackalytics] Official Programs tag?

On 11/01/2013 12:42 PM, Thierry Carrez wrote: > I think the following objective groupings make sense: > > Official > * Integrated (= commonly-released, server) projects (Nova, Swift... up > to Trove) > * Incubated (Marconi, Savanna...) > * All projects from all official programs (includes client

Re: [openstack-dev] [stackalytics] Official Programs tag?

Ilya Shakhat wrote: > Currently the grouping is two-layer: the higher is to split between > openstack-hosted and stackforge-hosted projects, the lower is to split > core, incubation, docs, etc. The grouping may be not so accurate since > it needs to comply with the latest changes in integrated / in

Re: [openstack-dev] [stackalytics] Official Programs tag?

Sean, Currently the grouping is two-layer: the higher is to split between openstack-hosted and stackforge-hosted projects, the lower is to split core, incubation, docs, etc. The grouping may be not so accurate since it needs to comply with the latest changes in integrated / incubated projects (bug

Re: [openstack-dev] [stackalytics] Official Programs tag?

On 28 October 2013 04:32, Sean Dague wrote: > I've been looking at the stackalytics code and one of the areas that I think > stackalytics has a structural issue is around the project_group tag. > > The existing project_group tags of "core", "incubation", "documentation", > "infrastructure", and "o

[openstack-dev] [stackalytics] Official Programs tag?

I've been looking at the stackalytics code and one of the areas that I think stackalytics has a structural issue is around the project_group tag. The existing project_group tags of "core", "incubation", "documentation", "infrastructure", and "other" are all fine and good, however none of these

[openstack-dev] [stackalytics] team meeting minutes October 21

Thanks everyone who have joined Stackalytics meeting. The team reviewed and prioritized blueprints. For the next 0.4 release the following bps were selected: * module-review-backlog-stats - reports on review activit

[openstack-dev] [Stackalytics] 0.3 release

Hello everyone! Together with Havana we are glad to present a new version of Stackalytics - 0.3. In this release the service is extended by email and blueprint processing. Blueprints are metered by popularity - the number of times they are mentioned in either emails o

[openstack-dev] [Stackalytics] 0.2 release

Hello everyone! We are excited to present the new release of Stackalytics- 0.2. One of major features of this release is review processing. It gives data on who reviews most, distribution of reviews by engineers or by modules, what is the ratio of positive to negative

Re: [openstack-dev] [Stackalytics] 0.1 release [metrics]

On Fri, 2013-07-26 at 07:40 -0700, Thierry Carrez wrote: > Stefano Maffulli wrote: > > On 07/23/2013 07:25 AM, Roman Prykhodchenko wrote: > >> I still think counting lines of code is evil because it might encourage > >> some developers to write longer code just for statistics. > > > > Data becomes

Re: [openstack-dev] [Stackalytics] 0.1 release [metrics]

Stefano Maffulli wrote: > On 07/23/2013 07:25 AM, Roman Prykhodchenko wrote: >> I still think counting lines of code is evil because it might encourage >> some developers to write longer code just for statistics. > > Data becomes evil when you decide to use them for evil purposes :) I > don't thin

Re: [openstack-dev] [Stackalytics] 0.1 release [metrics]

On 07/23/2013 07:25 AM, Roman Prykhodchenko wrote: > I still think counting lines of code is evil because it might encourage > some developers to write longer code just for statistics. Data becomes evil when you decide to use them for evil purposes :) I don't think that lines of code is a bad metr

Re: [openstack-dev] [Stackalytics] 0.1 release

Thank you Gareth, this makes total sense. We will make sure to include this in the next release. Alex Freedland Mirantis, Inc. On Thu, Jul 25, 2013 at 3:21 AM, Gareth wrote: > A suggestion: > > sort bugs number as int is much better than string, because '112' < '8' > but actually 112 > 8 >

Re: [openstack-dev] [Stackalytics] 0.1 release

A suggestion: sort bugs number as int is much better than string, because '112' < '8' but actually 112 > 8 http://stackalytics.com/companies/unitedstack On Thu, Jul 25, 2013 at 9:31 AM, Alex Freedland wrote: > Roman, > > Thank you for your comment. I agree that is should not be the only way to

Re: [openstack-dev] [Stackalytics] 0.1 release

Roman, Thank you for your comment. I agree that is should not be the only way to look at the statistics and that is why Stackalytics also measures the number of contributions and soon will add the number of reviews. I do, however, think it a useful statistic as because not all commits are created

Re: [openstack-dev] [Stackalytics] 0.1 release

I still think counting lines of code is evil because it might encourage some developers to write longer code just for statistics. On Jul 23, 2013, at 16:58 , Herman Narkaytis wrote: > Hello everyone! > > Mirantis is pleased to announce the release of Stackalytics 0.1. You can find > complete

[openstack-dev] [Stackalytics] 0.1 release

Hello everyone! Mirantis is pleased to announce the release of Stackalytics 0.1. You can find complete details on the Stackalytics wiki page, but here are the brief release notes: - Changed