Community
Participate
Working Groups
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
Additionally, add a note about execution environments: bug 357779.
> 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).
(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.
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).
Sounds good to me - guidelines rather than hard-and-fast rules on this will help to lubricate the process.
> 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)
Also need to update the contributor reference for: * Run builds and tests with Maven * Use Gerrit to stage changes for review
Update section to include information about changes to target definitions: * http://wiki.eclipse.org/Mylyn/Contributor_Reference#Target_Environment
I have updated the contributor reference as discussed. These sections have changed significantly: http://wiki.eclipse.org/Mylyn/Contributor_Reference#Project_Structure http://wiki.eclipse.org/Mylyn/Contributor_Reference#Setup http://wiki.eclipse.org/Mylyn/Contributor_Reference#Reviews http://wiki.eclipse.org/Mylyn/Contributor_Reference#Applying_Patches http://wiki.eclipse.org/Mylyn/Contributor_Reference#Maven
