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

Bug 356418

Summary:	Allow non-committers e-mail addresses in git commits
Product:	Community	Reporter:	Doug Schaefer <cdtdoug>
Component:	Git	Assignee:	Eclipse Webmaster <webmaster>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	angvoz.dev, daniel_megert, jamesblackburn+eclipse, marc.khouzam, overholt, pawel.1.piech, remy.suen, wayne.beaton
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Doug Schaefer

2011-08-31 18:38:52 EDT

A standard git workflow is to fetch commits from remotes, merge them into master branches, and push them to the golden repo.

Of course, the current restriction at Eclipse is that the committer e-mail address must be of a valid Eclipse committer. However when a contributor is working on github, for example, it'll be their e-mail address registered in the commit record.

This is creating extra work for us to figure out how to do this important workflow. For CDT we have three projects on the go from contributors that we want to bring into CDT once they're ready.

One simple idea is to keep a database of approved commit ids. So if the e-mail check fails, check the commit ids against this database.

Comment 1 Doug Schaefer

2011-08-31 18:40:44 EDT

The IPzilla would list the commit ids (URLs to github, for example). Once approved, they'd be entered into the database.

Comment 2 Wayne Beaton

2011-09-06 12:47:24 EDT

Can we assume that the contributor in this scenario is always an existing Eclipse committer?

We need to keep in mind that we currently do not import history with a contribution. If I understand your scenario, work developed at GitHub will--at some point--be brought to Eclipse. At this point, the code needs to be checked by the IP Team. They are not able to check history, so--at this point--we'd require that a code base be taken through the IP process and that snapshot would have to be committed.

Comment 3 Doug Schaefer

2011-09-06 13:54:49 EDT

(In reply to comment #2)
> Can we assume that the contributor in this scenario is always an existing
> Eclipse committer?

No, the point is the contributor is not a committer.

> We need to keep in mind that we currently do not import history with a
> contribution. If I understand your scenario, work developed at GitHub will--at
> some point--be brought to Eclipse. At this point, the code needs to be checked
> by the IP Team. They are not able to check history, so--at this point--we'd
> require that a code base be taken through the IP process and that snapshot
> would have to be committed.

Yes, that may be the best solution. We can use command-line git to create a patch, using git-diff, for the contribution. Once approved we can then apply the patch.

I was hoping we could keep the history throughout the off-site development. There may be other approaches to managing that.

And even more ideally, we can move to Gerrit and do the development there. :p

Comment 4 Wayne Beaton

2011-09-06 16:40:29 EDT

Moving the history of a contribution is currently not permitted. To change that would require a board resolution; this is something to explore with the committer reps if there is will (FWIW, keeping history would--under current rules--require that the history be scanned by the IP team thereby stretching already-thin resources).

Another work around: you can do the exploratory work in an incubator.

I'm not sure what else we can do to resolve this bug. Is it time to close it?

Comment 5 Doug Schaefer

2011-09-07 10:25:11 EDT

Yeah, sure. It is what it is, I guess.