Re: [openstack-dev] [stackalytics] [deb] [packaging] OpenStack contribution stats skewed by deb-* projects

[Thomas Goirand]

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

[Jeremy Stanley]

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

[Thierry Carrez]

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

[Ian Cordasco]

 

-Original Message-
From: Thomas Goirand <z...@debian.org>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: September 21, 2016 at 08:40:07
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@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=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

[Thomas Goirand]

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=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

[Ilya Shakhat]

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=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

[Thierry Carrez]

Ilya Shakhat wrote:
> Hi,
> 
> tldr; Commits stats are significantly skewed by deb-* projects
> (http://stackalytics.com/?metric=commits=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

[Ilya Shakhat]

Hi,

tldr; Commits stats are significantly skewed by deb-* projects (
http://stackalytics.com/?metric=commits=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