|[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 , 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 > >  > 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  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.
Back to the top