Re: Current status of the GNOME Github mirror

[Emmanuele Bassi <ebassi gmail com>]

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 <hadess hadess net> 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]