|[jgit-dev] Re: iplog for JGit|
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  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.
Back to the top