GitHub pull requests

[Tuncer Ayaz]

On Sun, Oct 5, 2014 at 12:56 PM, Joachim Breitner wrote:
> Hi,
>
> we already have the problem with some people submitting diffs on
> trac, other submitting git patches on trac or linking to their
> private fork somewhere to pull from, and others using Phabricator.
> And, at least as far as I can tell from here, it doesn’t seem to be
> a big deal.
>
> So (warning: surprisingly simple solution ahead) we could consider
> the option of simply accepting Github pull requests!
>
> I think it could work well ok if we either
>  * somehow communicate that people should open a trac ticket as
>    well, if they want to make sure their contribution is handled in
>    a timely manner, or (or and)
>  * someone of us looks after PR and creates trac tickets as needed.
>
> The advantage is clear: Low entry barrier for new contributors and,
> as Michael says, for very small contributions (documentation typo
> fixes or so).
>
> The downside is that we have more tools to work with. This either
> means that we all get to know the GitHub frontend (which is quite
> intuitive, and at least reading diffs and commenting should be
> possible for all without a lot of learning), or that we simply let
> those developers who are familiar with GitHub handle it.
>
> I think the advantage could outweigh the downside and it’s worth a
> try. We don’t even have to advocate it aggressively, just remove the
> „Do not submit PRs“ notice on the repo and see what happens.
>
> (The problem with the ticket numbers remain, unfortunately.)

There's also the problem that Github's review system is not as
powerful and most importantly does not preserve history like Gerrit or
Phabricator do. Once used to it, maintainers probably won't be happy
to lose productivity due to the simplistic review system.