From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Why are so many great packages not trying to get included in GNU Emacs? Date: Sat, 25 Apr 2020 11:33:29 +0300 Message-ID: <83lfmk7yna.fsf@gnu.org> References: <9mmFgzvrBwjt_n_VJyaJdXINraNi5HsGpwq-0MLeKiJA7kG2BQA4uywrzjyz7lpRS0OZDpjEi8lspOKYUA7P_QsODsDew_8nbH960G55fmY=@protonmail.com> <97DA7804-F647-4A1D-B8E0-AFFE7A324C64@gmail.com> <87d07xamrg.fsf@ericabrahamsen.net> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="128945"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, rms@gnu.org, eric@ericabrahamsen.net, emacs-devel@gnu.org, monnier@iro.umontreal.ca, ndame@protonmail.com To: Tim Cross Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 25 10:34:26 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jSGGY-000XSJ-50 for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Apr 2020 10:34:26 +0200 Original-Received: from localhost ([::1]:60850 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSGGX-00006j-4L for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Apr 2020 04:34:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48832) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSGFy-0007sh-8N for emacs-devel@gnu.org; Sat, 25 Apr 2020 04:33:50 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50454) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSGFx-0007so-Gf; Sat, 25 Apr 2020 04:33:49 -0400 Original-Received: from [176.228.60.248] (port=3106 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jSGFq-0008NT-B6; Sat, 25 Apr 2020 04:33:42 -0400 In-Reply-To: (message from Tim Cross on Sat, 25 Apr 2020 17:56:48 +1000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:247758 Archived-At: > From: Tim Cross > Date: Sat, 25 Apr 2020 17:56:48 +1000 > Cc: Eric Abrahamsen , Yuan Fu , > ndame , Stefan Monnier , > Emacs developers > > 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".