Open Stack

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/<release>
> 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)