From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Why are so many great packages not trying to get included in GNU Emacs? Date: Sun, 26 Apr 2020 16:06:49 +1000 Message-ID: References: <9mmFgzvrBwjt_n_VJyaJdXINraNi5HsGpwq-0MLeKiJA7kG2BQA4uywrzjyz7lpRS0OZDpjEi8lspOKYUA7P_QsODsDew_8nbH960G55fmY=@protonmail.com> <97DA7804-F647-4A1D-B8E0-AFFE7A324C64@gmail.com> <87d07xamrg.fsf@ericabrahamsen.net> <83lfmk7yna.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000024165d05a42b6815" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="6953"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Yuan Fu , rms@gnu.org, Eric Abrahamsen , Emacs developers , Stefan Monnier , ndame To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 26 08:08:14 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 1jSaSb-0001h0-G8 for ged-emacs-devel@m.gmane-mx.org; Sun, 26 Apr 2020 08:08:13 +0200 Original-Received: from localhost ([::1]:52984 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSaSa-00081b-Gq for ged-emacs-devel@m.gmane-mx.org; Sun, 26 Apr 2020 02:08:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32920) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSaS0-0007Jp-2D for emacs-devel@gnu.org; Sun, 26 Apr 2020 02:07:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSaRy-0004yp-Tr for emacs-devel@gnu.org; Sun, 26 Apr 2020 02:07:35 -0400 Original-Received: from mail-ot1-x32c.google.com ([2607:f8b0:4864:20::32c]:33997) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jSaRU-0004Eo-0R; Sun, 26 Apr 2020 02:07:04 -0400 Original-Received: by mail-ot1-x32c.google.com with SMTP id 72so20430228otu.1; Sat, 25 Apr 2020 23:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eJpZVzGGSdXjvMOF9BTGVN+FXGiUg66rL4/mKR9lK9g=; b=b9/HJYzbCw1uKD1s05MApbhg7Vb5Nx0FpvMEac0m0hsDQHdi994MLSC6NibPraSCEf bw7PNyA5ovgsgXCVqyhcrus7alIzp6GaNp4B8r/rFKGtFSJL9iiFR1EHXAcjtpudE8sa PVL9O/z9t8GJHn88EhD9z/30RlKmnzYlQpHzgl468cWFje+qJayTL5/EIYc1UDeRWB8C EwdIgPJ+u2pHTpNQcGcp/FfrdBJMGrrjYffDVbbSIJXlSLfkU3X5jogVMCdu4RvrDu+b i4F/QFrwmkDQnc/lA9ph4BCJrrhv+NNbwXOX/S0aTXjfeJu8UQQRxufnj2M5xnb1lIAC l9wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eJpZVzGGSdXjvMOF9BTGVN+FXGiUg66rL4/mKR9lK9g=; b=e6Y2ZMIAeSNtWZFXG0JWiU1rq5XRi6n2O0sUjYJhc7ZRG6vhzVqmfDqsTraS47sgXv Qp7z+ew1K+XXfur7iNH7J9HURbppZvEwtqGiDc0VdU4i9ljQASnmpuRLsBYYpbjzt53f zCavdVQD2HGzu4SXYU/N797GYDg01vY5h4wwEO68tFzwnVJ1qUiAYI6pX67lWcaRDAVW rMC31yV7VKknROAcyymzEETum6fO3dDn/Cs18grLz6vyXB6BUAKiUhF9N7pdchu8ZVEE o9Gmx7strz7km1+5H4cWKaNcKp5vHoXTH8WuRRToBGR7rVxH+WAceniF4AKHXSVPt6+I tR8g== X-Gm-Message-State: AGi0PuZUA9tn/tErwZV+uF43yjYkv0sQfGoOSq+TsVwX2qVafyivllAp YCmYeneqZWPGOu3m8ssl+WNLqsK4HDrqWt7zUvEpJu2o X-Google-Smtp-Source: APiQypK12XWmzctr9dhPbru3NU+ScJSyO2TZgmnsTfEBbw2HMy65FFVmSBGjX2T0Rha5VgK6PlRLK2rEOpJxdgd1k5k= X-Received: by 2002:a9d:5f18:: with SMTP id f24mr14312988oti.325.1587881221296; Sat, 25 Apr 2020 23:07:01 -0700 (PDT) In-Reply-To: <83lfmk7yna.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::32c; envelope-from=theophilusx@gmail.com; helo=mail-ot1-x32c.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2607:f8b0:4864:20::32c 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:247823 Archived-At: --00000000000024165d05a42b6815 Content-Type: text/plain; charset="UTF-8" On Sat, 25 Apr 2020 at 18:33, Eli Zaretskii wrote: > > From: Tim Cross > > Date: Sat, 25 Apr 2020 17:56:48 +1000 > > Cc: Eric Abrahamsen , Yuan Fu < > casouri@gmail.com>, > > 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 > > No, it is not clear. What I got from a number of Richard's posts was the concern that a PR would appear to be part of the GNU Emacs distribution or in some way mistaken as being 'official' or agreed to. What I was trying to make clear is that the PR has NO impact on the repository in itself. It is only after someone takes that pull request and merges it into the repository that it becomes part of the repository. A PR in itself is just a request to merge changes. It is effectively no different from sending an email with a patch in it except it is more public (or at least can be). As the PR is hosted in a completely separate repository, there is no chance it can be confused or seen as being part of the official repository. > > 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?) repo is shorthand for repository. It is a term in common usage and I think pretty obvious. > 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? > > Definitely not! You do not need to clone the PR repository. You can add the PR repository to your local clone as another upstream source. This is part of what makes PRs so easy to work with. Once you have aded the PR repository to your clone, you can checkout a branch from that repo in your clone. From this point, merging is just normal merging of branches in your clone. Nothing is seen in the upstream repo until you do a push. > 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? > > Fair enough. I will try to clarify and define the terms to make it clearer. > 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? > No, not quite. We do have 3 repositories, but not quite as you have defined them. 1. The upstream repository which lives on Savannah. Let's call this the master repository. 2. Local clone of master repository used by a maintainer. Call this one the maintenance repository 3. A developers fork of the master repository. This can be anywhere, but needs a public interface, like https (i.e. github, gitlab, bitbucket etc). Call this the developers repository. There is not much difference between a fork and a clone. A fork typically refers to a clone of a repository which itself is made available for further cloning/forking on a server somewhere. Changes can be made on the forked clone, but typically the changes cannot be pushed upstream to the master repository the forked repository was cloned from. The 3rd repository above needs to be a fork because it needs to be public and available to perform a merge following a pull request. A maintainer is someone who has write access to the master repository A developer is someone who would like to contribute code. They have read access (can clone) from the master repository, but do not have write access. The PR consists of two workflows, the developers workflow and the maintainers workflow. The developers workflow is roughly 1. Fork the master repository to some location, creating the developer repository. 2. Clone the developer repository so that the developer now has a local repository to work on 3. Make changes and when complete, push to the developers repository. Often, the changes will be in a feature branch. It would also be normal practice for the developer to make sure their forked copy is up-to-date and their changes in their feature branch have been merged with the current state of the upstream code i.e. pull from upstream, merge master with feature branch. 4. Make the PR. How this is done would depend on what interfaces are available, but could be as simple as an email to the maintainer which requests that the maintainer pull their changes from their developer repository and merge them into the master repository. The email would need to include the URL for the developer repository and include any branch information if required i.e. the changes might be in a feature branch within the developer repoository. The maintainer workflow could be something like 1. Maintainer receives the PR from the developer (how depends on what interfaces are available, but might just be an email). 2. Maintainer adds the developers repository as another upstream source to their LOCAL maintenance repository. 3. Maintainer checks out the developers PR branch as a local branch in their working directory 4. Maintainer does whatever reviews, cleanup, adjustments etc they think are necessary and commits the branch. This only commits to their local maintenance repository. 5. Maintainer does any other check, such as verifying copyright or whatever 6. Maintainer now checks out master branch of maintenance repository (possibly after doing a pull from upstream master repository to ensure latest code base). 7. Maintainer then merges local PR branch into master branch 8 Maintainer runs tests and verifies merge is good and if happy commits the master to local maintenance repository with appropriate commit message. At this point, the PR is only in the local maintenance repository. There has not yet been any changes made to the master repository, so nobody can see these changes. 9. Maintainer pushes the local master branch to the upstream master repository The maintainer may then choose to do some cleanup work, like removing the PR branch and PR upsream source from their local maintenance repository (or they can leave them, they don't use much space and you may get further PRs from that developer etc). 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. > > I don't think we need to care. Provided the person making the PR is able to provide a public interface to their repository, it doesn't matter where it is hosted. Once the PR is complete, the code is part of the master repository and the forked developer repository is irrelevant. -- regards, Tim -- Tim Cross --00000000000024165d05a42b6815 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, 25 Apr 2020 at 18:33, Eli Zar= etskii <eliz@gnu.org> wrote:
<= /div>
> From: Tim Cross= <theophilusx= @gmail.com>
> Date: Sat, 25 Apr 2020 17:56:48 +1000
> Cc: Eric Abrahamsen <eric@ericabrahamsen.net>, Yuan Fu <casouri@gmail.com>,
>=C2=A0 ndame <ndame@protonmail.com>, Stefan Monnier <monnier@iro.umontreal.ca>, >=C2=A0 Emacs developers <emacs-devel@gnu.org>
>
>=C2=A0 If this is meant as a way to implement pull requests, there is n= o need
>=C2=A0 for it.=C2=A0 We will not implement pull requests by copying pro= posed
>=C2=A0 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.=C2=A0 Nothing is added to you= r
> repo until you perform the merge.

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

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


No, it is not clear. What I got from a= number of Richard's posts was the concern that a PR would appear to be= part of the GNU Emacs distribution or in some way mistaken as being 'o= fficial' or agreed to. What I was trying to make clear is that the PR h= as NO impact on the repository in itself. It is only after someone takes th= at pull request and merges it into the repository that it becomes part of t= he repository. A PR in itself is just a request to merge changes. It is eff= ectively no different from sending an email with a patch in it except it is= more public (or at least can be). As the PR is hosted in a completely sepa= rate repository, there is no chance it can be confused or seen as being par= t of the official repository.
=C2=A0
> Basically, you add
> the PR repository to your LOCAL repo

How can you "add a repository to a repo"?=C2=A0 (And why use two = different
words, "repository" and "repo", to indicate the same th= ing?)=C2=A0

repo is shorthand for repositor= y. It is a term in common usage and I think pretty obvious.
= =C2=A0
Don't you mean to say "you fork a repository", i.e. clone the repositor= y to
produce a separate one, in another directory on the local system?


Definitely not! You do not need to clone the PR r= epository. You can add the PR repository to your local clone as another ups= tream source. This is part of what makes PRs so easy to work with. Once you= have aded the PR repository to your clone, you can checkout a branch from = that repo in your clone. From this point, merging is just normal merging of= branches in your clone. Nothing is seen in the upstream repo until you do = a push.


> 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 mast= er branch in your main repository. It is
> only at this point that the changes have been introduced to the main r= epository.
>
> 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 i= s,
and then use "main master repository" as if it were a different t= hing
(is it?).=C2=A0 Should we be surprised that people get confused?


Fair enough. I will try to clarify and= define the terms to make it clearer.
=C2=A0
I think there are 3 repositories involved in this story:

=C2=A0 . the upstream repository, which lives on Savannah
=C2=A0 . the local clone of the upstream repository on the user's machi= ne
=C2=A0 . the "forked repository", which is a clone of the clone m= entioned
=C2=A0 =C2=A0 in the previous item; this forked repository is also local, a= nd it
=C2=A0 =C2=A0 is where the user makes the changes which will be the subject= of
=C2=A0 =C2=A0 the PR

So far so good?

No, not quite. We do ha= ve 3 repositories, but not quite as you have defined them.

1. The upstream repository which lives on Savannah. Let's call= this the master repository.
2. Local clone of master repository = used by a maintainer. Call this one the maintenance repository
3.= A developers fork of the master repository. This can be anywhere, but need= s a public interface, like https (i.e. github, gitlab, bitbucket etc). Call= this the developers repository.

There is not= much difference between a fork and a clone. A fork typically refers to a c= lone of a repository which itself is made available for further cloning/for= king on a server somewhere. Changes can be made on the forked clone, but ty= pically the changes cannot be pushed upstream to the master repository the = forked repository was cloned from. The 3rd repository above needs to be a f= ork because it needs to be public and available to perform a merge followin= g a pull request.

A maintainer is someone who= has write access to the master repository
A developer is someone= who would like to contribute code. They have read access (can clone) from = the master repository, but do not have write access.

The PR consists of two workflows, the developers workflow and the ma= intainers workflow.

The developers workflow i= s roughly

1. Fork the master repository to so= me location, creating the developer repository.
2. Clone the= developer repository so that the developer now has a local repository to w= ork on
3. Make changes and when complete, push to the developers = repository. Often, the changes will be in a feature branch. It would also b= e normal practice for the developer to make sure their forked copy is up-to= -date and their changes in their feature branch have been merged with the c= urrent state of the upstream code i.e. pull from upstream, merge master wit= h feature branch.
4. Make the PR. How this is done would depe= nd on what interfaces are available, but could be as simple as an email to = the maintainer which requests that the maintainer pull their changes from t= heir developer repository and merge them into the master repository. The em= ail would need to include the URL for the developer repository and include = any branch information if required i.e. the changes might be in a feature b= ranch within the developer repoository.

=C2= =A0The maintainer workflow could be something like

1. Maintainer receives the PR from the developer (how depends on what inte= rfaces are available, but might just be an email).
2. Maintainer = adds the developers repository as another upstream source to their LOCAL ma= intenance repository.
3. Maintainer checks out the developer= s PR branch as a local branch in their working directory
4. Maint= ainer does whatever reviews, cleanup, adjustments etc they think are necess= ary and commits the branch. This only commits to their local maintenance re= pository.
5. Maintainer does any other check, such as verify= ing copyright or whatever
6. Maintainer now checks out master bra= nch of maintenance repository (possibly after doing a pull from upstream ma= ster repository to ensure latest code base).
7. Maintainer then m= erges local PR branch into master branch
8 Maintainer runs tests = and verifies merge is good and if happy commits the master to local mainten= ance repository with appropriate commit message.

<= div>At this point, the PR is only in the local maintenance repository. Ther= e has not yet been any changes made to the master repository, so nobody can= see these changes.

9. Maintainer pushes the = local master branch to the upstream master repository

<= div>The maintainer may then choose to do some cleanup work, like removing t= he PR branch and PR upsream source from their local maintenance repository = (or they can leave them, they don't use much space and you may get furt= her PRs from that developer etc).


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


I don't think we nee= d to care. Provided the person making the PR is able to provide a public in= terface to their repository, it doesn't matter where it is hosted. Once= the PR is complete, the code is part of the master repository and the fork= ed developer repository is irrelevant.
=C2=A0
--
re= gards,

Tim

--
Tim Cr= oss

--00000000000024165d05a42b6815--