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

Bug 354497

Summary: update contribution process in contributor reference
Product: z_Archived Reporter: Steffen Pingel <steffen.pingel>
Component: MylynAssignee: Steffen Pingel <steffen.pingel>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: P4 CC: b.muskalla, greensopinion, mik.kersten, thomas.ehrnhoefer
Version: unspecified   
Target Milestone: 3.7   
Hardware: PC   
OS: Linux   
URL: http://wiki.eclipse.org/Mylyn/Contributor_Reference
Whiteboard:
Bug Depends on:    
Bug Blocks: 329561    

Description Steffen Pingel CLA 2011-08-11 09:52:53 EDT
The process in http://wiki.eclipse.org/Mylyn/Contributor_Reference#Patches and http://wiki.eclipse.org/Mylyn/Contributor_Reference#Applying_Patches needs to be updated for Git. 

Suggestions from the discussion on bug 354077:

*Contributors*

* Patches should be rooted at the root of the Git repository
* Patches should only contain relevant changes
* http://wiki.eclipse.org/Git_for_Committers#Generating_patches_for_Bugzilla 
* http://wiki.eclipse.org/EGit/User_Guide#Creating_Patches

*Committers*

* Always enter the name of the contributor as the author of the commit
* To track authorship of changes commit the unaltered patch and then make another commit with your changes. A task-branch can be used to group commits and improve traceability.
* All files altered by a contributor must have a note in the copyright header and should have an @author tag if a change was significant
* http://wiki.eclipse.org/Development_Resources/Handling_Git_Contributions
Comment 1 Steffen Pingel CLA 2011-09-29 06:07:55 EDT
Additionally, add a note about execution environments: bug 357779.
Comment 2 David Green CLA 2011-09-29 19:40:37 EDT
>  To track authorship of changes commit the unaltered patch and then make another commit with your changes. A task-branch can be used to group commits and improve traceability.

How does this work with Gerrit?  We usually iterate several times on any patch, and often non-trivial patches can involve small things (like changing a label) that are tedious for contributors to work through.  It seems unreasonable to me that we would expect contributors to iterate on things until they're absolutely perfect (which we tend to do with Gerrit).
Comment 3 Steffen Pingel CLA 2011-09-30 04:23:08 EDT
(In reply to comment #2)
> How does this work with Gerrit?  We usually iterate several times on any patch,
> and often non-trivial patches can involve small things (like changing a label)
> that are tedious for contributors to work through.  It seems unreasonable to me
> that we would expect contributors to iterate on things until they're absolutely
> perfect (which we tend to do with Gerrit).

That is a good point. Gerrit should encourage that kind of collaboration by allowing anyone to push an update to a code review which is often more efficient that nit picking style and labels. Does Git allow specification of multiple authors? This would seem most appropriate if a commit contains changes authored by several people. You could add that as meta-data in the commit message, i.e. "Modified-By: ..." or something like that.

I guess my original statement is a little to strict and not practical. If changes are trivial it's seems reasonable to make those modifications and retain the original author. I often add @author tags, copyright headers etc. or modify labels to comply with UI guidelines without round-triping that through another patch iteration.
Comment 4 Steffen Pingel CLA 2011-09-30 04:26:00 EDT
One more thought on Gerrit: the good thing is that the history of each change is maintained in the Git repository if you push an update to a review that was created by someone else.  You should always be able to fairly easily trace changes back to the author through the version control system that way (and at some point Gerrit will hopefully be hosted at Eclipse.org and retain that history in the there).
Comment 5 David Green CLA 2011-09-30 11:20:56 EDT
Sounds good to me - guidelines rather than hard-and-fast rules on this will help to lubricate the process.
Comment 6 Benjamin Muskalla CLA 2011-09-30 11:45:49 EDT
> Does Git allow specification of multiple
> authors? This would seem most appropriate if a commit contains changes authored
> by several people. You could add that as meta-data in the commit message, i.e.
> "Modified-By: ..." or something like that.

As far as I know, git doesn't support properly multiple authors. One convention I know from several project is to use __Co-authored-by:__ (see also this post: http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg782550.html)
Comment 7 Steffen Pingel CLA 2011-10-07 09:42:52 EDT
Also need to update the contributor reference for:

* Run builds and tests with Maven
* Use Gerrit to stage changes for review
Comment 8 Steffen Pingel CLA 2011-10-07 09:44:34 EDT
Update section to include information about changes to target definitions:
* http://wiki.eclipse.org/Mylyn/Contributor_Reference#Target_Environment