On 09/20/2016 10:30 PM, Ilya Shakhat wrote:
> tldr; Commits stats are significantly skewed by deb-* projects
> 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.
Replying again here (I'm subscribed, so it will go through this time).
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
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
Thomas Goirand (zigo)
OpenStack Development Mailing List (not for usage questions)