| Summary: | update contribution process in contributor reference | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Steffen Pingel <steffen.pingel> |
| Component: | Mylyn | Assignee: | 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
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 |