Re: [openstack-dev] [stackalytics] [deb] [packaging] OpenStack contribution stats skewed by deb-* projects
On 09/21/2016 03:44 PM, Ian Cordasco wrote: > Thomas, > > As you already pointed out, where it matters, the analysis of > commits is correct. I'm sure the Stackalytics team has prioritized > this as they see appropriate. I've asked because I would like to attempt to fix it myself, considering 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
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
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
-Original Message- From: Thomas Goirand Reply: OpenStack Development Mailing List (not for usage questions) Date: September 21, 2016 at 08:40:07 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [stackalytics] [deb] [packaging] OpenStack contribution stats skewed by deb-* projects > On 09/20/2016 10:30 PM, Ilya Shakhat wrote: > > Hi, > > > > tldr; Commits stats are significantly skewed by deb-* projects > > (http://stackalytics.com/?metric=commits&module=packaging-deb-group) > > > > By default Stackalytics processes commits from project's master branch. > > For some "old core" projects 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
On 09/20/2016 10:30 PM, Ilya Shakhat wrote: > Hi, > > tldr; Commits stats are significantly skewed by deb-* projects > (http://stackalytics.com/?metric=commits&module=packaging-deb-group) > > By default Stackalytics processes commits from project's master branch. > For some "old core" projects 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
2016-09-21 14:37 GMT+03:00 Thierry Carrez : > Ilya Shakhat wrote: > > Hi, > > > > tldr; Commits stats are significantly skewed by deb-* projects > > (http://stackalytics.com/?metric=commits&module=packaging-deb-group) > > > > By default Stackalytics processes commits from project's master branch. > > 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
Ilya Shakhat wrote: > Hi, > > tldr; Commits stats are significantly skewed by deb-* projects > (http://stackalytics.com/?metric=commits&module=packaging-deb-group) > > By default Stackalytics processes commits from project's master branch. > For some "old core" projects there is configuration to 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
Hi, tldr; Commits stats are significantly skewed by deb-* projects ( http://stackalytics.com/?metric=commits&module=packaging-deb-group) By default Stackalytics processes commits from project's master branch. For some "old core" projects there is configuration to process stable branches as well. 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