GitHub pull requests

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

GitHub pull requests

Julian Foad-5
Here's a thread for discussing the github (GH) pull-request (PR) method of contributing.

My views, briefly, include:

* I don't want open source projects to support GitHub; there is at least one good open source alternative, GitLab. So I don't want us to keep the existing GH semi-integration as-is, for that reason at least. I don't see a real need to have any level of presence on GitHub beyond probably a place-holder that points to our preferred options.

* When the facility to contribute in this way (PRs) is available, it is because We, the ASF community, have made it so, and we can turn it off if we don't like it. It would be very rude of us to criticize contributors for using a route that we have made available. (The same applies to writing to the mailing list from google groups, for example.)

* I think drive-by contributions can be a valuable route for new contributors to get started. I do acknowledge that they sometimes require a level of hand-holding that can be tedious compared with contributions from more "seasoned" contributors. I think that's OK for our community. Nobody has to do any more than ensure a brief, polite response is given.

* I think the PR style of contribution is useful.

* I would love to help figure out how we could make a PR style of contribution work well, perhaps using GitLab, certainly with better integration than the existing GH semi-integration.

--
- Julian
Reply | Threaded
Open this post in threaded view
|

Re: GitHub pull requests

Branko Čibej
On 24.01.2019 12:29, Julian Foad wrote:
> Here's a thread for discussing the github (GH) pull-request (PR) method of contributing.
>
> My views, briefly, include:
>
> * I don't want open source projects to support GitHub; there is at least one good open source alternative, GitLab. So I don't want us to keep the existing GH semi-integration as-is, for that reason at least. I don't see a real need to have any level of presence on GitHub beyond probably a place-holder that points to our preferred options.


Hmph. I don't want open-source projects to "support" git, and I suppose
my wish is just as likely to happen as yours.


> * When the facility to contribute in this way (PRs) is available, it is because We, the ASF community, have made it so, and we can turn it off if we don't like it.


This point is far too general for this list. members@ might be the right
forum, but there are many, many people at the ASF that believe GitHub is
the whole world (seems to go in hand with the "git == version control"
and "GitHub == git" viewpoints).


On the other hand, we can request that Infra removes *our* GitHub
mirror, just as we requested in the past that it creates one. I'd rather
see the ability to submit pull requests disabled for that mirror, though.


>  It would be very rude of us to criticize contributors for using a route that we have made available. (The same applies to writing to the mailing list from google groups, for example.)
>
> * I think drive-by contributions can be a valuable route for new contributors to get started. I do acknowledge that they sometimes require a level of hand-holding that can be tedious compared with contributions from more "seasoned" contributors. I think that's OK for our community. Nobody has to do any more than ensure a brief, polite response is given.
>
> * I think the PR style of contribution is useful.


I think it is not. This style seems to be designed specifically so that
contributors have to interact with the community as *little* as
possible. It's completely at odds with how we do things here. The
example that prompted the creation of  this thread illustrates this
quite well.


> * I would love to help figure out how we could make a PR style of contribution work well, perhaps using GitLab, certainly with better integration than the existing GH semi-integration.

Surely you mean non-integration. :)

-- Brane
Reply | Threaded
Open this post in threaded view
|

Re: GitHub pull requests

Julian Foad-5
Branko Čibej wrote:
> Julian Foad wrote:
> > * When the facility to contribute in this way (PRs) is available, it is because We, the ASF community, have made it so, and we can turn it off if we don't like it.
>
> [...] we can request that Infra removes *our* GitHub
> mirror, just as we requested in the past that it creates one.

Exactly: our project gets to say what goes for our project.

> I'd rather
> see the ability to submit pull requests disabled for that mirror, though.

Me too. GH, as a closed system, intentionally limits what we can do with it. I'm pretty sure I asked in the past to turn off PRs and was told that's not possible. I'm pretty sure with GitLab we could turn off PRs.

> > * I think the PR style of contribution is useful.
>
> I think it is not. This style seems to be designed specifically so that
> contributors have to interact with the community as *little* as
> possible. [...]

That is certainly the effect we get from GitHub's PRs and the ASF non-integration, but it's not necessarily true of the PR concept in general.

--
- Julian
Reply | Threaded
Open this post in threaded view
|

Re: GitHub pull requests

Julian Foad-5
I posted "Use GitLab, not GitHub" to ASF ComDev [1], somewhat related to this thread.

[1] https://lists.apache.org/thread.html/a3e63ac787dd9413bb283df01645bfe50b683b0044a97df1f3650d37@%3Cdev.community.apache.org%3E
[2] A variant on my blog: https://blog.foad.me.uk/2018/11/28/use-gitlab-not-github/

--
- Julian
Reply | Threaded
Open this post in threaded view
|

Re: GitHub pull requests

Julian Foad-5
In reply to this post by Julian Foad-5
We don't handle GitHub pull requests well. Should we change something?

The issue:

- there is a "mirror" of svn source code on GitHub [1]
- that makes it look like people could submit pull-requests
- a (very) few people have tried to do so [2]
- it isn't integrated with our project work flow
- svn committers don't even have basic permissions to manage
   PRs, such as closing a PR
- those potential contributors get a very poor response
   (PRs left unacknowledged or abandoned in "open" state)

Some potential options:

* turn off the github "mirror" of svn entirely
   - replace it with a dummy project that just says where to find us

* try to persuade ASF infra and GitHub to turn off the PRs UI
   - previously said to be not possible

* move svn source from svn to git (ASF gitbox) hosting
   - then a github 2-way integration will be available

My thoughts:

The poor experience is not much of a real problem at the moment because
the number of interactions is so tiny (10 in 7 years), but it gives a
bad impression and I prefer to avoid ugliness like this. Moving to git
would probably be pragmatic in objective terms, but of course terribly
emotive so might cause more upset and ridicule than it's worth. Turning
off PRs might be best, so might be worth asking again if it's possible.

Your thoughts?


[1] https://github.com/apache/subversion
[2] https://github.com/apache/subversion/pulls?q=is%3Apr

Julian Foad wrote:


> Branko Čibej wrote:
>> Julian Foad wrote:
>>> * When the facility to contribute in this way (PRs) is available, it is because We, the ASF community, have made it so, and we can turn it off if we don't like it.
>>
>> [...] we can request that Infra removes *our* GitHub
>> mirror, just as we requested in the past that it creates one.
>
> Exactly: our project gets to say what goes for our project.
>
>> I'd rather
>> see the ability to submit pull requests disabled for that mirror, though.
>
> Me too. GH, as a closed system, intentionally limits what we can do with it. I'm pretty sure I asked in the past to turn off PRs and was told that's not possible. I'm pretty sure with GitLab we could turn off PRs.
>
>>> * I think the PR style of contribution is useful.
>>
>> I think it is not. This style seems to be designed specifically so that
>> contributors have to interact with the community as *little* as
>> possible. [...]
>
> That is certainly the effect we get from GitHub's PRs and the ASF non-integration, but it's not necessarily true of the PR concept in general.

Reply | Threaded
Open this post in threaded view
|

Re: GitHub pull requests

Paul Hammant-3
One of the major GitHub social contributions to the community is the
ease of forking. I don't mean as part of a "contribution workflow",
but as a tool for getting an upstream team to change their attitude. A
famous case was Node.js and how it ended well (merged again -
http://anandmanisankar.com/posts/nodejs-iojs-why-the-fork/) but was a
smack of sorts for the maintaining company. There are others, too. I'm
talking folks that elicit changes in maintainer policy.

Generally, any viable F/OSS thing is going to end up on GitHub if it
fits (Git has size limits; GitHub have a page on limits -
https://help.github.com/en/articles/what-is-my-disk-quota). It is
going to exist there with Pull-Requests and Issues enabled by some
group.

If a team that "owns" a compelling F/OSS thing on GitHub and attempt
to not have Pull-Requests or GH issues - the thing effectively gets
taken away from them in a fork, that has that turned on. Sure, they
may insist the other "team" doesn't use their trademarks, but they
used and OSI approved license so that's all they can do.

The only defense against that is to NOT have a compelling viable project.

Well that's not absolutely true - https://github.com/mackyle/sqlite is
a fork of something that's canonical on Fossil but
https://github.com/mackyle/sqlite/network shows there's no
maintained-divergence on GH. SqLite is super viable as a project
though - things are happening to it at enough of a pace (2 or 3
commits a day) to make you overcome objections to contribute at the
source in Fossil if you want to get something into upstream. Maybe
after you tried to build it from a git-clone (assuming up to date) and
prove your patch there. However if D Richard Hipp went on a 6mo
vacation, Sqlite would have relocated to GitHub without him.

Forks are going to happen on GitHub regardless with PRs enabled. You
might as well embrace that, and play ball by leaving PRs enabled for
your repo too. Subversion's not in a shameful place if its source is
in Git. Instead it is boosted, IMO.  Time was when your wire protocol
(at least WebDAV) was lingua franca. Now it's Gits: Perforce,
PlasticSCM and Mercurial all speak Git.

- Paul
Reply | Threaded
Open this post in threaded view
|

Re: GitHub pull requests

Branko Čibej
In reply to this post by Julian Foad-5
On 19.06.2019 11:47, Julian Foad wrote:

> We don't handle GitHub pull requests well. Should we change something?
>
> The issue:
>
> - there is a "mirror" of svn source code on GitHub [1]
> - that makes it look like people could submit pull-requests
> - a (very) few people have tried to do so [2]
> - it isn't integrated with our project work flow
> - svn committers don't even have basic permissions to manage
>   PRs, such as closing a PR
> - those potential contributors get a very poor response
>   (PRs left unacknowledged or abandoned in "open" state)
>
> Some potential options:
>
> * turn off the github "mirror" of svn entirely
>   - replace it with a dummy project that just says where to find us
>
> * try to persuade ASF infra and GitHub to turn off the PRs UI
>   - previously said to be not possible
>
> * move svn source from svn to git (ASF gitbox) hosting
>   - then a github 2-way integration will be available
>
> My thoughts:
>
> The poor experience is not much of a real problem at the moment
> because the number of interactions is so tiny (10 in 7 years), but it
> gives a bad impression and I prefer to avoid ugliness like this.
> Moving to git would probably be pragmatic in objective terms, but of
> course terribly emotive so might cause more upset and ridicule than
> it's worth. Turning off PRs might be best, so might be worth asking
> again if it's possible.


Moving the source to git would be less than ideal in terms of eating our
own dogfood. It would also be a terrible move from the "marketing"
perspective.

As for handling pull requests: we do receive e-mails for those, IIRC,
although they seem to be fairly trivial. I would suggest (to Infra) to
slightly improve the integration in two ways:

  * include the patch (as an attachment?) in the PR mails
  * post the mail thread replies back to the PR thread on GitHub

I think such integration would be useful for more than just Subversion,
and in our case, it would make dealing with a GitHub PR more or less
transparent to our normal patch submission process.


-- Brane
Reply | Threaded
Open this post in threaded view
|

Re: GitHub pull requests

Branko Čibej
In reply to this post by Paul Hammant-3
On 19.06.2019 18:59, Paul Hammant wrote:
> Time was when your wire protocol
> (at least WebDAV) was lingua franca. Now it's Gits: Perforce,
> PlasticSCM and Mercurial all speak Git.

Apropos of that, reviving and finishing up the ra_git branch would be
one of the more useful projects.

-- Brane

Reply | Threaded
Open this post in threaded view
|

Re: GitHub pull requests

Nathan Hartman
In reply to this post by Branko Čibej
On Thu, Jun 20, 2019 at 3:27 AM Branko Čibej <[hidden email]> wrote:
Moving the source to git would be less than ideal in terms of eating our
own dogfood. It would also be a terrible move from the "marketing"
perspective.

I agree with that. There is a lot to be said for "dogfooding." Keeping the project in svn with better GitHub integration would be a win. Also it would be a demonstration that Subversion can do that, particularly for those who need Subversion's features but would like to benefit from that possibility.

Reply | Threaded
Open this post in threaded view
|

Re: GitHub pull requests

Paul Hammant-3
In reply to this post by Branko Čibej
>   * include the patch (as an attachment?) in the PR mails

https://coderwall.com/p/6aw72a/creating-patch-from-github-pull-request
<- turns out GitHub has a secret URL that aids in that workflow.

Remaining: a pledge for speedy processing of these.  If standards for
code donations are made clear, and CLA obligations streamlined, then
you have a possible way forward. If an item starts in GH-PR though,
does it get entered into Jira too?  I would leave it there, and
complete (prosefully at least) the workflow there - 1) code-review
commentary in GH, 2) conclusion statement with a reminder that the
changes in question will reappear in GitHub later aftr a sync from
upstream Svn@theASF, 3) close of PR.
Reply | Threaded
Open this post in threaded view
|

Re: GitHub pull requests

Paul Hammant-3
In reply to this post by Nathan Hartman
The gaping hole in Subversion's capability, 11 years on from when
GitHub launched with it, and 13 or so years from Google
operational-izing the functional equivalent for themselves is
patch-review in a way that each is re-creatable in working-copy by
reviewers from the command line.  GitHub made this as a Pull-Requests
from forks that are essentially short lived feature branches.  They
later talked of "GitHub Flow" (not to be confused with GitFlow) as a
branching model.  Perforce couldn't do SLFBs so Google implemented it
as a patch management and review system that was effectively the same.
The UI was called Mondrian (Guido tech-talked about that himself in
2006). Opensource-land received Rietveld and the Gerrit in the image
of Mondrian, and indeed Subversion was supported at the outset.

This needs to be built in to Subversion IMO, and an extension of
Julian's shelve tech. No web-ui, just sve.ee compatibility.

I'm saying this because dogfooding requires minimal comparable features.

-ph
Reply | Threaded
Open this post in threaded view
|

Re: GitHub pull requests

Branko Čibej
In reply to this post by Paul Hammant-3
On 20.06.2019 16:47, Paul Hammant wrote:

>>   * include the patch (as an attachment?) in the PR mails
> https://coderwall.com/p/6aw72a/creating-patch-from-github-pull-request
> <- turns out GitHub has a secret URL that aids in that workflow.
>
> Remaining: a pledge for speedy processing of these.  If standards for
> code donations are made clear, and CLA obligations streamlined, then
> you have a possible way forward. If an item starts in GH-PR though,
> does it get entered into Jira too?  I would leave it there, and
> complete (prosefully at least) the workflow there - 1) code-review
> commentary in GH, 2) conclusion statement with a reminder that the
> changes in question will reappear in GitHub later aftr a sync from
> upstream Svn@theASF, 3) close of PR.

We usually *don't* use Jira for tracking patches.

-- Brane