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: Sat, 25 Apr 2020 17:56:48 +1000 Message-ID: References: <9mmFgzvrBwjt_n_VJyaJdXINraNi5HsGpwq-0MLeKiJA7kG2BQA4uywrzjyz7lpRS0OZDpjEi8lspOKYUA7P_QsODsDew_8nbH960G55fmY=@protonmail.com> <97DA7804-F647-4A1D-B8E0-AFFE7A324C64@gmail.com> <87d07xamrg.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a3766505a418d347" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="114728"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eric Abrahamsen , Yuan Fu , ndame , Stefan Monnier , Emacs developers To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 25 09:57:47 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 1jSFh4-000TXi-SL for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Apr 2020 09:57:46 +0200 Original-Received: from localhost ([::1]:60278 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSFh3-0004j7-SF for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Apr 2020 03:57:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43740) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSFgP-00040z-FY for emacs-devel@gnu.org; Sat, 25 Apr 2020 03:57:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSFgO-0004wb-Tm for emacs-devel@gnu.org; Sat, 25 Apr 2020 03:57:05 -0400 Original-Received: from mail-ot1-x32b.google.com ([2607:f8b0:4864:20::32b]:33898) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jSFgM-0004lh-FH; Sat, 25 Apr 2020 03:57:02 -0400 Original-Received: by mail-ot1-x32b.google.com with SMTP id 72so16802768otu.1; Sat, 25 Apr 2020 00:57:01 -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=gMBRh96j7WNyadMgmx+27LH7XgOPIchaCUyIDIgAFHA=; b=OEvRmyaGlj1QUMIN+p78B6TKfMc5ahuQtLoRkoxW/DEGahciShK1DeF93ZTu8tkNG3 TrkOImEy8aInq1aEQb+zSO6WnG6+RI59fyo5g0lWgoyFkrYoOaXZbnhQGgOD5qaeItc0 PNU7kfxrJ80wbdT3SJAE5/OfF3dgOPyXBDm9ZoPRCH8QqH7ipTDpXvak3ZWUpm9uj1Dx QIMc1CIuCG/Bjzb8SKHzMemt3lp6WxzrAONwGv9XEefIH7hJ/aFVYScRdsGhH7QYZarz ZXv1/LWbz1aex9v9HAqE7rWnzQVWZOYq/l9T1Qv0bqk1bSX6ogxtBfkSR+KUMvP5uZbd 1g7w== 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=gMBRh96j7WNyadMgmx+27LH7XgOPIchaCUyIDIgAFHA=; b=o0pQH8ivLAuJYkJVuNmgl7yXneYb5acigWlbDilXJsNTq2DYnoLhkyTyggjUlmgjXV Mvec3/QuebmsO1z4fsTAfXURLLSCOZ3Ws03bla5A6rE7u8NTkmqAvLLqYtnk6SCaWd6O hY/ISw1tgOOTruWriLhj9pS/WEtZpIgKBzZXIenebQ0MhQamiS0Tf0mnbrD5nUsCzNNh zkkCWvXbwFRLWP+JEHG4f8BHJZcT5b0RRE9Yp4AAqR4e2HYtlSrtN1Ga/J3yizAw5sxe nm5SKb/cVhOdFUQ82XRfwQKIgtaNOW9czruIdoQVc88FxDSqpLQSG4VQygxsGXY7rd0U kE/w== X-Gm-Message-State: AGi0PuZFMjL39xqwUxEctVcDNihGuIvBBl0GxahQYNDVsJeUsqfH6vHK 8sb9YEBf112eUZIkoZ4qGPDpD06hj40zqPuPuu4Cvw== X-Google-Smtp-Source: APiQypItCgJ+dkhQTVe6s1CzG16W2L6kfBvoyy05/DMTZ8Vs63/wpcG8aAsC6GsmquTGCShI7a/whB5HlRKTt3E/KLM= X-Received: by 2002:a05:6830:1d99:: with SMTP id y25mr81848oti.235.1587801420427; Sat, 25 Apr 2020 00:57:00 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::32b; envelope-from=theophilusx@gmail.com; helo=mail-ot1-x32b.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::32b 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:247757 Archived-At: --000000000000a3766505a418d347 Content-Type: text/plain; charset="UTF-8" On Sat, 25 Apr 2020 at 13:32, Richard Stallman wrote: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > > 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'. 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. The pull request adds nothing to your repo. Some of this confusion is likely due to github and to some extent, gitlab, putting some UI 'sugar' on top of the process to make it easier. However, you can do/manage pull requests completely from the git command line (although it is a bit fiddly). Basically, you add the PR repository to your LOCAL repo 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. In this respect, it is no different from when the owner recieves a patch via email. Others cannot see the PR in the master repository (they would be able to see it and clone it from the pull requestor's repository, just like I can pull fro any public repository in github or gitlab), It is only after the owner (or someone with write permission to the 'master' repository (i.e. the one on savannah) merges that PR into the master repo that it will be seen by anyone who has cloned the master repo. It should also be noted that the 'git pull-request' command is NOT a standard git command. This is an extension that github has added. It would be possible to create an FSF GNU git module which does something similar or more specific to suit FSF requirements. For example, you could have a module which looks at the size of the changes in the commit, checks a list of people who have submitted copyright paperwork and only allow the pull request to complete if either the change is 'tiny' or the submitter has provided copyright assignment. -- regards, Tim -- Tim Cross --000000000000a3766505a418d347 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, 25 Apr 2020 at 13:32, Richard= Stallman <rms@gnu.org> wrote:
=
[[[ To any NSA and = FBI agents reading my email: please consider=C2=A0 =C2=A0 ]]]

If this is meant as a way to implement pull requests, there is no need
for it.=C2=A0 We will not implement pull requests by copying proposed
patches into our repo before they are installed.


There seems to be some confusion regar= ding 'pull requests'. 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 a= dded to your repo until you perform the merge. The pull request adds nothin= g to your repo. Some of this confusion is likely due to github and to some = extent, gitlab, putting some UI 'sugar' on top of the process to ma= ke it easier. However, you can do/manage pull requests completely from the = git command line (although it is a bit fiddly).=C2=A0 Basically, you add th= e PR repository to your LOCAL repo and check it out as a branch. Do whateve= r 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 w= ith your local master branch. At this point, there is still no change to th= e 'main' master repository. If the merge all goes fine, you can the= n push the changes to your master branch in your main repository. It is onl= y at this point that the changes have been introduced to the main repositor= y.

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. In this respect, it is no differ= ent from when the owner recieves a patch via email. Others cannot see the P= R in the master repository (they would be able to see it and clone it from = the pull requestor's repository, just like I can pull fro any public re= pository in github or gitlab), It is only after the owner (or someone with = write permission to the 'master' repository (i.e. the one on savann= ah) merges that PR into the master repo that it will be seen by anyone who = has cloned the master repo.

It should also be note= d that the 'git pull-request' command is NOT a standard git command= . This is an extension that github has added. It would be possible to creat= e an FSF GNU git module which does something similar or more specific to su= it FSF requirements. For example, you could have a module which looks at th= e size of the changes in the commit, checks a list of people who have submi= tted copyright paperwork and only allow the pull request to complete if eit= her the change is 'tiny' or the submitter has provided copyright as= signment.
=C2=A0
--
regards,

Tim

--
Tim Cross

=
--000000000000a3766505a418d347--