On Mar 5, 2013, at 6:39 PM, Jon Robson <jdlrob...@gmail.com> wrote: > I was wondering what the latest on this was (I can't seem to find any > recent updates in my mailing list). The MobileFrontend project was > reassured to see a github user commenting on our commits in github. > It's made me more excited about a universe where pull requests made in > github show up in gerrit and can be merged. How close to this dream > are we? >
I'm not sure to what extend we should make it "show up" in Gerrit. But there is https://bugzilla.wikimedia.org/show_bug.cgi?id=35497 Where it is explained that it is trivial to take a PR and submit it to Gerrit. Though one could write a tool to simplify it, there isn't much to simplify. Someone with access to Gerrit (anyone with a labs account) only has to: * Check it out locally. * Squash it[1] and amend with no modifications (just `git commit --amend -C HEAD`; which will trigger your git-review hook to add a Change-Id). * Push to Gerrit. If it is submitted as a pull request on GitHub, the communication with the author and revisions of the patch should be on GitHub. We only submit it to Gerrit once it is pretty much finalised. Otherwise the user is going to be unable to answer and act on the feedback. I assume the reason we are not disabling Pull requests, which is possible, is because we want this. If all we do is immediately copy the PR, submit it to Gerrit and close the PR saying "Please create a WMFLabs account, learn all of fucking Gerrit, and then continue on Gerrit to finalise the patch", then we should just kill PR now. Instead we are going to have to have some people that participate in review on GitHub. Which, fortunately, is very open and much like on Gerrit. Anyone with a GitHub account can participate in review, anyone can take it and submit it to Gerrit. The only minor detail is "closing" the PR. When that happens and who that does. The who is clear, someone with write access to the Wikimedia GitHub account. The when, could be when it is taken to Gerrit, could be when it lands in master. -- Krinkle [1] Squash because on GitHub it is common to add commits and squash later (some projects don't even squash, it depends on whether they handle a policy where every commit in the master history should be "good" - either way, we do, so when a PR gets a commit added to it that fixes a syntax error, we should squash it in the process of preparing for Gerrit). _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
