Hi; as much as I agree with Bastien on the subject of pull requests (and I have to use them at work every day), you can avoid the pesky merge button:
https://news.ycombinator.com/item?id=9051220 """ GitHub provides a special pulls remote "namespace" on the upstream repo, so you can add it as a fetch pattern to your .git/config like so: [remote "upstream"] url = https://github.com/neovim/neovim.git fetch = +refs/heads/*:refs/remotes/upstream/* fetch = +refs/pull/*/head:refs/pull/upstream/* Then when you `git fetch --all`, you will have ALL pull requests available in your local repo in the local pull/ namespace. To check out PR #42: git checkout -b foo refs/pull/upstream/42 """ This, at least, allows you to edit the PR and rebase it locally before merging it with a fast forward. The rest of the objections stay the same: * the code review process is dire and generates far too much notification noise * it's completely overkill for simple patches Having said that, there's one occasion where a pull request beats Bugzilla: large patch-sets. For those we don't have a good story — and Bugzilla, even with git-bz, is probably the worst option. At least, the pull request (by virtue of being branch based) allows you to rebase, thus you can keep it reasonably linear after each round of review. On 6 May 2015 at 09:29, Bastien Nocera <[email protected]> wrote: >> Apparently we don't have a simple solution we could apply to solve >> the >> problem all together > > Allowing the upstream maintainers to close those Pull Requests would > be a good start. Indeed. Getting notifications of open pull requests to the maintainers listed in the DOAP file would also be good, so each maintainer can decide whether or not to integrate one or just direct. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
