On Wed, 2013-11-13 at 21:16 +0000, Stangel, Dan wrote:
> On Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:
>
> > To enable this, we are proposing that the commit text of a patch may
> > include a
> > sponsored-by: <sponsorname>
> > line which could be used by various tools to report on these commits.
> > Sponsored-by should not be used to report on the name of the company
> > the contributor is already affiliated to.
> >
> > We would appreciate to see your comments on the subject and eventually
> > get your approval for it's use.
>
> Rather than including this sponsor information directly in commit logs,
> the metrics tools could attribute specific changesets to a different
> organization. This would override the normal attribution that the
> metrics tools would otherwise make based solely on the committer's own
> affiliation.
>
> gitdm already special-cases some commits. For example, we do this to
> completely omit changesets that should not be counted towards
> contribution metrics, such as automated commits from Jenkins or
> translations [1]. Stackalytics has a similar mechanism [2], and
> activity.openstack.org (metrics-grimoire) may also provide similar
> functionality.
>
> This approach moves the recognition completely out of band from the git
> commit, and closer to where (presumably) it will be recognized by the
> community and the sponsor. Yet it would allows special attributions to
> be transparently documented and maintained by, and within, the
> community.
I find this approach quite doable. On the one hand, any developer not
interested would not need to do anything about all this, and will not
even find that information by reading commit logs or other
developer-oriented information. On the other, those interested will
update that out-of-band information according to their interests. Anyone
interested in knowing about all of this, will be able of finding, and
checking, the relevant information.
The only thing would be to define a format for specifying how a certain
changeset is attributed to a certain organization. Probably we need to
consider at least two cases:
- Commits by a certain developer, during a certain period.
- Specific commits.
A format could be something like:
Attribution:Commit-period:Developer:start_date:end_date
Attribution:Single-commit:commit_hash
Attribution would be the name of the organization being "attributed".
A file managed with the usual code review process could include all this
information.
Those commits not matched by this file would be attributed "as usual".
Well, just my two eurocents...
Saludos,
Jesus.
> Dan
>
> [1]
> https://github.com/openstack-infra/gitdm/blob/master/openstack-config/grizzly
> - the list of commit IDs in parentheses are omitted from metrics totals
> [2]
> https://github.com/stackforge/stackalytics/blob/master/etc/corrections.json -
> stackalytics provides for finer-grained "corrections" to specific changesets.
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
--
Bitergia: http://bitergia.com http://blog.bitergia.com
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
