Re: [PATCH v1] Configure Git contribution guidelines for github.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 12, 2017 at 5:52 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> "Philip Oakley" <philipoakley@xxxxxxx> writes:
>
>> From: "Lars Schneider" <larsxschneider@xxxxxxxxx>
>>> Many open source projects use github.com for their contribution process.
>>> Although we mirror the Git core repository to github.com [1] we do not
>>> use any other github.com service. This is unknown/unexpected to a
>>> number of (potential) contributors and consequently they create Pull
>>> Requests against our mirror with their contributions. These Pull
>>> Requests become stall [2]. This is frustrating to them as they think we
>>> ignore them and it is also unsatisfactory for us as we miss potential
>>> code improvements and/or new contributors.
>>>
>>> GitHub offers a way to notify Pull Request contributors about the
>>> contribution guidelines for a project [3]. Let's make use of this!
>>>
>>> [1] https://github.com/git/git
>>> [2] https://github.com/git/git/pulls
>>> [3]
>>> https://help.github.com/articles/creating-a-pull-request-template-for-your-repository/
>>>
>>> Signed-off-by: Lars Schneider <larsxschneider@xxxxxxxxx>
>>> ---

[The latest patch in this thread looks good to me to, thanks Lars]

>> I see there are currently 84 open PRs (13 in the last 14 days), so it
>> is real.
>
> Not so insignificant fraction of these are done purely for the
> purpose of using submitgit, though.  In other words, if submitgit
> were improved not to require a pull request against [1] (instead, it
> could be pointed at a branch in a contributor's repository and do
> the fromatting), these numbers will go down.

There are things we get out of this that would regress if
submitGit were changed this way:

 * Now when you submit a pull request you get a Travis build for
git/git, I don't get this if I push to any random branch in my
avar/git, and although I could probably set it up, it's extra work
etc.

 * I like being able to "git fetch" patches I'm reviewing. Now I can
just set "+refs/pull/*:refs/remotes/origin/pull/*" in the refspec for
git/git, if it were pulling from target repos I'd need to "git remote
add" for each one, not a big deal, but less convenient.

 * There would be no single place to list submitGit requests, which
you can do now through the pull page, although I think this is largely
stale now because nothing auto-closes them if they're merged (by which
point they'll have different sha1s), but that could be improved with
some bot...

There's probably ways to do this without git/git pull requests, but I
don't see what problem would be solved by moving this off git/git,
even if there's open requests submitGit is the only thing using these,
and any confusion about that pull UI would remain if it wasn't (AFAIK
there's no way to completely disable pull requests on github, but I
may be wrong).



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]