[openstack-dev] [stackalytics] [deb] [packaging] OpenStack contribution stats skewed by deb-* projects
Ian Cordasco
sigmavirus24 at gmail.com
Wed Sep 21 13:44:28 UTC 2016
-----Original Message-----
From: Thomas Goirand <zigo at debian.org>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: September 21, 2016 at 08:40:07
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at 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&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
More information about the OpenStack-dev
mailing list