From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: non-gnu elpa issue tracking Date: Sat, 12 Dec 2020 17:37:10 +1100 Message-ID: References: <20201209125516.lenqswi7fhiscbr2@E15-2016.optimum.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000002cc18f05b63ea457" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5839"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Jean Louis , Stefan Kangas , Boruch Baum , thibaut.verron@gmail.com, Emacs developers To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 12 07:38:37 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 1knyY8-0001QN-UB for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Dec 2020 07:38:37 +0100 Original-Received: from localhost ([::1]:43270 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knyY7-0005jD-SJ for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Dec 2020 01:38:35 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44534) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1knyX0-0005IR-Ts for emacs-devel@gnu.org; Sat, 12 Dec 2020 01:37:26 -0500 Original-Received: from mail-oi1-x230.google.com ([2607:f8b0:4864:20::230]:45694) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1knyWy-00044l-Iw; Sat, 12 Dec 2020 01:37:26 -0500 Original-Received: by mail-oi1-x230.google.com with SMTP id f132so12644768oib.12; Fri, 11 Dec 2020 22:37:23 -0800 (PST) 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=eQQLywqD/IinBvXRyPjATB0oEdiS5JAStes89I0/QPc=; b=X/DCbipoHSPoYSTkcJf7lBa+k8JeUk5yDjBMLAoT6FE3zcO7vytmaawpNV05JHvCEz EJ7MKLgLpR+vxsUgUzj0wx3ieLvHnPkwqpqPQmxA8NRxVMLi5TvSUqu4ZPnAZ7Fi2Gb0 d0uIEJloD9trW7ays8rUwSSzUDoX0TsWtr6hhfxZOjAFqMArmDoXjJ3mQWWxU8BlrWIK WR+tuqlCWgdvoJwSDdKOrcOBxHSsE2MrhJVXONRPXO/ABkd9m4vsHCQQIVGYGwqZgArg cgoBtKenSQEM4ghOFU+Tc3J85GWyvt3ON2b6AwSEjHydMzhOj3YD6jr/PndiUe3q9onT ZQDg== 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=eQQLywqD/IinBvXRyPjATB0oEdiS5JAStes89I0/QPc=; b=bpY+Wm7O3iUoGTT68EkI/Bu0fbmLXlKMo4u1bxG0jLK8L0MkvkW0nF3xUVtbTbrPDF ZR9Qw0ghQNARIwiuWNMT3REZ4XfC5CCCUlKR6/T7Jxw1avdlPZ8je1fsASf2yG/D6gbQ pp9OTrtlguj/id0SZ6eUyBBRfV0Mj6gALxCUVj8T39l4LBL31tF5tA1VVPFCgbC6IqFs UF6ygXn3xc0I+j3EQx19RNjAgHF67JrFd55eGaOKE5YMttJKWaWy7ViFp4155thOX6v+ O7wqIaqTit3QHX+Zhg6tKXolAhCW5a60ebIk4wnWF/vJi72rCuYO8lVJqvwomslRgn7o yJyg== X-Gm-Message-State: AOAM530gdjvNxpcC/6v39aJ9+ZGCr/WJtNX0+1stcJA6RTeJ230U0B54 DN/w0TgMVj2a2Awotc44I6izPgGBdU14VajIWmqd1RMzKd/dnw== X-Google-Smtp-Source: ABdhPJwFl5yObbv8MSQ7nTrfWKhChY7czhI6UkwUPTrFXbBBJcmUotrwc0I+/DoxB1pfU6yDCDMW1cRbLtGdFsL/aZ0= X-Received: by 2002:a05:6808:8f0:: with SMTP id d16mr11917236oic.47.1607755042175; Fri, 11 Dec 2020 22:37:22 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::230; envelope-from=theophilusx@gmail.com; helo=mail-oi1-x230.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:260711 Archived-At: --0000000000002cc18f05b63ea457 Content-Type: text/plain; charset="UTF-8" Bottom line is that if packages in non-GNU ELPA are hosted on Github, like it or not, you are encouraging the use of Github. Yes, there are many Github features you can access from the command line and via other means, like commenting on issues via email, but these other mechanisms typically take more effort and are not as convenient (and have limitations - you cannot use markup when commenting on issues via email for example). The non-GNU ELPA is supposed to be a repository for packages which are GPL compliant and it is a reasonable expectation that those who make their packages GPL compliant do so because they support the philosophical goals of the FSF. Therefore, I don't think it is too much to ask that they also have those packages hosted on a platform which also supports these same philosophical goals. As I understand it, non-GNU ELPA is not supposed to be a repository for all other packages where the author doe snot want to assign copyright to the FSF. It is supposed to be for all other GPL compliant packages where the author does not want to assign copyright to the FSF. I think a mandatory requirement should simply be that any packages which go into non-GNU ELPA are hosted on an approved platform. We could point to a list of such hosting providers e.g. https://www.gnu.org/software/repo-criteria-evaluation.html and say Grade C or better only. . This will also have the added incentive of encouraging better hosting options. It might even encourage GitLab for example, to enhance their environment to meet Class B. Many people have selected Github for hosting simply because it was the best known solution. With a little encouragement, they would probably be willing to move to at least GitLab, which offers many of the similar convenience features of Github. Being able to host your package in non-GNU ELPA might be that encouragement. BTW I also think the questions regarding openess, arguments, not hurting feelings etc can be largely avoided by simply having clear well publicised policy which outlines the requirements for inclusion in non-GNU ELPA. The README is a good start, but it will likely take a few rounds of editing to get it right and make it clear (a challenging task, but not impossible) and a documented process for requesting a review for a rejected package or a package which has been included which someone thinks is not compliant. On Sat, 12 Dec 2020 at 16:36, 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. ]]] > > > As far as I remember from a previous discussion, it is possible to use > > github with javascript disabled, but creating an account requires > > running non-free javascript for the captcha. And it is not possible to > > open or comment on issues without an account. > > Assuming someone who knows for certain confirms that information, I > have to conclude that reporting bugs via GitHub comments is not an > ethical way to accept bug reports. We cannot direct users to report > bugs in the package that way. We should edit the README file to > remove that. > > But there are other kinds of arrangements we can ask to make with the > package developers, such as > > * The developers check bug-gnu-emacs for reports about their package. > > * Establish an email address which will forward to them, > and give that as the way to report bugs in that package. > > * A volunteer relayer who already has a GitHib account checks > bug-gnu-emacs for reports about that package, and enters them in > GitHib as comments. The developers will have to reach the OP by email > -- the relayer would not want to keep relaying every conversation > for its whole length. > > If the developers propose something else, and it meets the moral > requirements and isn't too much work, and we can do it, we should be > flexible. I expect most packages won't get a bug report every month. > > -- > Dr Richard Stallman > Chief GNUisance of the GNU Project (https://gnu.org) > Founder, Free Software Foundation (https://fsf.org) > Internet Hall-of-Famer (https://internethalloffame.org) > > > > -- regards, Tim -- Tim Cross --0000000000002cc18f05b63ea457 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bottom line is that if packages in non-GNU ELPA are hosted= on Github, like it or not, you are encouraging the use of Github. Yes, the= re are many Github features you can access from the command line and via ot= her means, like commenting on issues via email, but these other mechanisms = typically take more effort and are not as convenient (and have limitations = - you cannot use markup when commenting on issues via email for example).= =C2=A0

The non-GNU ELPA is supposed to be a repository f= or packages which are GPL compliant and it is a reasonable expectation=C2= =A0that those who make their packages GPL compliant do so because they supp= ort the philosophical goals of the FSF. Therefore, I don't think it is = too much to ask that they also have those packages hosted on a platform whi= ch also supports these same philosophical goals. As I understand it, non-GN= U ELPA is not supposed to be a repository for all other packages where the = author doe snot want to assign copyright to the FSF. It is supposed to be f= or all other GPL compliant packages where the author does not want to assig= n copyright to the FSF.=C2=A0

I think a mandatory = requirement should simply be that any packages which go into non-GNU ELPA a= re hosted on an approved platform. We could point to a list of such hosting= providers e.g. https://www.gnu.org/software/repo-criteria-evaluation.html = and say Grade C or better only. .=C2=A0

This will = also have the added incentive of encouraging better hosting options. It mig= ht even encourage GitLab for example, to enhance their environment to meet = Class B.=C2=A0

Many people have selected Github fo= r hosting simply because it was the best known solution. With a little enco= uragement, they would probably be willing to move to at least GitLab, which= offers many of the similar convenience features of Github.=C2=A0 Being abl= e to host your package in non-GNU ELPA might be that encouragement.=C2=A0

BTW I also think the questions regarding openess, a= rguments, not hurting feelings etc can be largely avoided by simply having = clear well publicised policy which outlines the requirements for inclusion = in non-GNU ELPA. The README is a good start, but it will likely take a few = rounds of editing to get it right and make it clear (a challenging task, bu= t not impossible) and a documented process for requesting a review for a re= jected package or a package which has been included which someone thinks is= not compliant.=C2=A0

On Sat, 12 Dec 2020 at 16:36, Richard Stallman &= lt;rms@gnu.org> wrote:
[[[ To any NSA and FBI agents = reading my email: please consider=C2=A0 =C2=A0 ]]]
[[[ whether defending the US Constitution against all enemies,=C2=A0 =C2=A0= =C2=A0]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]<= br>
=C2=A0 > As far as I remember from a previous discussion, it is possible= to use
=C2=A0 > github with javascript disabled, but creating an account requir= es
=C2=A0 > running non-free javascript for the captcha. And it is not poss= ible to
=C2=A0 > open or comment on issues without an account.

Assuming someone who knows for certain confirms that information, I
have to conclude that reporting bugs via GitHub comments is not an
ethical way to accept bug reports.=C2=A0 We cannot direct users to report bugs in the package that way.=C2=A0 We should edit the README file to
remove that.

But there are other kinds of arrangements we can ask to make with the
package developers, such as

* The developers check bug-gnu-emacs for reports about their package.

* Establish an email address which will forward to them,
and give that as the way to report bugs in that package.

* A volunteer relayer who already has a GitHib account checks
bug-gnu-emacs for reports about that package, and enters them in
GitHib as comments.=C2=A0 The developers will have to reach the OP by email=
-- the relayer would not want to keep relaying every conversation
for its whole length.

If the developers propose something else, and it meets the moral
requirements and isn't too much work, and we can do it, we should be flexible.=C2=A0 I expect most packages won't get a bug report every mon= th.

--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





--
regards,

Tim

--
Tim Cross

--0000000000002cc18f05b63ea457--