<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2016-09-21 14:37 GMT+03:00 Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Ilya Shakhat wrote:<br>
> Hi,<br>
><br>
> tldr; Commits stats are significantly skewed by deb-* projects<br>
> (<a href="http://stackalytics.com/?metric=commits&module=packaging-deb-group" rel="noreferrer" target="_blank">http://stackalytics.com/?<wbr>metric=commits&module=<wbr>packaging-deb-group</a>)<br>
><br>
> By default Stackalytics processes commits from project's master branch.<br>
> For some "old core" projects there is configuration to process stable<br>
> branches as well. If some commit is cherry-picked from master to stable<br>
> it is counted twice in both branches / releases. The configuration for<br>
> stable branch is simple - branch starting with branching point (e.g.<br>
> stable/newton that starts with rc1)<br>
><br>
> In deb-* projects master branch corresponds to upstream Debian<br>
> community. All OpenStack-related contribution goes into debian/<release><br>
> branch. But unlike in the rest of OpenStack, git workflow differs and<br>
> the branch contains merge commits from master. This makes filtering<br>
> "pure" branch commits from those that came from master quite tricky (not<br>
> possible to specify the branch-point). And support of this will require<br>
> changes in Stackalytics code.<br>
><br>
> Since currently we are at the time when people may get nervous about<br>
> numbers, I'd suggest to temporary hide all commits from deb-* projects<br>
> and revise stats processing in a month.<br>
<br>
</span>Sounds good. Are you working on it ?</blockquote><div><br></div><div>Yep. I'm working on this, will update on the results.</div><div><br></div><div>--Ilya Shakhat </div></div></div></div>