codereview: accept Github PRs #18517
Comments
|
How would the CLA happen? My understanding is that currently you can't make a Gerrit CL without having already jumped through the CLA hoop. If we auto-make a Gerrit CL, we'd have un-CLAd CLs floating around. Mark them in big red letters, maybe? |
|
@randall77, Google has an official bot for CLA checking already. We just have to flip a bit to turn it on. |
|
(The CLA check would happen on the PR before the Gerrit CL is created.) |
|
Is Gerrit a requirement? I'm asking because Github recently released improved versions of reviewing Code at Github. Some parts (such as commenting on the code) is now similar to Gerrit. Also say we opened a PR from Github, is the Contributor required to do anything in Gerrit or is only used for merging/testing? I'm curious about the boundary (I just contributed once via Gerrit so don't remember quite the details anymore |
|
What about feedback? If someone files a PR and it gets converted to a Gerrit CL, they might not know how or be willing to reply to any comments or update the code. |
|
@fatih, Gerrit is still a requirement. GitHub has made improvements, but it's still not as powerful as Gerrit. Moving off Gerrit would be way too big of a change to be palatable. @mvdan, as I wrote above:
You can see this in action at grpc/grpc-go#546 for example. The bot is barely a prototype at this point and could be improved to leave better messages on Github. |
|
Taking a look at the grpc issue, I'm a bit skeptical as to the value this strategy adds. Users get to contribute changes in a more familiar way, but as soon as a code review is posted, we're in unfamiliar territory again. I suspect that, as a result of this change, we'll see a lot of abandoned contributions proposed by people who didn't know what they were getting into and don't have an interest in figuring this all out. Learning Gerrit is a pill contributors still need to swallow, regardless. That said, I appreciate the effort the Go team is making to improve this process. |
It's something to learn, yes, but it's not as much of a mountain as our current process. Also, the new Gerrit UI is coming along nicely and will probably be the default at about the same time we're done with this, lowering the bar as well. |
|
I would also love to see Trybots integration to push the CI results back to the PR. If no one is working on that, I can. |
|
@rakyll, that'd be nice, but it's a bit soon for that. Let's get Hello World working first, and then we can do that fanciness. |
|
( @rakyll did this get closed by accident? ) |
|
YES YES YES YES! |
|
👍 This would be nice. As someone who rarely uses Gerrit or the gocontribute tool, I've found it necessary to review the rather lengthy Contribution Guidelines #17802 every time. Honestly, that is a deterrent when wanting to make a small change, such as fixing a typo in the release notes. I do have the same question (#18517 (comment)) as @fatih and I'm not convinced that Gerrit is still more powerful. It seems far simpler to join language communities like Microsoft TypeScript, Mozilla Rust, and Apple Swift in using GitHub for development. But I can understand that a lot of tooling has been built up around Gerrit, that it could be the personal preference of all or most regular contributors, and switching tools yet again would be a big undertaking. Which is to say, I think this proposal would be a very nice way to meet the GitHub-using community in the middle. Using Gerrit for review isn't bad -- a few icons are a mystery (e.g. it took me a minute to figure out how to switch to a unified view), but that will likely improve with the new UI. I think the big open question is what happens when somebody pushes a followup commit to GitHub or amends their local commit and force pushes it? Can gerritbot be expected to handle that? Thanks Brad. |
|
Would contributors be able to submit additional versions of their patch set by updating their PR (branch) too, or would they have to switch to Gerrit? As a very occasional Go contributor I find I have to relearn the semantics around creating and publishing patch sets each time, vs GitHub where it's just "push to a branch". (As an open source maintainer I do recognize that Gerrit leads to better patch sets vs PRs where contributors tend to tack more commits on the end during review instead of rewriting, though.) Whereas the discussion part on Gerrit is no trouble. |
|
@glasser Check out GitHub squash commits https://github.com/blog/2141-squash-your-commits It's long been possible for maintainers to squash things first via tools like hub, or for contributors to amend and force push. In the past year, such functionality is just a button on GitHub. It's not identical to the Gerrit cherry-pick system, but accomplishes the same goal (tidy git history). |
|
Would it make sense that the gopherbot also syncronizes it the other way around (Gerrit -> Github)? Because apart from contributing Github PRs also allow people to watch open-source projects development, either through the timeline or the notifications overview panel. That could be great to also have access to the contribution activity through Github, eg. to see what CLs are currently pending, what is merged or refused, possibly what is discussed too. |
It is closed by my issue triaging tool, waffle.io, by mistake :( |
|
@bamarni, that might be nice later once we get the basics working. Or maybe https://dev.golang.org/ will be fleshed out more by then and we'd prefer that dashboard. We'll see. |
|
If gerritbot is just to transfer the initial PR to a CL, what would the transition look like for followup changes based on the review? |
That is not true. Even in the prototype already implemented, it updates Gerrit when a new version of the Github PR arrives. It can also reply and tell users to squash if they're stacking commits on top of each other. |
This should certainly work fine, but let me know if/when you enable this so I can keep a close eye on any CLA issues. There are a few cases I can think of that might cause confusion, depending on how you are creating the Gerrit CL. CLA checking on both GitHub and Gerrit support looking contributors up by email address, but Gerrit has its own internal email alias concept that doesn't apply to GitHub PRs. Similarly, CLA checks on GitHub PRs can be done based solely on GitHub username, even if the git author email is something completely different than what was used to sign the CLA. Gerrit obviously doesn't know or care about GitHub usernames. So I can imagine a case where CLA checking on the GitHub PR succeeds, but subsequently fails when moved over to Gerrit. Anyway, lots of moving pieces, but I'm happy to do what we can on the CLA side to make this easier. |
|
@willnorris, thanks! Yes, I planned on bugging you, @spearce, et al when the time came. |
|
This would be very nice. A week ago I forked x/crypto to add a missing feature to the ssh library[1]. https://golang.org/doc/contribute.html is daunting and I ended up tabling the whole thing until I have a few hours to set aside to setup everything required to submit or even discuss my 10 line patch. |
|
@bradfitz "It can also reply and tell users to squash if they're stacking commits on top of each other." When you merge PRs, you have the option to squash the merge via Github's UI. I've thought it's odd that users are forced to keep squashing commits on their branches... it's especially annoying when the PR author makes several small changes to adhere to feedback and then they need to (continually) 're-squash' them. |
|
Yeah, perhaps the gerritbot should squash the commits by itself,
which makes the live easier for PR authors.
I tried to squash and push -f for github PRs, but github would then
think the different squashed commits are different, and will add
separate notifications to the mentioned issues.
One problem for gerritbot to squash the commit is to figure out
the proper commit message to use. And I don't have good solution
for this problem...
|
Update golang/go#18517 Change-Id: I5c7980d07db368c90c2e76610ee4c854cec27b60 Reviewed-on: https://go-review.googlesource.com/92936 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Update golang/go#18517 Change-Id: I5ea227896265d5612b5efa60850f9e03b9025db6 Reviewed-on: https://go-review.googlesource.com/92937 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
Change https://golang.org/cl/93015 mentions this issue: |
Otherwise you get something like golang/go#23752 (comment) Update golang/go#18517 Change-Id: I5298f1e34738a4f6faa8b829546bf880a237043d Reviewed-on: https://go-review.googlesource.com/93015 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
Change https://golang.org/cl/93035 mentions this issue: |
Update #18517 Change-Id: I76d928d5fcc5ed22beaffb86f0fa8fbf6d4ac3d7 Reviewed-on: https://go-review.googlesource.com/93035 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
Change https://golang.org/cl/93135 mentions this issue: |
Update golang/go#18517 Change-Id: Icdc131236092f15c51effafa71329e280979a0ef Reviewed-on: https://go-review.googlesource.com/93135 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
Change https://golang.org/cl/93335 mentions this issue: |
|
Would it still be possible to submit changes directly to Gerrit? |
|
Yes.
… On 12 Feb 2018, at 06:32, Pietro Gagliardi ***@***.***> wrote:
Would it still be possible to submit changes directly to Gerrit?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Good; thanks. (I'm not opposed to GitHub PRs at all — my own projects use the PR system and GitHub's code review software; I am a bit uncomfortable with having to have a forked repository linger in your repo list, though, but that may just be me not knowing everything about git or GitHub to know why the current system they have is better than just sending over a patch file. That being said, I plan on patching Go from my work computer(s) instead of from my home computer, and was going to just git clone directly instead of going through GitHub, which is why I was asking.) |
Also remove the "Also, please do not post patches on the issue tracker" part, since that didn't seem to reduce the number of patches inlined into bug reports. And now that we accept PRs, people will probably try that first. We'll see. Fixes #23779 Updates #18517 Change-Id: I449e0afd7292718e57d9d428494799c78296a0d2 Reviewed-on: https://go-review.googlesource.com/93335 Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
Change https://golang.org/cl/93355 mentions this issue: |
|
Change https://golang.org/cl/93356 mentions this issue: |
|
Change https://golang.org/cl/93357 mentions this issue: |
|
Filed #23783 to further update documentation. |
Update golang/go#18517 Change-Id: Ia970d648b85cd75831ee0c6969762752e9b49289 Reviewed-on: https://go-review.googlesource.com/93355 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Update golang/go#18517 Change-Id: Iccb7b5c61d8fc161b877d0a39f4ee1c523a4cd75 Reviewed-on: https://go-review.googlesource.com/93356 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
Change https://golang.org/cl/93435 mentions this issue: |
|
This is live. We now accept Pull Requests in all our repos so I’m going to close this as fixed. 🎉 |
Use maintner as a fast-path to determine whether comments are duplicates or not. Update golang/go#18517 Change-Id: I3ddc380e6e202371903ce62ae9e4c07e9805c1ed Reviewed-on: https://go-review.googlesource.com/93435 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
For more information, see https://golang.org/wiki/GerritBot |
|
Awesome work! |
|
Change https://golang.org/cl/104577 mentions this issue: |
and others
I propose we start accepting Github PRs (Pull Requests).
Currently we have a bot auto-close them with a message telling them we don't use PRs and instead use Gerrit.
When we moved to Github, @robpike said:
While that's true, we're still not using Github like Github users use Github.
I believe that our current pushback bot dissuades many potential contributors.
I propose we start accepting pull requests by automatically converting them into Gerrit CLs ("change lists", same as a PR but different terminology). Reviews would still happen on Gerrit and the bot would update the PR of activity on Gerrit. Gerrit is still where we'd run trybots and push the "Merge" button. We would never merge on Github. Gerrit would remain the upstream source-of truth.
I prototyped this syncing in https://github.com/LetsUseGerrit/gerritbot/ and used it a bit while working on gRPC-go (examples), but in the opposite direction: my Gerrit CLs were abandoned after gRPC-go accepted them on Github.
In any case, the point is that this can be automated with a bit of work and rejecting Github PRs or not is a policy decision more than anything. I propose we change our policy.
Some will say that the quality of PRs will decrease, as many the PRs that arrive and are auto-closed by the pushback bot are pretty bad. But so are many of the Gerrit CLs. I believe the Gerrit CLs are only better on average because that means it's more likely people have read the contributing instructions, or have contributed in the past. But if you only look at first-time contributors on Github PRs vs Gerrit CLs, the quality doesn't look too different. People improve over time as they learn the project and its policies.
The text was updated successfully, but these errors were encountered: