Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 491917

Summary: Track "sponsor" company in Git commits
Product: Community Reporter: Wayne Beaton <wayne.beaton>
Component: ProcessAssignee: Eclipse Management Organization <emo>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: mike.milinkovich
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard: stalebug

Description Wayne Beaton CLA 2016-04-18 10:13:11 EDT
We do a very good job of matching commits to the sponsoring member company in the case when the author is a committer. We do have an issue with historical affiliation information, but we'll address that separately.

Our database does not, however, capture the information required to map a commit to a member company when the commit is authored by a contributor who is not a committer.

We can probably be a bit clever with email address patterns, but this will fail in cases where the contributor uses, for example, a gmail address.

It should be a relatively simple matter to encourage contributors working for member companies to include an extra footer in their commit messages.

e.g. add a "Sponsor:" footer item:

--
commit 862e6ff22ad56c10df6de3385ffa4c7d02363d1d
Author: Joe Somebody <somebody@someplace.net>
Date:   Mon Jun 17 17:19:38 2013 -0700

    [410937] Auto share multiple projects in single job
    
    When multiple projects are imported together, perform all the necessary
    auto shares in a single job rather than spawning a separate job for each
    project.
    
    Bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=410937
    Also-by: Some Otherperson <otherperson@someplace.net>
    Sponsor: 656 (IBM)
    Signed-off-by: Joe Somebody <somebody@someplace.net>
--

This will only work if we have a consistent means of expressing the company identity. In this example, I'm assuming the use of EF Database-assigned organization id, followed by arbitrary text that we would ignore during extraction. A textual key would probably be better, but will make it more challenging as we would have to deal with variation.

There's really nothing stopping anybody from adding this to their commits today, so I'm not too concerned about gaming. That, and we only report on contributions from EF member companies anyway.

This is just an idea at this point. Poke holes...
Comment 1 Eclipse Genie CLA 2018-04-09 17:01:42 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 2 Eclipse Genie CLA 2020-03-30 05:24:27 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 3 Wayne Beaton CLA 2020-03-30 11:00:25 EDT
Closing as WONTFIX. We can reopen if there is interest.