[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[jgit-dev] Re: iplog for JGit
|
Wayne Beaton <wayne@xxxxxxxxxxx> wrote:
> Just drop the affiliation. Like I said, we can sort that out.
>
> If you look on the project summary page [1], there is a list of
> committers. If you hover over one of the names, the URL for that link
> contains the UNIX id for the user (param=[userId]).
Thanks.
> I can guarantee that the IP Team will have a problem with the "Code
> Review" user. If I'm understanding correctly, these contributions aren't
> really new IP anyway. Can you just drop that user?
Yea, I'm working on it. I think I can trivially drop it by just
having the rule that says "commits that have no impact at all on
*any* file aren't reported".
On the one hand, I don't like hiding data, but on the other hand,
its pretty true, if there was 0 impact to the actual files, there
really isn't any IP concern, is there? :-)
> HTH,
>
> Wayne
>
> [1]
> http://eclipse.org/projects/project_summary.php?projectid=technology.egit
>
> Shawn O. Pearce wrote:
>> Wayne Beaton <wayne@xxxxxxxxxxx> wrote:
>>
>>> This exercise has been helpful. Thank you for that.
>>>
>>
>> I agree. We need to get our IP log for JGit ready, because we're
>> trying to hit a Feb 10th release. :-)
>>
>>
>>> Yes. Contributor Id is their bugzilla email.
>>>
>>
>> OK. I will modify our generator to produce that.
>>
>>
>>> If the committers are using the same email address in Gerrit that
>>> they're using in their Eclipse Foundation record, we should be able
>>> to determine affiliation. The automated tools only provide this
>>> information because they can; it's not strictly required.
>>>
>>
>> Hmm, OK. Then I can drop the affiliation attribute from output?
>>
>> Unfortunately, our committers are using multiple email addresses.
>> For example, my public identity for this project is actually
>> "spearce@xxxxxxxxxxx", despite my $DAY_JOB employer being Google
>> who also allows me to spend $DAY_JOB time on the EGit/JGit project.
>>
>> If I can only report one email address in the IP log XML, I'm likely
>> to pick the spearce.org address for myself, because that's the one
>> that my commits are actually attributed as.
>>
>> So, how to proceed?
>>
>> Basically, I have a _list_ of verified email addresses for each
>> committer, and a change is attributed to them if one of those is
>> a match to the committer identity in the change. I could give you
>> that list in the IP log XML if you give me a way to store it.
>>
>>
>>> What you need is the identity of the committers. The Project Log
>>> documentation [1] suggests that we need the UNIX name. Other
>>> projects provide the name. As long as we have the identity, we
>>> should be good to go. The new IP Log Tool (from project Woolsey
>>> which is being proposed now) can obtain all of this information for
>>> you automatically. So, we can get it totally right in the log for a
>>> future version. In the meantime, you've provided enough information
>>> that we can figure out anything we need.
>>>
>>
>> I could also try to require that my project committers to make
>> their Gerrit username match their UNIX username. Then I can just
>> dump the UNIX username for you in the id field. That might be the
>> easiest solution to the problem here.
>>
>> OK, that's what we shall do. Is there someplace I can get the list
>> of UNIX usernames who are committers on my projects? I'd like to do
>> a cursory review to make sure everyone is using the right identity.
>>
>>
>>> You only need to list contributions from non-committers. This is
>>> where it gets a little silly: it's time-sensitive. You need to list
>>> contributions that come from folks before the became a committer.
>>>
>>
>> I do. For an example, look at Chris Aniszczyk. He became a
>> committer, but not before a non-committer contribution by him
>> occurred:
>>
>> <iplog:committer active="true" affiliation="eclipsesource.com" firstName="Chris" hasCommits="true" id="2" lastName="Aniszczyk"/>
>>
>> <iplog:contributor id="" name="Chris Aniszczyk">
>> <iplog:bug bug-id="291108" created="2009-10-01 14:12:50" id="144b16d141794ae595184e050d3e3fb6bba5a29a" size="+17 lines" summary="Cleanup MANIFEST.MF in JGit" type="patch"/>
>> </iplog:contributor>
>>
>> :-)
>>
>> So I think we're fine here, the tool takes it into account.
>> It'll even understand a committer leaving, and coming back, and
>> have non-committer contributions in the interim. :-)
>>
>>
>>> Who is the user "Code Review"?
>>>
>>
>> A historical mistake.
>>
>> CVS and SVN don't have this equivilant, but Git and other DVCSen do.
>> What happened was some changes needed to be merged in the commit
>> graph, because parallel development happened in another file. E.g.:
>>
>> by me by "Code Review"
>> | |
>> o--------o-------------M
>> \ /
>> \ /
>> +----------------o
>> |
>> by Robin
>>
>> If both Robin and I created concurrent changes to different files
>> and submitted them, the project temporarily forked. To put the
>> project back together again someone needs to create that merge commit
>> "M" above. Gerrit Code Review writes that commit automatically if
>> the merge is clean (no conflicts).
>>
>> Older versions of the Gerrit software attributed these merge nodes
>> to a generic user account, "Code Review".
>>
>> Newer versions now attribute these merge nodes to the committer who
>> pushes the button that causes the action to take place. So these
>> 8 merges are listed here... but we shouldn't see any others.
>>
>> I might be able to drop these out of the ip log by looking to
>> see if the merge introduced any changes relative to the parents.
>> In these 8 merges, no changes were introduced, the merge was just
>> a graph join operation and had no impact on the actual source code.
>> I could have the tool mask these out. I'll try to fix that today.
>>
>
> --
> Wayne Beaton, The Eclipse Foundation
> http://www.eclipse.org
>
> I'm going to EclipseCon!
> http://www.eclipsecon.org
>
--
Shawn.
