Bugzilla – Full Text Bug Listing
| Summary: | Process for accepting GitHub pull requests | ||
|---|---|---|---|
| Product: | Community | Reporter: | Wayne Beaton <wayne.beaton> |
| Component: | Git | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | adietish, caniszczyk, denis.roy, gunnar, irbull, jacek.pospychala, jeremie.bresson, jesse.mcconnell, kevin, KevinSawicki, matthias.sohn, mistria, pnehrer, robin, sbouchet, stephan.leichtvogt, thatnitind |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | stalebug | ||
|
Description
Wayne Beaton
Currently Eclipse repo at GitHub are mirror of Git repos at Eclipse.org. Will mirroring still work if we start working (ie merge pull requests) on GitHub repos? Multiplying tools (Gerrit + GitHub) will increase the amount of work for "mergers". It would probably be better to be able to rely on a single one (Gerrit). Would it be possible to import GitHub pull requests as Gerrit contirutions at Eclipse.org? We could think about a script that polls GitHub and imports pull requests to Gerrit and sends a mail to GitHub contributor telling him that his pull request is followed on Gerrit (with a link). The difficult part here is that for some users, it would mean automatically create an Eclipse.org account for the,. If we choose that way, it has the advantage of removing need to set up new tools, processes & policies. I've added Kevin Sawicki to the conversation; he should be able to answer the GitHub questions. (In reply to comment #1) > Currently Eclipse repo at GitHub are mirror of Git repos at Eclipse.org. > Will mirroring still work if we start working (ie merge pull requests) on > GitHub repos? Based on my understanding of how Git works, the mirroring should still work. Kevin, can you confirm. > Multiplying tools (Gerrit + GitHub) will increase the amount of work for > "mergers". It would probably be better to be able to rely on a single one > (Gerrit). I prefer to avoid adding burden to developers (or mergers). I'm trying to smooth out the process for projects that opt to use GitHub. There's no rule that says that you have to use GitHub at all. Ultimately, each project has to decide for themselves how they will interact with adopters. Having said that, projects need to have some flexibility. If contributors come to GitHub in droves, then you really need to spend some time there. > Would it be possible to import GitHub pull requests as Gerrit contirutions > at Eclipse.org? We could think about a script that polls GitHub and imports > pull requests to Gerrit and sends a mail to GitHub contributor telling him > that his pull request is followed on Gerrit (with a link). I'm not sure if this is possible. Sounds like a cool idea if we could make it work. > The difficult > part here is that for some users, it would mean automatically create an > Eclipse.org account for the,. This is probably the biggest challenge; automatically-created accounts do not have the legal protections that we get when a user creates their own account. > If we choose that way, it has the advantage of removing need to set up new > tools, processes & policies. The landscape always has and always will change. We need to constantly adapt to stay current and relevant. As I suggested earlier, if the world decides that they want to come to your project through GitHub, then you'd be crazy not to meet them there. You can push to a mirrored GitHub repository but the repository will still updates from its source URL meaning the commits pushed to GitHub will disappear the next time the mirror updates if they aren't in the source repository. (In reply to comment #2) > I've added Kevin Sawicki to the conversation; he should be able to answer > the GitHub questions. > > (In reply to comment #1) > > Currently Eclipse repo at GitHub are mirror of Git repos at Eclipse.org. > > Will mirroring still work if we start working (ie merge pull requests) on > > GitHub repos? > > Based on my understanding of how Git works, the mirroring should still work. > Kevin, can you confirm. FWIW, I found two very good reads: https://github.com/SpringSource/spring-framework/wiki/Manually-merging-pull-requests https://help.github.com/articles/using-pull-requests Especially the SpringSource case is a good template (IMHO) to how things can be done. I think there are only two differences for Eclipse projects. 1. You need to due IP clearance before starting the merge 2. The final "origin" to push master to won't be GitHub but Eclipse.org which then gets mirrored to GitHub. I'm ok with number two. I'm also ok with number one. It seems to be very easy to download a pull request as a patch and attach that to a CQ. The way I see it, the author would remain the contributor. But if I don't squash all the commits before merging into master I won't be able to push it to Eclipse.org because the comitter email will be different. There is a script that ensures the committer id is the same person that pushes. However, that might not be a problem if I squash all the commits before the merge. This changes the committer to me. Kevin, do you know if there is metadata in commit message that indicates if the merge involves a pull request? It would be very convenient if GitHub recognizes on the next sync that I merged a commit from a pull request and auto-closes the pull request. (In reply to comment #1) > Multiplying tools (Gerrit + GitHub) will increase the amount of work for > "mergers". It would probably be better to be able to rely on a single one > (Gerrit). As the initiator of the request to EMO, I'd like to state that the request actually evolved because of me using Gerrit. I'm sorry, but I find GitHub pull requests much more appealing than working with Gerrit. There is also evidence in our team that getting started with GitHub and pull requests is easier than getting started with Gerrit. However, as stated by Wayne, it should not be considered another systems that projects have to use. It really is just an option for projects, i.e. "opt-in" model (as is Gerrit, btw). If merged via the merge button the merge commit does include metadata about the pull request. Otherwise no additional metadata is included in the commit message beyond what the author has entered. (In reply to comment #4) > Kevin, do you know if there is metadata in commit message that indicates if > the merge involves a pull request? It would be very convenient if GitHub > recognizes on the next sync that I merged a commit from a pull request and > auto-closes the pull request. (In reply to comment #3) > You can push to a mirrored GitHub repository but the repository will still > updates from its source URL meaning the commits pushed to GitHub will > disappear the next time the mirror updates if they aren't in the source > repository. So that means that while GitHub repos are just mirrors, we can't expect the pull request to work for Eclipse projects. So I'm back to the idea of importing pull requests: * If the submitter email matches an Eclipse.org login, import the Pull Request to Gerrit, and annotate the Pull Request on GitHub to link to the relevant Gerrit entry * If the submitter email does not match an Eclipse.org login, send a mail pointing to this pull request to the <project>-dev@eclipse.org list, and annotate PR on GitHub to encourage contributor to use Gerrit. Also link him to the <project>-dev@eclipse.org list since he'll probably need some guidance for his contribution. Maybe the Eclipse Foundation should enforce usage and creation of a "CONTRIBUTING" file to guide people to Bugzilla or Gerrit before doing a Pull Request: https://github.com/blog/1184-contributing-guidelines (In reply to comment #8) > Maybe the Eclipse Foundation should enforce usage and creation of a > "CONTRIBUTING" file to guide people to Bugzilla or Gerrit before doing a > Pull Request: https://github.com/blog/1184-contributing-guidelines +1 except for the enforce part. Unless this is something that we can do automatically. Perhaps "encourage" or "suggest" are more appropriate words. I have added a "Recommended Practices" section [1] to the Git wiki page. [1] http://wiki.eclipse.org/Git#Recommended_Practices (In reply to comment #0) > The eclipse.org repository is subject to the terms of the IP Due Diligence > process. If the process so dictates, a CQ must be created and processed for > a commit before it can be pulled into the eclipse.org repository. The > contribution must be recorded in the IP Log, and--at least as of this > point--the contributor must have answered the notorious three questions. Wayne, I just found this: http://wiki.eclipse.org/Development_Resources/Handling_Git_Contributions Is this the preferred process to follow? Just to confirm, I'll outline the steps I intend to do. 1. As I got a first pull request, I'll open a bug and ask the three magic questions. 2. Once that is in, I'll pull the commit and merge it into my local Git repository cloned from Eclipse.org. 3. I'll amend the commit in order to mark me as the committer. This is necessary to satisfy the Eclipse.org push hook committer check. 4. While amending the commit I'll retain the original author information in order to allow automatic detection of the contribution by the IP Log tool. Kevin, (In reply to comment #6) > If merged via the merge button the merge commit does include metadata about > the pull request. > > Otherwise no additional metadata is included in the commit message beyond > what the author has entered. It would be really nice to have something like Gerrit's Change-ID in the commit message to allow automatic discovery of merged pull requests. Otherwise the process seems to be broken from a GitHub's perspective. (In reply to comment #10) > Wayne, I just found this: > http://wiki.eclipse.org/Development_Resources/Handling_Git_Contributions > > Is this the preferred process to follow? Just to confirm, I'll outline the > steps I intend to do. > > 1. As I got a first pull request, I'll open a bug and ask the three magic > questions. > > 2. Once that is in, I'll pull the commit and merge it into my local Git > repository cloned from Eclipse.org. > > 3. I'll amend the commit in order to mark me as the committer. This is > necessary to satisfy the Eclipse.org push hook committer check. > > 4. While amending the commit I'll retain the original author information in > order to allow automatic detection of the contribution by the IP Log tool. Correct. The contributor needs to answer the three questions themselves, directly in Bugzilla. We need the contributor to agree to our terms of use; the best way to do this is to get them to create the eclipse.org account required to respond on Bugzilla. (In reply to comment #11) > Kevin, > > (In reply to comment #6) > > If merged via the merge button the merge commit does include metadata about > > the pull request. > > > > Otherwise no additional metadata is included in the commit message beyond > > what the author has entered. > > It would be really nice to have something like Gerrit's Change-ID in the > commit message to allow automatic discovery of merged pull requests. > Otherwise the process seems to be broken from a GitHub's perspective. The default commit message when merging pull requests includes the pull request number, repository, and branch. For example: https://github.com/github/hubot/commit/4571d541ade89f8fccec1ff2b2c851c1ffb6eb6e FWIW, we almost forbid usage of the GitHub "merge" button on pull request for JBoss Tools components. It actually adds a lot of "merge" commits when we prefer rebasing and keeping history readable (mostly linear). So in the end, we deal with merges manually, using git pull --rebase when possible, and only when it's not straightforward, we let a merge commit appear; but the merge commit also contains necessary changes, not only the merge metadata (multiple parents). I think I would use the same process for Eclipse projects. I just found this Bug on the MediaWiki Bugzilla: https://bugzilla.wikimedia.org/show_bug.cgi?id=35497 It seems to me that each organization/foundation tries to do the same... What is the status on this? https://www.eclipse.org/org/SocialCodingFAQ.php That page has not been updated since June 2013... updated for anyone else that stumbled across this issue https://wiki.eclipse.org/Social_Coding/Hosting_a_Project_at_GitHub can this be closed then? Jesse, I'm not sure what you're asking. Since this bug has been opened, we've allowed projects to host on GitHub, so perhaps this is no longer an issue? This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. (In reply to Denis Roy from comment #18) > Jesse, I'm not sure what you're asking. Since this bug has been opened, > we've allowed projects to host on GitHub, so perhaps this is no longer an > issue? I believe that we're done here. While we haven't completely disassembled all of the mirrors, we've deprecated the concept. Pull requests are pull requests. |