Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Tim Cross <address@hidden>
> Date: Sat, 25 Apr 2020 17:56:48 +1000
> Cc: Eric Abrahamsen <address@hidden>, Yuan Fu <address@hidden>,
>  ndame <address@hidden>, Stefan Monnier <address@hidden>,
>  Emacs developers <address@hidden>
> 
>  If this is meant as a way to implement pull requests, there is no need
>  for it.  We will not implement pull requests by copying proposed
>  patches into our repo before they are installed.
> 
> There seems to be some confusion regarding 'pull requests'.

There definitely is, but let's not exacerbate the situation by using
confusing inconsistent terminology.

> When you look at it, all a pull request is is a request to merge a
> branch from another repo into your repo.  Nothing is added to your
> repo until you perform the merge.

It should be clear that Richard is talking about 2 things:

  . the location (i.e. the hosting server) where that "other"
    repository lives
  . the process of merging the PR

> Basically, you add
> the PR repository to your LOCAL repo

How can you "add a repository to a repo"?  (And why use two different
words, "repository" and "repo", to indicate the same thing?)  Don't
you mean to say "you fork a repository", i.e. clone the repository to
produce a separate one, in another directory on the local system?

> and check it out as a branch. Do whatever you need (review, fix, etc),
> commit it to your local repository. Perhaps do some diffs against your master 
> repository and if all is good,
> merge it with your local master branch. At this point, there is still no 
> change to the 'main' master repository.
> If the merge all goes fine, you can then push the changes to your master 
> branch in your main repository. It is
> only at this point that the changes have been introduced to the main 
> repository. 
> 
> So, in short, making a PR has NO impact on the master repository until 
> someone with write permission ie.g.
> the owner, merges the PR into the master repository.

And here you use "master repository" without defining what that is,
and then use "main master repository" as if it were a different thing
(is it?).  Should we be surprised that people get confused?

I think there are 3 repositories involved in this story:

  . the upstream repository, which lives on Savannah
  . the local clone of the upstream repository on the user's machine
  . the "forked repository", which is a clone of the clone mentioned
    in the previous item; this forked repository is also local, and it
    is where the user makes the changes which will be the subject of
    the PR

So far so good?

Then we have another person in the picture, someone with write access
to the upstream repository.  That person is supposed to pull from the
"forked repository", into his or her local clone of the upstream,
which merges the PR changes, and then eventually push the results of
the merge to upstream.  At which point the PR is considered "accepted"
(or "merged"), and is visible to everyone who tracks the upstream.

Does this describe what you had in mind?

If so, as previous discussions have established, the issue that is of
concern is what server should host the "forked repository".  It
cannot be someone's private machine, because private machines don't
usually have Git servers, and thus cannot be pulled from.  Richard
also didn't want this to be Savannah, because then the forked
repository and its changes could be perceived as "endorsed" by GNU.
The practical solution is to host this on some nongnu.org server.

And now I think you can understand what Richard means when he says
"our repo".