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

[Jeremy Stanley]

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.org/ site:

https://git.openstack.org/cgit/openstack-infra/puppet-stackalytics/

Maybe that's useful to you?
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Hanxi Liu]

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
if you can help.

[1]https://wiki.openstack.org/wiki/Stackalytics/HowToRun
[2]https://wiki.openstack.org/wiki/Stackalytics

Best regards,

Hanxi Liu

(IRC:lhx_)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Trinath Somanchi]

I’m referring to, https://review.openstack.org/#/c/446942/1


/ Trinath Somanchi.


From: Yujun Zhang (ZTE) [mailto:zhangyujun+...@gmail.com]
Sent: Monday, March 20, 2017 11:00 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>; shak...@gmail.com
Cc: 张玉军 <yujun.zh...@easystack.cn>
Subject: Re: [openstack-dev] [stackalytics] user correction seems not effective

Hi, Trinath

What failure are you referring to exactly? It seems all jobs passed normally.

I know there are some error message in the console logs, but that seems to be 
expected failures for negative test cases.

On Mon, Mar 20, 2017 at 12:16 PM Trinath Somanchi 
<trinath.soman...@nxp.com<mailto:trinath.soman...@nxp.com>> wrote:
Jenkins is throwing some Failures in new submissions. That might be an issue.
Get Outlook for iOS<https://aka.ms/o0ukef>


From: Yujun Zhang (ZTE) 
<zhangyujun+...@gmail.com<mailto:zhangyujun%2b...@gmail.com>>
Sent: 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] 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", "user_id": "zhangyujun", "seq": 65434, 
"company_link": "EasyStack",
 "text": "Zhang Yujun", "companies": [{"company_name": "ZTE Corporation", 
"end_date": 1474588800}, {"company_name": "EasyStack", "end_date": 0}], "id": 
"zhangyujun", "static": true, "gerrit_id": "zhangyujun", "user_name": "Zhang 
Yujun", "emails": 
["zhangyujun.d...@gmail.com<mailto:zhangyujun.d...@gmail.com>", 
"zhangyu...@gmail.com<mailto:zhangyu...@gmail.com>", 
"284517...@qq.com<mailto:284517...@qq.com>", 
"zhangyujun+...@gmail.com<mailto:zhangyujun%2b...@gmail.com>", 
"yujun.zh...@easystack.cn<mailto:yujun.zh...@easystack.cn>", 
"zhang.yuj...@zte.com.cn<mailto:zhang.yuj...@zte.com.cn>"]}}

The email address in red should be removed if the patch works as expected.

Is there any way I can make further investigation on this issue? The log 
message from the stackalytics server might be helpful.


[1]: https://review.openstack.org/#/c/426502/

--
Yujun Zhang
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Yujun Zhang
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Yujun Zhang (ZTE)]

Hi, Trinath

What failure are you referring to exactly? It seems all jobs passed
normally.

I know there are some error message in the console logs, but that seems to
be expected failures for negative test cases.

On Mon, Mar 20, 2017 at 12:16 PM Trinath Somanchi <trinath.soman...@nxp.com>
wrote:

Jenkins is throwing some Failures in new submissions. That might be an
issue.

Get Outlook for iOS <https://aka.ms/o0ukef>

--
*From:* Yujun Zhang (ZTE) <zhangyujun+...@gmail.com>
*Sent:* Monday, March 20, 2017 8:47:30 AM
*To:* 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] 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", "user_id": "zhangyujun", "seq":
65434, "company_link": "EasyStack", "text": "Zhang
Yujun", "companies": [{"company_name": "ZTE Corporation", "end_date":
1474588800}, {"company_name": "EasyStack", "end_date": 0}], "id":
"zhangyujun", "static": true, "gerrit_id": "zhangyujun", "user_name":
"Zhang Yujun", "emails": [*"zhangyujun.d...@gmail.com
<zhangyujun.d...@gmail.com>", "zhangyu...@gmail.com <zhangyu...@gmail.com>"*,
"284517...@qq.com", "zhangyujun+...@gmail.com", "yujun.zh...@easystack.cn",
"zhang.yuj...@zte.com.cn"]}}

The email address in red should be removed if the patch works as expected.

Is there any way I can make further investigation on this issue? The log
message from the stackalytics server might be helpful.

[1]: https://review.openstack.org/#/c/426502/

-- 
Yujun Zhang
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Yujun Zhang
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Trinath Somanchi]

Jenkins is throwing some Failures in new submissions. That might be an issue.

Get Outlook for iOS<https://aka.ms/o0ukef>


From: Yujun Zhang (ZTE) <zhangyujun+...@gmail.com>
Sent: Monday, March 20, 2017 8:47:30 AM
To: 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] 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", "user_id": "zhangyujun", "seq": 65434, 
"company_link": "EasyStack",
 "text": "Zhang Yujun", "companies": [{"company_name": "ZTE Corporation", 
"end_date": 1474588800}, {"company_name": "EasyStack", "end_date": 0}], "id": 
"zhangyujun", "static": true, "gerrit_id": "zhangyujun", "user_name": "Zhang 
Yujun", "emails": 
["zhangyujun.d...@gmail.com<mailto:zhangyujun.d...@gmail.com>", 
"zhangyu...@gmail.com<mailto:zhangyu...@gmail.com>", 
"284517...@qq.com<mailto:284517...@qq.com>", 
"zhangyujun+...@gmail.com<mailto:zhangyujun%2b...@gmail.com>", 
"yujun.zh...@easystack.cn", 
"zhang.yuj...@zte.com.cn<mailto:zhang.yuj...@zte.com.cn>"]}}

The email address in red should be removed if the patch works as expected.

Is there any way I can make further investigation on this issue? The log 
message from the stackalytics server might be helpful.


[1]: https://review.openstack.org/#/c/426502/

--
Yujun Zhang
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Yujun Zhang (ZTE)]

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", "user_id": "zhangyujun", "seq":
65434, "company_link": "EasyStack", "text": "Zhang
Yujun", "companies": [{"company_name": "ZTE Corporation", "end_date":
1474588800}, {"company_name": "EasyStack", "end_date": 0}], "id":
"zhangyujun", "static": true, "gerrit_id": "zhangyujun", "user_name":
"Zhang Yujun", "emails": [*"zhangyujun.d...@gmail.com
", "zhangyu...@gmail.com "*,
"284517...@qq.com", "zhangyujun+...@gmail.com", "yujun.zh...@easystack.cn",
"zhang.yuj...@zte.com.cn"]}}

The email address in red should be removed if the patch works as expected.

Is there any way I can make further investigation on this issue? The log
message from the stackalytics server might be helpful.

[1]: https://review.openstack.org/#/c/426502/

-- 
Yujun Zhang
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ihar Hrachyshka]

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 2:28 GMT+03:00 Ihar Hrachyshka :
>>
>> Hi all,
>>
>> I am looking at
>> http://stackalytics.com/?project_type=openstack=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 briefly looked at the code, and it seems like the project should
>> reflect what’s defined in governance repo, but apparently it’s not the case.
>> So what does it reflect?
>>
>> Ihar
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Yujun Zhang]

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 user profile is
not possible.

*This will cause a statistic data error when user changes his launchpad id.*

My commits submitted with email address "zhang.yuj...@zte.com.cn" are now
updated to EasyStack instead of ZTE Corporation[3].

Below is the detailed analysis:

I modified my launchpad id from `zhangyujun` to `yujunz` and forced an
association of my email address "zhang.yuj...@zte.com.cn" to `yujunz` by
patching `default_data.json`[4].

Now I realized the association between `zhang.yuj...@zte.com.cn
` still exists in runtime storage. I found my
commits associated to `zhangyujun` and `yujunz` randomly even after trying
to rewrite the old user id[5]

So when another user registered with my old launchpad id[6], it started to
cause statistic chaos not only in user but also in company.

My questions is: *is there any way to remove the obsolete email address*?

[1]: https://bugs.launchpad.net/stackalytics/+bug/1634020
[2]:
http://git.openstack.org/cgit/openstack/stackalytics/tree/stackalytics/processor/user_processor.py#n99
[3]:
http://stackalytics.com/?project_type=opnfv-group=commits_id=zhangyujun
[4]: https://review.openstack.org/#/c/365375/1/etc/default_data.json
[5]: https://review.openstack.org/#/c/384000/1/etc/default_data.json
[6]: https://review.openstack.org/#/c/384801/1/etc/default_data.json
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ilya Shakhat]

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=
> 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 briefly looked at the code, and it seems like the project should
> reflect what’s defined in governance repo, but apparently it’s not the
> case. So what does it reflect?
>
> Ihar
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ihar Hrachyshka]

Hi all,

I am looking at 
http://stackalytics.com/?project_type=openstack=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 briefly looked at the code, and it seems like the project should reflect 
what’s defined in governance repo, but apparently it’s not the case. So what 
does it reflect?

Ihar
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stackalytics]

[Ilya Shakhat]

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 how could
> solve this bug?
>

This duplication is one of the reasons why we removed all deb-* projects
from statistics. Now it seems like we need to fix all other stats as well.

Thanks for reporting this.

--Ilya
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [stackalytics]

[Roman Vasilets]

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
solve this bug?

[1] https://bugs.launchpad.net/stackalytics/+bug/1625060

Best regards, Roman Vasylets.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Thomas Goirand]

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
Ilya may not have enough time. That's a constructive reply, unlike what
you seemed to believe.

> How does the current prioritization
> harm the Debian packaging team?

No more or less than any other project in the big tent, I guess.

> Are employers of team members using stackalytics to judge activity?

Sorry to say it strait this way, but that's really none of your
business. Please avoid this type of remarks in the future.

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jeremy Stanley]

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/blob/master/tools/owners.py
> 
> AFAIK that is because Stackalytics works from git history, while the
> infra script works from Gerrit changes (which are more reliable).

Where "reliable" in this case means that a Gerrit change number
(numeric index ID) refers to one specific commit in one repository.
If that same commit SHA appears in the history of another repository
(because it's a fork or something) then it won't have its own Gerrit
change number and so won't show up a second time.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Thierry Carrez]

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 from git history, while the
infra script works from Gerrit changes (which are more reliable).

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ian Cordasco]

 

-Original Message-
From: Thomas Goirand <z...@debian.org>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: September 21, 2016 at 08:40:07
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  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=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. If some commit is cherry-picked from master to stable
> > it is counted twice in both branches / releases. The configuration for
> > stable branch is simple - branch starting with branching point (e.g.
> > stable/newton that starts with rc1)
> >
> > In deb-* projects master branch corresponds to upstream Debian
> > community. All OpenStack-related contribution goes into debian/
> > branch. But unlike in the rest of OpenStack, git workflow differs and
> > the branch contains merge commits from master. This makes filtering
> > "pure" branch commits from those that came from master quite tricky (not
> > possible to specify the branch-point). And support of this will require
> > changes in Stackalytics code.
> >
> > Since currently we are at the time when people may get nervous about
> > numbers, I'd suggest to temporary hide all commits from deb-* projects
> > and revise stats processing in a month.
> >
> > Thanks,
> > Ilya
>  
> Replying again here (I'm subscribed, so it will go through this time).
>  
> Ilya,
>  
> 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  
>  
> What part of Stackalytics is gathering the commits?
>  
> Waiting for a full month to solve this issue properly isn't nice at all
> for those working on packaging_deb. Could it be solved properly earlier
> than this?
>  
> Cheers,
>  
> Thomas Goirand (zigo)

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. How does the current prioritization harm the Debian packaging 
team? Are employers of team members using stackalytics to judge activity? I'd 
encourage you and the team members to point them to better tooling for that.

--  
Ian Cordasco


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Thomas Goirand]

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=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. If some commit is cherry-picked from master to stable
> it is counted twice in both branches / releases. The configuration for
> stable branch is simple - branch starting with branching point (e.g.
> stable/newton that starts with rc1)
> 
> In deb-* projects master branch corresponds to upstream Debian
> community. All OpenStack-related contribution goes into debian/
> branch. But unlike in the rest of OpenStack, git workflow differs and
> the branch contains merge commits from master. This makes filtering
> "pure" branch commits from those that came from master quite tricky (not
> possible to specify the branch-point). And support of this will require
> changes in Stackalytics code.
> 
> Since currently we are at the time when people may get nervous about
> numbers, I'd suggest to temporary hide all commits from deb-* projects
> and revise stats processing in a month.
> 
> Thanks,
> Ilya

Replying again here (I'm subscribed, so it will go through this time).

Ilya,

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

What part of Stackalytics is gathering the commits?

Waiting for a full month to solve this issue properly isn't nice at all
for those working on packaging_deb. Could it be solved properly earlier
than this?

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ilya Shakhat]

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=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. If some commit is cherry-picked from master to stable
> > it is counted twice in both branches / releases. The configuration for
> > stable branch is simple - branch starting with branching point (e.g.
> > stable/newton that starts with rc1)
> >
> > In deb-* projects master branch corresponds to upstream Debian
> > community. All OpenStack-related contribution goes into debian/
> > branch. But unlike in the rest of OpenStack, git workflow differs and
> > the branch contains merge commits from master. This makes filtering
> > "pure" branch commits from those that came from master quite tricky (not
> > possible to specify the branch-point). And support of this will require
> > changes in Stackalytics code.
> >
> > Since currently we are at the time when people may get nervous about
> > numbers, I'd suggest to temporary hide all commits from deb-* projects
> > and revise stats processing in a month.
>
> Sounds good. Are you working on it ?


Yep. I'm working on this, will update on the results.

--Ilya Shakhat
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Thierry Carrez]

Ilya Shakhat wrote:
> Hi,
> 
> tldr; Commits stats are significantly skewed by deb-* projects
> (http://stackalytics.com/?metric=commits=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. If some commit is cherry-picked from master to stable
> it is counted twice in both branches / releases. The configuration for
> stable branch is simple - branch starting with branching point (e.g.
> stable/newton that starts with rc1)
> 
> In deb-* projects master branch corresponds to upstream Debian
> community. All OpenStack-related contribution goes into debian/
> branch. But unlike in the rest of OpenStack, git workflow differs and
> the branch contains merge commits from master. This makes filtering
> "pure" branch commits from those that came from master quite tricky (not
> possible to specify the branch-point). And support of this will require
> changes in Stackalytics code.
> 
> Since currently we are at the time when people may get nervous about
> numbers, I'd suggest to temporary hide all commits from deb-* projects
> and revise stats processing in a month.

Sounds good. Are you working on it ?


-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ilya Shakhat]

Hi,

tldr; Commits stats are significantly skewed by deb-* projects (
http://stackalytics.com/?metric=commits=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. If some commit is cherry-picked from master to stable it is
counted twice in both branches / releases. The configuration for stable
branch is simple - branch starting with branching point (e.g. stable/newton
that starts with rc1)

In deb-* projects master branch corresponds to upstream Debian community.
All OpenStack-related contribution goes into debian/ branch. But
unlike in the rest of OpenStack, git workflow differs and the branch
contains merge commits from master. This makes filtering "pure" branch
commits from those that came from master quite tricky (not possible to
specify the branch-point). And support of this will require changes in
Stackalytics code.

Since currently we are at the time when people may get nervous about
numbers, I'd suggest to temporary hide all commits from deb-* projects and
revise stats processing in a month.

Thanks,
Ilya
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Anita Kuno]

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 "others" category. Is there any new rule in Stackalytics?
> 
> Best Regards
> Chaoyi Huang ( joehuang )
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

I use gerrit directly for evaluation of reviewing activity.

Gerrit has many different queries that can be created to evaluate
individual contributions both for ownership of patches and for reviewing
patches. Besides, while absolute numbers of patches can be useful,
evaluating the quality of the individual's review is vastly more
important. Taking the time to make useful inline comments and link to
references to support contributor's composing really good patches far
surpasses numbers in my book. Many of my best reviews on patches don't
include a vote, something that stackalytics doesn't count at all.

There is a whole world of valuable data on gerrit. I encourage you to
explore it: https://review.openstack.org/Documentation/user-search.html

Thank you,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Shinobu Kinjo]

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 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?
>
> Best Regards
> Chaoyi Huang ( joehuang )
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[joehuang]

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?

Best Regards
Chaoyi Huang ( joehuang )
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ilya Shakhat]

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 gives much clearer picture of the kind of reviews
> someone is/wants to be involved in. I couldn't find documentation in the
> README or anywhere else and the minimal amount of docstrings are making
> it difficult for me to figure the changes.
>
> What's the best possible route to accomplish this?
>

Well, I see two different metrics here: the first counts +0s and the second
is additional analytic over existing reviews.

Counting +0s or comments is something that is asked from time to time and
something that I'd like to avoid. The reason is that retrieving comments
lead to higher load on Gerrit and slows down the update cycle.

However Stackalytics already retrieves comments for some projects (those
that have external CIs, like nova), so we can try this new metric there as
experiment. The metric should probably be different from "reviews" not to
skew the current numbers. As of implementation, the changes should be in
both processor and dashboard; the code similar to existing counting reviews.

The second feature is counting votes against patch-sets posted by bots.
This one should be easier to implement and all data is already available.
In the report like [1] every vote record can be extended with info from
patch-set; the filtering should take into account the author's company, all
bots are assigned to '*robots'.

Thanks,
Ilya


>
> [1] http://stackalytics.com/report/contribution/astara-group/30
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2016-April/091836.html
>
> --
>
> Thanks,
> Nikhil
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 gives much clearer picture of the kind of reviews
someone is/wants to be involved in. I couldn't find documentation in the
README or anywhere else and the minimal amount of docstrings are making
it difficult for me to figure the changes.

What's the best possible route to accomplish this?

[1] http://stackalytics.com/report/contribution/astara-group/30
[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-April/091836.html

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Alexis Lee]

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 314 1496 79

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ilya Shakhat]

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.

> The most important number which I'm trying to get, is an average time
> > change requests waiting for reviewers since last vote or mark, from
> > all requests (not only those which remain in open state, like it is
> > now, I believe).


Do you mean to calculate stats not only for open, but also for those that
are already closed? Should it be for all times, or during specified period?

Regards,
--Ilya


2015-11-12 1:14 GMT+03:00 Jesus M. Gonzalez-Barahona :

> 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 "time waiting for reviewer" (from the moment a new
> patchset is produced, to the time a conclusive review vote is found in
> Gerrit), and "time waiting for developer" (from the conclusive review
> vote to next patchset).
>
> We're working now in a visualization for that kind of information. For
> now, we only have complete changeset values, check if you're
> interested:
>
> http://blog.bitergia.com/2015/10/22/understanding-the-code-review-proce
> ss-in-openstack/
>
> Saludos,
>
> Jesus.
>
> On Wed, 2015-11-11 at 21:45 +, Mike Scherbakov wrote:
> > 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, not total number of reviews?
> >
> > The most important number which I'm trying to get, is an average time
> > change requests waiting for reviewers since last vote or mark, from
> > all requests (not only those which remain in open state, like it is
> > now, I believe).
> >
> > How hard would it be to get / extend Stackalytics to make it..?
> >
> > Thanks!
> > --
> > Mike Scherbakov
> > #mihgen
> > _
> > _
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> > cribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> --
> Bitergia: http://bitergia.com
> /me at Twitter: https://twitter.com/jgbarah
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Mike Scherbakov]

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, including already closed, for some
period of time. For instance, last 30, 60, 90 days.

btw, I updated list of fuel-group repos, please review:
https://review.openstack.org/#/c/244936/.

Thank you,

On Thu, Nov 12, 2015 at 6:59 AM Ilya Shakhat  wrote:

> 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.
>
>
> > The most important number which I'm trying to get, is an average time
>> > change requests waiting for reviewers since last vote or mark, from
>> > all requests (not only those which remain in open state, like it is
>> > now, I believe).
>
>
> Do you mean to calculate stats not only for open, but also for those that
> are already closed? Should it be for all times, or during specified period?
>
> Regards,
> --Ilya
>
>
>
> 2015-11-12 1:14 GMT+03:00 Jesus M. Gonzalez-Barahona :
>
>> 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 "time waiting for reviewer" (from the moment a new
>> patchset is produced, to the time a conclusive review vote is found in
>> Gerrit), and "time waiting for developer" (from the conclusive review
>> vote to next patchset).
>>
>> We're working now in a visualization for that kind of information. For
>> now, we only have complete changeset values, check if you're
>> interested:
>>
>> http://blog.bitergia.com/2015/10/22/understanding-the-code-review-proce
>> ss-in-openstack/
>> 
>>
>> Saludos,
>>
>> Jesus.
>>
>> On Wed, 2015-11-11 at 21:45 +, Mike Scherbakov wrote:
>> > 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, not total number of reviews?
>> >
>> > The most important number which I'm trying to get, is an average time
>> > change requests waiting for reviewers since last vote or mark, from
>> > all requests (not only those which remain in open state, like it is
>> > now, I believe).
>> >
>> > How hard would it be to get / extend Stackalytics to make it..?
>> >
>> > Thanks!
>> > --
>> > Mike Scherbakov
>> > #mihgen
>> > _
>> > _
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
>> > cribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> --
>> Bitergia: http://bitergia.com
>> /me at Twitter: https://twitter.com/jgbarah
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Mike Scherbakov
#mihgen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jesus M. Gonzalez-Barahona]

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 "time waiting for reviewer" (from the moment a new
patchset is produced, to the time a conclusive review vote is found in
Gerrit), and "time waiting for developer" (from the conclusive review
vote to next patchset).

We're working now in a visualization for that kind of information. For
now, we only have complete changeset values, check if you're
interested:

http://blog.bitergia.com/2015/10/22/understanding-the-code-review-proce
ss-in-openstack/

Saludos,

Jesus.

On Wed, 2015-11-11 at 21:45 +, Mike Scherbakov wrote:
> 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, not total number of reviews?
> 
> The most important number which I'm trying to get, is an average time
> change requests waiting for reviewers since last vote or mark, from
> all requests (not only those which remain in open state, like it is
> now, I believe).
> 
> How hard would it be to get / extend Stackalytics to make it..?
> 
> Thanks!
> -- 
> Mike Scherbakov
> #mihgen
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-- 
Bitergia: http://bitergia.com
/me at Twitter: https://twitter.com/jgbarah


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Mike Scherbakov]

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, not total number of reviews?

The most important number which I'm trying to get, is an average time
change requests waiting for reviewers since last vote or mark, from all
requests (not only those which remain in open state, like it is now, I
believe).

How hard would it be to get / extend Stackalytics to make it..?

Thanks!
-- 
Mike Scherbakov
#mihgen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ilya Shakhat]

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 below:

1. Stackalytics now respects history of changes in the official programs
list. Changes are tracked per-release, so if some project was accepted
officially in Liberty, it does not appear in the past and thus does not
affect Kilo stats. As anchor points we use tags in governance repo (e.g.
april-2015-elections)[1]
. These tags are
related to elections and created a bit before the release thus saving from
last-minute changes in the stats.

2. With removal of Stackforge, all projects are now classified in 2 groups:
'OpenStack' = listed in the official projects.yaml [2]

and 'OpenStack Others' = those that are in openstack organization, but not
accepted officially. As before, by default Stackalytics shows official
projects.

3. CI metric [3]  is redesigned from
scratch. Now it analyses votes in merged patches only, the numbers are
shown for every driver. List of drivers is synced with DriverLog [4]

.

4. Added a new driver status report [5]
. The report shows total number
of votes, success rate and the latest result per every driver per module.
The report is available for projects that have external CI configured
(Nova, Neutron, Cinder, Manila, Sahara, number of Fuel plugins) The data
may be not complete now and requires proper configuration in DriverLog's
default data (maintainers are welcome to contribute into [4]

)

5. Abandoning a change request is now treated as reviewing [6]
 and is included into review
metric. Only abandoning of other's CRs is taken into account.

6. Reviews for own patches are not included into the stats anymore. In the
activity log such reviews are marked with prefix 'Self-' (e.g.
Self-Code-Review and Self-Approve)

7. Review processing is made compatible with Gerrit 2.9+, making
Stackalytics ready for infra upgrade.

Thanks,
Ilya

[1] - https://git.openstack.org/cgit/openstack/governance/
[2] -
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
[3] - http://stackalytics.com/?metric=ci
[4] -
http://git.openstack.org/cgit/openstack/driverlog/tree/etc/default_data.json
[5] - http://stackalytics.com/report/ci/cinder/7
[6] - https://bugs.launchpad.net/bugs/1498769
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jay Pipes]

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 'big tent' model.

The full list of changes below:

1. Stackalytics now respects history of changes in the official programs
list. Changes are tracked per-release, so if some project was accepted
officially in Liberty, it does not appear in the past and thus does not
affect Kilo stats. As anchor points we use tags in governance repo (e.g.
april-2015-elections)[1]
. These tags are
related to elections and created a bit before the release thus saving
from last-minute changes in the stats.

2. With removal of Stackforge, all projects are now classified in 2
groups: 'OpenStack' = listed in the official projects.yaml [2]

and 'OpenStack Others' = those that are in openstack organization, but
not accepted officially. As before, by default Stackalytics shows
official projects.

3. CI metric [3]  is redesigned from
scratch. Now it analyses votes in merged patches only, the numbers are
shown for every driver. List of drivers is synced with DriverLog [4]
.


4. Added a new driver status report [5]
. The report shows total
number of votes, success rate and the latest result per every driver per
module. The report is available for projects that have external CI
configured (Nova, Neutron, Cinder, Manila, Sahara, number of Fuel
plugins) The data may be not complete now and requires proper
configuration in DriverLog's default data (maintainers are welcome to
contribute into [4]
)

5. Abandoning a change request is now treated as reviewing [6]
 and is included into review
metric. Only abandoning of other's CRs is taken into account.

6. Reviews for own patches are not included into the stats anymore. In
the activity log such reviews are marked with prefix 'Self-' (e.g.
Self-Code-Review and Self-Approve)

7. Review processing is made compatible with Gerrit 2.9+, making
Stackalytics ready for infra upgrade.


Awesome work, Ilya, thanks for your work on these improvements.

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Flavio Percoco]

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 'big tent' model. 

The full list of changes below:

1. Stackalytics now respects history of changes in the official programs list.
Changes are tracked per-release, so if some project was accepted officially in
Liberty, it does not appear in the past and thus does not affect Kilo stats. As
anchor points we use tags in governance repo (e.g. april-2015-elections)[1]
. These tags are related to elections and created a bit before the release thus
saving from last-minute changes in the stats.

2. With removal of Stackforge, all projects are now classified in 2 groups:
'OpenStack' = listed in the official projects.yaml [2] and 'OpenStack Others' =
those that are in openstack organization, but not accepted officially. As
before, by default Stackalytics shows official projects.

3. CI metric [3] is redesigned from scratch. Now it analyses votes in merged
patches only, the numbers are shown for every driver. List of drivers is synced
with DriverLog [4]. 

4. Added a new driver status report [5]. The report shows total number of
votes, success rate and the latest result per every driver per module. The
report is available for projects that have external CI configured (Nova,
Neutron, Cinder, Manila, Sahara, number of Fuel plugins) The data may be not
complete now and requires proper configuration in DriverLog's default data
(maintainers are welcome to contribute into [4])

5. Abandoning a change request is now treated as reviewing [6] and is included
into review metric. Only abandoning of other's CRs is taken into account.

6. Reviews for own patches are not included into the stats anymore. In the
activity log such reviews are marked with prefix 'Self-' (e.g. Self-Code-Review
and Self-Approve)

7. Review processing is made compatible with Gerrit 2.9+, making Stackalytics
ready for infra upgrade. 


Awesome work! Thanks for your efforts!

Flavio



Thanks, 
Ilya

[1] - https://git.openstack.org/cgit/openstack/governance/
[2] - http://git.openstack.org/cgit/openstack/governance/tree/reference/
projects.yaml
[3] - http://stackalytics.com/?metric=ci
[4] - http://git.openstack.org/cgit/openstack/driverlog/tree/etc/
default_data.json
[5] - http://stackalytics.com/report/ci/cinder/7
[6] - https://bugs.launchpad.net/bugs/1498769



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ilya Shakhat]

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 have been lost.
>
> http://stackalytics.com/?metric=commits=openstack-ansible
>
> Can anyone assist with rectifying this?
>
> --
> Jesse Pretorius
> IRC: odyssey4me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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 have been lost.

http://stackalytics.com/?metric=commits=openstack-ansible

Can anyone assist with rectifying this?

-- 
Jesse Pretorius
IRC: odyssey4me
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ilya Shakhat]

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 eye on commercial interest and know who is sponsoring near-by
technologies.

I agree that adding complementary projects was an authoritarian decision
and ready to remove them in the community version if TC decides so.

Thanks,
Ilya

2015-06-19 10:48 GMT+03:00 Thierry Carrez thie...@openstack.org:

 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=complementarymetric=commits

 It's not a community decision. I'd say it is an editorial decision of
 the current owner of the project and website. While we are trying to
 move this project under the Infra project team and the Technical
 Committee oversight, it is currently still a Stackforge project owned by
 Mirantis.

 Personally if we were to move it under Infra I would (1) remove the
 complementary projects and (2) make sure that whoever wants to reuse
 stackalytics code to track Docker / CloudFoundry activity can easily do so.

 --
 Thierry Carrez (ttx)

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jay Pipes]

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 depends
on, like OVS and Ansible.
  * to keep an eye on commercial interest and know who is sponsoring
near-by technologies.

I agree that adding complementary projects was an authoritarian decision
and ready to remove them in the community version if TC decides so.


Hi Ilya,

Personally, I quite like having those complementary projects in 
Stackalytics, for the reasons you note above.


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Thierry Carrez]

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=complementarymetric=commits

It's not a community decision. I'd say it is an editorial decision of
the current owner of the project and website. While we are trying to
move this project under the Infra project team and the Technical
Committee oversight, it is currently still a Stackforge project owned by
Mirantis.

Personally if we were to move it under Infra I would (1) remove the
complementary projects and (2) make sure that whoever wants to reuse
stackalytics code to track Docker / CloudFoundry activity can easily do so.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jay Pipes]

On 06/19/2015 10:31 AM, Joe Gordon wrote:

On Jun 19, 2015 3:56 PM, Jay Pipes jaypi...@gmail.com
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 - 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 eye on commercial interest and know who is sponsoring
  near-by technologies.
 
  I agree that adding complementary projects was an authoritarian decision
  and ready to remove them in the community version if TC decides so.
 
 
  Hi Ilya,
 
  Personally, I quite like having those complementary projects in
Stackalytics, for the reasons you note above.
 

Although it's not very useful for 'reviews'

http://stackalytics.com/?project_type=complementary


Sure, agreed :)


I also wonder how well maintained the email mappings are for
complementary projects.


Good point. I'm sure there can be many improvements made to the support 
for complementary projects. I was just remarking that I find the 
information there to be interesting, nothing more.


-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Joe Gordon]

On Jun 19, 2015 3:56 PM, Jay Pipes 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 - 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 eye on commercial interest and know who is sponsoring
 near-by technologies.

 I agree that adding complementary projects was an authoritarian decision
 and ready to remove them in the community version if TC decides so.


 Hi Ilya,

 Personally, I quite like having those complementary projects in
Stackalytics, for the reasons you note above.


Although it's not very useful for 'reviews'

http://stackalytics.com/?project_type=complementary

I also wonder how well maintained the email mappings are for complementary
projects.

 Best,
 -jay


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Monty Taylor]

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 jaypi...@gmail.com
 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 - 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 eye on commercial interest and know who is sponsoring
   near-by technologies.
  
   I agree that adding complementary projects was an authoritarian
 decision
   and ready to remove them in the community version if TC decides so.
  
  
   Hi Ilya,
  
   Personally, I quite like having those complementary projects in
 Stackalytics, for the reasons you note above.
  

 Although it's not very useful for 'reviews'

 http://stackalytics.com/?project_type=complementary
 
 Sure, agreed :)
 
 I also wonder how well maintained the email mappings are for
 complementary projects.
 
 Good point. I'm sure there can be many improvements made to the support
 for complementary projects. I was just remarking that I find the
 information there to be interesting, nothing more.

I also find it interesting. I, in fact, added the ansible and python
packaging related repos to the list, because I found it interesting.

It's also nice to see that we're not completely insular - that we, as
OpenStack, also work with others. We have humans working in both
openstack and openvswitch, for instance. And who are working in ansible
and openstack. Etc. I think that's a great positive thing to be able to
highlight - we are, after all, not an island to ourselves, but are part
of a larger community.

So, my vote will be to keep them. I'm only one vote, of course, but I
think it would be a shame to get rid of them.

Monty


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Stackalytics] Complementary projects

[Paul Belanger]

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=complementarymetric=commits

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Stackalytics 0.6 released!

[Herman Narkaytis]

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
different technologies which were targeted to show decent performance on 1
million records. At that time there were only 50k commits records and we
estimated to achieve 1M in 3 years. I'm glad to admit that we were wrong.
Now Stackalytics handles not only commits, but reviews, blueprints, bugs,
emails, registrations on openstack.org, etc. We've reached 1M bound and
still are able to generate reports in seconds!

  Today we'd like to announce 0.6 release with a bunch of new features:

   - Implemented module classification based on programs.yaml with
   retrospective integrated/incubated attribution
   - Added support for co-authored commits
   - Added metrics on filed and resolved bugs
   - Added drill-down report on OpenStack foundation members

  I want to say thank you to our development team and especially to Ilya
Shakhat, Pavel Kholkin and Yury Taraday.

  Please feel free to provide your feedback. It's highly appreciated.

--
Herman Narkaytis
DoO Ru, PhD
Tel.: +7 (8452) 674-555, +7 (8452) 431-555
Tel.: +7 (495) 640-4904
Tel.: +7 (812) 640-5904
Tel.: +38(057)728-4215
Tel.: +1 (408) 715-7897
ext 2002
http://www.mirantis.com

This email (including any attachments) is confidential. If you are not the
intended recipient you must not copy, use, disclose, distribute or rely on
the information contained in it. If you have received this email in error,
please notify the sender immediately by reply email and delete the email
from your system. Confidentiality and legal privilege attached to this
communication are not waived or lost by reason of mistaken delivery to you.
Mirantis does not guarantee (that this email or the attachment's) are
unaffected by computer virus, corruption or other defects. Mirantis may
monitor incoming and outgoing emails for compliance with its Email Policy.
Please note that our servers may not be located in your country.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Fukuda, Yuko]

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


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

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

[Tom Fifield]

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.org/wiki/GerritWorkflow


Please let us know if you require any assistance.


Regards,


Tom

On 27/02/14 10:05, Fukuda, Yuko wrote:

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


___
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] [stackalytics] Pull request on default_data.json (addition of a domain)

[Fukuda, Yuko]

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] [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.org/wiki/GerritWorkflow

Please let us know if you require any assistance.


Regards,


Tom

On 27/02/14 10:05, Fukuda, Yuko wrote:
 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


 ___
 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 mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Stackalytics 0.4 released!

[Ilya Shakhat]

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/report/reviews/neutron-group/30). Open reviews
report to help core engineers with tracking the backlog and reviews that
stay for too long (http://stackalytics.com/report/reviews/nova/open). And
activity report, the one to show all work done by engineer and another by
company. Also this report includes nice punch-card and the one can find
that there are really world-wide never-sleeping contributors like
http://stackalytics.com/report/companies/red%20hat :)

In details, total changes are:

   - Added review stats
reporthttp://stackalytics.com/report/reviews/neutron-group/30that
shows top reviewers with breakdown by marks and disagreement ratio
   against core's decision
   - Added open reviews
reporthttp://stackalytics.com/report/reviews/nova/openthat shows top
longest reviews and backlog summary
   - Added activity report
http://stackalytics.com/report/users/boris-42with engineer's
activity log and punch-card of usual online hours (in UTC).
   The same report is available for companies
   - Fixed review stats calculation, now Approve marks are counted
   separately
   - Fixed commit date calculation, now it is date of merge, not commit
   - Minor improvements in filter selectors
   - Incorporated 21 updates to user and company profiles in default data

The next Stackalytics meeting will be on Monday, Dec 16 at 15:00 UTC in
#openstack-meeting. Come and join us, we have somemore things for the next
release.

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

Re: [openstack-dev] Stackalytics 0.4 released!

[Monty Taylor]

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 finding most active reviewers
 (ex. http://stackalytics.com/report/reviews/neutron-group/30). Open
 reviews report to help core engineers with tracking the backlog and
 reviews that stay for too long
 (http://stackalytics.com/report/reviews/nova/open). And activity report,
 the one to show all work done by engineer and another by company. Also
 this report includes nice punch-card and the one can find that there are
 really world-wide never-sleeping contributors
 like http://stackalytics.com/report/companies/red%20hat :)

Nice work. On the activity chart, it shows an activity graph of time and
day. What timezone are those hours shown in?

 In details, total changes are:
 
   * Added review stats report
 http://stackalytics.com/report/reviews/neutron-group/30 that shows
 top reviewers with breakdown by marks and disagreement ratio against
 core's decision
   * Added open reviews report
 http://stackalytics.com/report/reviews/nova/open that shows top
 longest reviews and backlog summary
   * Added activity report
 http://stackalytics.com/report/users/boris-42 with engineer's
 activity log and punch-card of usual online hours (in UTC). The same
 report is available for companies
   * Fixed review stats calculation, now Approve marks are counted
 separately
   * Fixed commit date calculation, now it is date of merge, not commit
   * Minor improvements in filter selectors
   * Incorporated 21 updates to user and company profiles in default data 
 
 The next Stackalytics meeting will be on Monday, Dec 16 at 15:00 UTC in
 #openstack-meeting. Come and join us, we have somemore things for the
 next release.
 
 Thanks,
 Ilya
 
 
 ___
 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] Stackalytics 0.4 released!

[chandan kumar]

Hello ,

On Thu, Dec 12, 2013 at 10:11 PM, Monty Taylor mord...@inaugust.com 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 demanded top reviewers chart acknowledged as an essential tool
 for finding most active reviewers
 (ex. http://stackalytics.com/report/reviews/neutron-group/30). Open
 reviews report to help core engineers with tracking the backlog and
 reviews that stay for too long
 (http://stackalytics.com/report/reviews/nova/open). And activity report,
 the one to show all work done by engineer and another by company. Also
 this report includes nice punch-card and the one can find that there are
 really world-wide never-sleeping contributors
 like http://stackalytics.com/report/companies/red%20hat :)

 Nice work. On the activity chart, it shows an activity graph of time and
 day. What timezone are those hours shown in?

 In details, total changes are:

   * Added review stats report
 http://stackalytics.com/report/reviews/neutron-group/30 that shows
 top reviewers with breakdown by marks and disagreement ratio against
 core's decision
   * Added open reviews report
 http://stackalytics.com/report/reviews/nova/open that shows top
 longest reviews and backlog summary
   * Added activity report
 http://stackalytics.com/report/users/boris-42 with engineer's
 activity log and punch-card of usual online hours (in UTC). The same
 report is available for companies
   * Fixed review stats calculation, now Approve marks are counted
 separately
   * Fixed commit date calculation, now it is date of merge, not commit
   * Minor improvements in filter selectors
   * Incorporated 21 updates to user and company profiles in default data

 The next Stackalytics meeting will be on Monday, Dec 16 at 15:00 UTC in
 #openstack-meeting. Come and join us, we have somemore things for the
 next release.

 Thanks,
 Ilya


Thank you Ilya for bringing lots of changes in the stackalytics.
I would like to help in the development of stackalytics. Last time i
have missed.
This time i will not.

Thanks,
Chandan Kumar

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

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

[Stefano Maffulli]

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 personal activity pages: good way to
see when people are mostly active during the day/week. I think it would
be good to have one comprehensive view of the activity of a person or
company in one page. Do you already have plans to merge this view
http://stackalytics.com/?user_id=project_type=allrelease=allcompany=Red+Hatmetric=all
with http://stackalytics.com/report/companies/red%20hat?

Just yesterday I noticed another incident where people take all our
reported numbers as 'solid gold' while they are subject to
interpretation and verification. I think there should be a warning on
every page, especially the pages reporting companies activity (and a
link to how to fix the data if somebody finds a mistake would be good
too). I and Tom filed a bug for stackalytics and Activity Board:
https://bugs.launchpad.net/stackalytics/+bug/1260135

I think you're doing a very good job with the reporting. We may want to
start discussing how to improve the company-person affiliation problem
in the long term. There is a bug filed for this topic too:
https://bugs.launchpad.net/openstack-community/+bug/1260140

let's keep this going, we want to have good data available automatically
all the time :)

/stef

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

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

[Ilya Shakhat]

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 https://bugs.launchpad.net/stackalytics/+bug/1244485).

I see there's a need to have stats for official projects (more correctly to
say projects belonging to official programs
https://wiki.openstack.org/wiki/Programs), and separate that stats from
other openstack-hosted projects.
So will it work to have the grouping like that?
 - Official OpenStack Projects
- core
- integrated
- incubated
 - OpenStack complimentary projects (e.g. infra projects like jeepyb, gitdm)
 - Stackforge projects (everything from github/stackforge)

Thanks,
Ilya


2013/10/27 Robert Collins robe...@robertcollins.net

 On 28 October 2013 04:32, Sean Dague s...@dague.net 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 other are all fine and good, however none of
 these
  actually represent a number I'd like to see, which is Official Programs
  contributions over all.
 
  Which would be core + documentation + infrastructure + QA / Devstack
 trees
  (+ maybe Tripleo? I don't remember if that's Official or Incubated
 program
  at this point).

 TripleO is official

 NB: Incubation happens to projects, not programs.

 -Rob



 --
 Robert Collins rbtcoll...@hp.com
 Distinguished Technologist
 HP Converged Cloud

 ___
 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] [stackalytics] Official Programs tag?

[Thierry Carrez]

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 / incubated
 projects (bug https://bugs.launchpad.net/stackalytics/+bug/1244485). 
 
 I see there's a need to have stats for official projects (more correctly
 to say projects belonging to official
 programs https://wiki.openstack.org/wiki/Programs), and separate that
 stats from other openstack-hosted projects. 
 So will it work to have the grouping like that?
  - Official OpenStack Projects
 - core 
 - integrated 
 - incubated
  - OpenStack complimentary projects (e.g. infra projects like jeepyb, gitdm)
  - Stackforge projects (everything from github/stackforge)

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 bindings like
python-novaclient, openstack-infra/*, tempest, tripleO  etc.)

Stackforge
* All stackforge

Core at this point probably doesn't make sense, since depending on who
you ask, or what reference text you look at, you'd get a different list.
Just use integrated instead.

OpenStack complimentary projects is also subjective and should be
dropped in favor of the All projects from all official programs category.

-- 
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] [stackalytics] Official Programs tag?

[Sean Dague]

On 11/01/2013 12:42 PM, Thierry Carrez wrote:
snip
 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 bindings like
 python-novaclient, openstack-infra/*, tempest, tripleO  etc.)

Agreed. Though realistically I still want Official Programs + Integrated
to be separable from incubation. Incubation is by definition a different
class of things. Yes, it's something the TC let move closer to
integration, but it's not a declared official part of OpenStack (yet).

The other important thing is this mapping is temporal, which as far as I
can tell stackalytics doesn't support for tagging.

If we're going to reference stackalytics more often for the project this
needs to be done right, and not even have the appearance that the
groupings were created just to make certain organizations float to the
top. So lets get these right. I'd love to permanently retire gitdm, but
until stackalytics actually counts things the way the project is
organized, it's not possible.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sean Dague]

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 actually represent a number I'd like to see, which 
is Official Programs contributions over all.


Which would be core + documentation + infrastructure + QA / Devstack 
trees (+ maybe Tripleo? I don't remember if that's Official or Incubated 
program at this point).


What would be the best way to add this in? Right now there is a lot of 
assumptions that project_group is a string, and I think it should be an 
array of strings instead, but the implications across the source base to 
me are pretty unclear from my cursory reads. So hints at implementing 
this would be good.


-Sean

--
Sean Dague
http://dague.net
project_group

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

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

[Robert Collins]

On 28 October 2013 04:32, Sean Dague s...@dague.net 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 other are all fine and good, however none of these
 actually represent a number I'd like to see, which is Official Programs
 contributions over all.

 Which would be core + documentation + infrastructure + QA / Devstack trees
 (+ maybe Tripleo? I don't remember if that's Official or Incubated program
 at this point).

TripleO is official

NB: Incubation happens to projects, not programs.

-Rob



-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

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

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

[Ilya Shakhat]

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-statshttps://blueprints.launchpad.net/stackalytics/+spec/module-review-backlog-stats
-
reports on review activity for modules
 * 
review-punchcardhttps://blueprints.launchpad.net/stackalytics/+spec/review-punchcard
-
report usual working hours for engineer, similar to
https://github.com/stackforge/stackalytics/graphs/punch-card
 * 
web-filters-cachinghttps://blueprints.launchpad.net/stackalytics/+spec/web-filters-caching
-
cache search queries to improve performance

The full logs are available below:

Minutes:
http://eavesdrop.openstack.org/meetings/stackalytics/2013/stackalytics.2013-10-21-15.01.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/stackalytics/2013/stackalytics.2013-10-21-15.01.txt
Log:
http://eavesdrop.openstack.org/meetings/stackalytics/2013/stackalytics.2013-10-21-15.01.log.html


Sincerely yours,
Ilya Shakhat
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Stackalytics] 0.2 release

[Ilya Shakhat]

Hello everyone!

We are excited to present the new release of
Stackalyticshttp://www.stackalytics.com/- 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 marks. Also the service
now shows all projects from OpenStack world - nearly 150 active projects!
And the last but not the least - filtering options are made more intuitive,
user may slice the stats by release, project type, module, company,
engineer and, of course, by metric.

Full release notes are below:

   - Changed internal architecture. Got rid of persistent storage in Mongo.
   Configuration file
default_data.jsonhttps://github.com/Mirantis/stackalytics/blob/master/etc/default_data.jsonnow
serves as persistent storage.
   - Added polling of Gerrit for retrieval of review related source data.
   - Implemented basic statistics for reviews: number of reviews over time,
   number of negative/positive review, ratio of positive and negative reviews.
   - Redesigned navigation and layout of statistics pages.
   - Implemented auto-assignment of commits to release cycles based on
   dates.
   - Implemented automated retrieval of projects list from GitHub API.
   - Cleanup of default_data.json (reduced from 14k LOC to 4k)
   - Added to corrections.json all commits which are over 3k LOC and looks
   like auto-generated.
   - Implemented feature request Sort bugs ID as numbers, not as
stringshttps://bugs.launchpad.net/stackalytics/+bug/1204926
   - Fixed bunch deletion from
memcachedhttps://bugs.launchpad.net/stackalytics/+bug/1209211

More details on the architecture are on project's wiki:
https://wiki.openstack.org/wiki/Stackalytics And certainly welcome everyone
who wants to run the service on their own:
https://wiki.openstack.org/wiki/Stackalytics/HowToRun

We currently gather feature requests for version 0.3 - feel free to post
blueprint to project's space at launchpad:
https://launchpad.net/stackalytics/

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

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

[Thierry Carrez]

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 think that lines of code is a bad metric per se: like any other
 metric it becomes bad when used in an evile context. I'm getting more
 and more convinced that it's a mistake to show ranks and classifications
 in the dashboard and I'll be deleting all the ones that we may have on
 http://activity.openstack.org. (see
 https://bugs.launchpad.net/openstack-community/+bug/1205139)
 
 Counting anything in OpenStack, from commits to number of reviews is not
 a race, we don't need to *rank* top contributors.

While I think those stats are useless to identify top contributors
(since the precise metric used will influence who ends up in the top
spots), I think they are useful to identify who does not contribute at
all. In that case 0 commits = 0 lines of code = 0 reviews and the metric
used does not matter that much.

You could say we should not be in the business of shaming people, but
remember that since we use a permissive license, societal pressures
(rather than institutional pressures like the license) are the only way
to force companies to contribute back. The Apache license lets you not
contribute back, but that doesn't mean companies who claim to be an
OpenStack open source team player can get away with not contributing
anything at all...

-- 
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] [Stackalytics] 0.1 release

[Gareth]

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 afreedl...@mirantis.comwrote:

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

 To your argument that the developers will write longer code just for the
 sake of statistics, I think this will not happen en mass. First and
 foremost, the developers care about their reputations and knowing that
 their code is peer-reviewed, very few will intentionally write inefficient
 code just to get their numbers up. Those few who will choose this route
 will lose the respect of their peers and consequently will not be able to
 contribute as much.

 Also, in order to deal with the situations where people can manipulate the
 numbers, Stackalytics allows anyone in the community to correct the line
 count where it does not make sense.  (
 https://wiki.openstack.org/wiki/Stackalytics#Commits_metrics_corrections_and_a_common_sense_approach
 ).

 We welcome any other improvements and suggestions on how to make OpenStack
 statistics more transparent, meaningful and reliable.

 Alex Freedland




 On Tue, Jul 23, 2013 at 7:25 AM, Roman Prykhodchenko 
 rprikhodche...@mirantis.com wrote:

 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 hnarkay...@mirantis.com
 wrote:

 Hello everyone!

 Mirantis http://www.mirantis.com/ is pleased to announce the release
 of Stackalytics http://www.stackalytics.com/ 0.1. You can find
 complete details on the Stackalytics 
 wikihttps://wiki.openstack.org/wiki/Stackalytics page,
 but here are the brief release notes:

- Changed the internal architecture. Main features include advanced
real time processing and horizontal scalability.
- Got rid of all 3rd party non-Apache libraries and published the
source on StackForge under the Apache2 license.
- Improved release cycle tracking by using Git tags instead of
approximate date periods.
- Changed project classification to a two-level structure: OpenStack 
 (core,
incubator, documentation, other) and StackForge.
- Implemented correction mechanism that allows users to tweak metrics
for particular commits.
- Added a number of new projects (Tempest, documentation, Puppet
recipes).
- Added company affiliated contribution breakdown to the user's
profile page.

 We welcome you to read, look it over, and comment.

 Thank you!

 --
 Herman Narkaytis
 DoO Ru, PhD
 Tel.: +7 (8452) 674-555, +7 (8452) 431-555
 Tel.: +7 (495) 640-4904
 Tel.: +7 (812) 640-5904
  Tel.: +38(057)728-4215
 Tel.: +1 (408) 715-7897
 ext 2002
 http://www.mirantis.com

 This email (including any attachments) is confidential. If you are not
 the intended recipient you must not copy, use, disclose, distribute or rely
 on the information contained in it. If you have received this email in
 error, please notify the sender immediately by reply email and delete the
 email from your system. Confidentiality and legal privilege attached to
 this communication are not waived or lost by reason of mistaken delivery to
 you. Mirantis does not guarantee (that this email or the attachment's) are
 unaffected by computer virus, corruption or other defects. Mirantis may
 monitor incoming and outgoing emails for compliance with its Email Policy.
 Please note that our servers may not be located in your country.
  ___
 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 mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Gareth

*Cloud Computing, OpenStack, Fitness, Basketball*
*OpenStack contributor*
*Company: UnitedStack http://www.ustack.com*
*My promise: if you find any spelling or grammar mistakes in my email from
Mar 1 2013, notify me *
*and I'll donate $1 or ￥1 to an open organization you specify.*
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Alex Freedland]

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 academicgar...@gmail.com wrote:

 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 
 afreedl...@mirantis.comwrote:

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

 To your argument that the developers will write longer code just for the
 sake of statistics, I think this will not happen en mass. First and
 foremost, the developers care about their reputations and knowing that
 their code is peer-reviewed, very few will intentionally write inefficient
 code just to get their numbers up. Those few who will choose this route
 will lose the respect of their peers and consequently will not be able to
 contribute as much.

 Also, in order to deal with the situations where people can manipulate
 the numbers, Stackalytics allows anyone in the community to correct the
 line count where it does not make sense.  (
 https://wiki.openstack.org/wiki/Stackalytics#Commits_metrics_corrections_and_a_common_sense_approach
 ).

 We welcome any other improvements and suggestions on how to make
 OpenStack statistics more transparent, meaningful and reliable.

 Alex Freedland




 On Tue, Jul 23, 2013 at 7:25 AM, Roman Prykhodchenko 
 rprikhodche...@mirantis.com wrote:

 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 hnarkay...@mirantis.com
 wrote:

 Hello everyone!

 Mirantis http://www.mirantis.com/ is pleased to announce the release
 of Stackalytics http://www.stackalytics.com/ 0.1. You can find
 complete details on the Stackalytics 
 wikihttps://wiki.openstack.org/wiki/Stackalytics page,
 but here are the brief release notes:

- Changed the internal architecture. Main features include advanced
real time processing and horizontal scalability.
- Got rid of all 3rd party non-Apache libraries and published the
source on StackForge under the Apache2 license.
- Improved release cycle tracking by using Git tags instead of
approximate date periods.
- Changed project classification to a two-level structure: OpenStack 
 (core,
incubator, documentation, other) and StackForge.
- Implemented correction mechanism that allows users to tweak
metrics for particular commits.
- Added a number of new projects (Tempest, documentation, Puppet
recipes).
- Added company affiliated contribution breakdown to the user's
profile page.

 We welcome you to read, look it over, and comment.

 Thank you!

 --
 Herman Narkaytis
 DoO Ru, PhD
 Tel.: +7 (8452) 674-555, +7 (8452) 431-555
 Tel.: +7 (495) 640-4904
 Tel.: +7 (812) 640-5904
  Tel.: +38(057)728-4215
 Tel.: +1 (408) 715-7897
 ext 2002
 http://www.mirantis.com

 This email (including any attachments) is confidential. If you are not
 the intended recipient you must not copy, use, disclose, distribute or rely
 on the information contained in it. If you have received this email in
 error, please notify the sender immediately by reply email and delete the
 email from your system. Confidentiality and legal privilege attached to
 this communication are not waived or lost by reason of mistaken delivery to
 you. Mirantis does not guarantee (that this email or the attachment's) are
 unaffected by computer virus, corruption or other defects. Mirantis may
 monitor incoming and outgoing emails for compliance with its Email Policy.
 Please note that our servers may not be located in your country.
  ___
 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 mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Gareth

 *Cloud Computing, OpenStack, Fitness, Basketball*
 *OpenStack contributor*
 *Company: UnitedStack http://www.ustack.com*
 *My promise: if you find any spelling or grammar mistakes in my email
 from Mar 1 2013, notify me *
 *and I'll donate $1 or ￥1 to an open organization you specify.*

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

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

[Stefano Maffulli]

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 metric per se: like any other
metric it becomes bad when used in an evile context. I'm getting more
and more convinced that it's a mistake to show ranks and classifications
in the dashboard and I'll be deleting all the ones that we may have on
http://activity.openstack.org. (see
https://bugs.launchpad.net/openstack-community/+bug/1205139)

Counting anything in OpenStack, from commits to number of reviews is not
a race, we don't need to *rank* top contributors. What we need is to
identify trends. Practical example: in the report for Grizzly, most
metrics put Red Hat and IBM visibly on top of many charts, while in
Folsom their contributions were much lower. The story of those numbers
was that IBM and Red Hat changed gear since Folsom and from 'involved'
became visibly and concretely 'committed'.  The story of those metrics
was not that Red Hat was first or second in some sort of race.

We should keep in mind that commits or bug resolutions to different
projects are not directly comparable, that line charts can damage the
appearance of some companies/people (loose face). Other charts need to
be explored (punch cards?) and avoid direct comparisons, maybe?

/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] [Stackalytics] 0.1 release

[Alex Freedland]

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

To your argument that the developers will write longer code just for the
sake of statistics, I think this will not happen en mass. First and
foremost, the developers care about their reputations and knowing that
their code is peer-reviewed, very few will intentionally write inefficient
code just to get their numbers up. Those few who will choose this route
will lose the respect of their peers and consequently will not be able to
contribute as much.

Also, in order to deal with the situations where people can manipulate the
numbers, Stackalytics allows anyone in the community to correct the line
count where it does not make sense.  (
https://wiki.openstack.org/wiki/Stackalytics#Commits_metrics_corrections_and_a_common_sense_approach
).

We welcome any other improvements and suggestions on how to make OpenStack
statistics more transparent, meaningful and reliable.

Alex Freedland




On Tue, Jul 23, 2013 at 7:25 AM, Roman Prykhodchenko 
rprikhodche...@mirantis.com wrote:

 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 hnarkay...@mirantis.com
 wrote:

 Hello everyone!

 Mirantis http://www.mirantis.com/ is pleased to announce the release of
 Stackalytics http://www.stackalytics.com/ 0.1. You can find complete
 details on the Stackalytics 
 wikihttps://wiki.openstack.org/wiki/Stackalytics page,
 but here are the brief release notes:

- Changed the internal architecture. Main features include advanced
real time processing and horizontal scalability.
- Got rid of all 3rd party non-Apache libraries and published the
source on StackForge under the Apache2 license.
- Improved release cycle tracking by using Git tags instead of
approximate date periods.
- Changed project classification to a two-level structure: OpenStack (core,
incubator, documentation, other) and StackForge.
- Implemented correction mechanism that allows users to tweak metrics
for particular commits.
- Added a number of new projects (Tempest, documentation, Puppet
recipes).
- Added company affiliated contribution breakdown to the user's
profile page.

 We welcome you to read, look it over, and comment.

 Thank you!

 --
 Herman Narkaytis
 DoO Ru, PhD
 Tel.: +7 (8452) 674-555, +7 (8452) 431-555
 Tel.: +7 (495) 640-4904
 Tel.: +7 (812) 640-5904
 Tel.: +38(057)728-4215
 Tel.: +1 (408) 715-7897
 ext 2002
 http://www.mirantis.com

 This email (including any attachments) is confidential. If you are not the
 intended recipient you must not copy, use, disclose, distribute or rely on
 the information contained in it. If you have received this email in error,
 please notify the sender immediately by reply email and delete the email
 from your system. Confidentiality and legal privilege attached to this
 communication are not waived or lost by reason of mistaken delivery to you.
 Mirantis does not guarantee (that this email or the attachment's) are
 unaffected by computer virus, corruption or other defects. Mirantis may
 monitor incoming and outgoing emails for compliance with its Email Policy.
 Please note that our servers may not be located in your country.
  ___
 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 mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Stackalytics] 0.1 release

[Herman Narkaytis]

Hello everyone!

Mirantis http://www.mirantis.com/ is pleased to announce the release of
Stackalytics http://www.stackalytics.com/ 0.1. You can find complete
details on the Stackalytics
wikihttps://wiki.openstack.org/wiki/Stackalytics page,
but here are the brief release notes:

   - Changed the internal architecture. Main features include advanced real
   time processing and horizontal scalability.
   - Got rid of all 3rd party non-Apache libraries and published the source
   on StackForge under the Apache2 license.
   - Improved release cycle tracking by using Git tags instead of
   approximate date periods.
   - Changed project classification to a two-level structure: OpenStack (core,
   incubator, documentation, other) and StackForge.
   - Implemented correction mechanism that allows users to tweak metrics
   for particular commits.
   - Added a number of new projects (Tempest, documentation, Puppet
   recipes).
   - Added company affiliated contribution breakdown to the user's profile
   page.

We welcome you to read, look it over, and comment.

Thank you!

-- 
Herman Narkaytis
DoO Ru, PhD
Tel.: +7 (8452) 674-555, +7 (8452) 431-555
Tel.: +7 (495) 640-4904
Tel.: +7 (812) 640-5904
Tel.: +38(057)728-4215
Tel.: +1 (408) 715-7897
ext 2002
http://www.mirantis.com

This email (including any attachments) is confidential. If you are not the
intended recipient you must not copy, use, disclose, distribute or rely on
the information contained in it. If you have received this email in error,
please notify the sender immediately by reply email and delete the email
from your system. Confidentiality and legal privilege attached to this
communication are not waived or lost by reason of mistaken delivery to you.
Mirantis does not guarantee (that this email or the attachment's) are
unaffected by computer virus, corruption or other defects. Mirantis may
monitor incoming and outgoing emails for compliance with its Email Policy.
Please note that our servers may not be located in your country.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev