Re: pull requests

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Richard,

Sorry for the late reply. I'll try to make a good description.

On 02.04.2020 05:39, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
> I have never seen what a pull request is like to use.  I do not use
> the systems which support them.  In trying to think about their
> implications, I have to go by the descriptions people have sent me
> in this discussion.
> 
> Unfortunately, the descriptions I've reaceived seen to conflict.
> Perhaps people were describing different ways that different projects
> or different platforms handle pull requests, but I did not know that
> when I read them.

AFAIK, there are basically two different things that are called a "pull 
request".

The first is basically an email with details about the repository and 
the branch you want code "pulled" from. There are more details here: 
https://www.kernel.org/doc/html/latest/maintainer/pull-requests.html, 
but this is largely irrelevant to this discussion because a) we can do 
this already (and don't need any help with that), b) our developers and 
contributors don't use this approach. So it's not what we've been 
discussing.

The second one (which is what we're considering) has been popularized by 
the proprietary code forge called GitHub. In there, users can make 
'forks' of the original repository, where a fork is basically a copy of 
the original repository that belongs to the user's account (and its URL 
has the user's username in it). The said user can create a new branch, 
push some changesets into it, and then propose the said branch to the 
original repository and its developers for merging. By creating a "pull 
request".

It's a "thing": Github, as well as similar forges such as Gitlab, have a 
dedicated type of issue (*) that's called a "pull request". It has all 
the features of an "issue" (which generally means people can leave 
comments in it), as well as extra features: it shows the author, the 
source branch, a multi-line description that the author usually has to 
fill, the proposed commits, it can show the combined diff of those 
commits, users can leave comments associated with individual lines of 
that diff (and the UI displays that neatly), they can lead threaded 
discussions on said commits (which get semi-hidden as soon as the 
related code has changed), and the PR tracks the source branch closely, 
so as soon as the user pushes some new changes to the branch, the 
information in the PR updates automatically. The PR web page can show 
the status of the CI build for the proposed branch. The main 
repository's maintainers can merge the PR with just a couple of clicks 
with the mouse (this works best with small contributions). There are 
other features.

Overall, a lot of developers are used to this workflow and would never 
choose patch submission over email. Of course, not everybody. Some 
people just don't like web interfaces, for example.

(*) Issues are basically bug reports, but people can use them for 
discussions, support questions, and so on.