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: GNU ELPA package discoverability Date: Sun, 24 May 2020 19:15:46 +1000 Message-ID: References: <35DBF02E-44D7-41E5-A217-7D6EC84ED221@icloud.com> <4e937898-ae46-710a-cbca-e452a1156fa1@yandex.ru> <2e630dc7-ba1d-e4c9-74b3-4da976db1e82@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000069fddf05a6614fa3" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="20082"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs developers To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 24 11:16:34 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 1jcmkD-000573-FA for ged-emacs-devel@m.gmane-mx.org; Sun, 24 May 2020 11:16:33 +0200 Original-Received: from localhost ([::1]:48760 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcmkC-0000L4-ES for ged-emacs-devel@m.gmane-mx.org; Sun, 24 May 2020 05:16:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50640) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jcmjj-0008M4-9m for Emacs-devel@gnu.org; Sun, 24 May 2020 05:16:03 -0400 Original-Received: from mail-ot1-x32d.google.com ([2607:f8b0:4864:20::32d]:44094) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jcmjf-0008GP-MB; Sun, 24 May 2020 05:16:00 -0400 Original-Received: by mail-ot1-x32d.google.com with SMTP id f18so11715229otq.11; Sun, 24 May 2020 02:15:59 -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=/yao/3/WRGd3BV+FIGN1uDYkV+H0ESdi4SJ3w1IXuxM=; b=UuIa5qbCsthIBzqZpzkO/HyW/8py4jj9qbLkpgj7vZVT7uzfK0IBOUzMlgLC3jbom1 pEiIrXSvK8Ybxx0TZaYdbI/GHADYDspXfjeqmY1phsNRG+267cxN/BaH+1nKiJfLBILJ P9ypzK9/ABVPfaxpP8TOlAp/+DxBF4snbgSGNObVLKAhSlB394In7f4A9Of5kj5b0Q2g +jAVVm7LJNbSG/8nutLMO3mjmpOwcgE8O5GlPCEMiG7K0fE5hHsvkKcokfMuV2dyMUdO WmgfAMr/0SiDzioSGTJowPpa6saBbgZrtH/WxyBS2h0jtPPzeBTe0C7DwgwXD8QS7ciS KLkQ== 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=/yao/3/WRGd3BV+FIGN1uDYkV+H0ESdi4SJ3w1IXuxM=; b=GxBBh+VInceDv0vMZuHqBv7432fA+xN9JRWRsVMfZoQEeVwkOJIH4PQfjAyX/DmIMZ UuK5voJsUdu82xc+lkP53FfC2byLFf2qsFCdj445MnsZF9k6zIrlG2yb9iK8O80vaclM G9nz7pIoPE+lIfUv4GnE8zH39K7uaMxS6EufQ53wDtmGWKu5jvQqQcKPe/OxgxHRS82o jFQ4U8HJkuBeAz2aKKl0mV3ppsTpMlWyloT/jxVpGA0lspeK+j8vejCIaOO30tT1avcA 0E2BT/tdksLPJPeIlCTpJcA7cP0eLyzml+875Ss1iab88Px1IEqHxCNaag+ZADl4CrGh qWxw== X-Gm-Message-State: AOAM531kAYsIQOaPfOQLthmNS0Tcko4wGMH30/Z9jwR8B0Of2XvFKjvv sUkg+VbXwwkb5EZwsUMFfyVlR8U5VSEU7TvpfQBKv6lp X-Google-Smtp-Source: ABdhPJxTnf1CoR2h578m8Hqh2SAQAKFIl+ziUuTiwqFPqdxjw/OwnCfN4sQ0Gky2KH3697MqOAncnI4DkJSGu6x8Gnc= X-Received: by 2002:a9d:66c6:: with SMTP id t6mr16621356otm.56.1590311757936; Sun, 24 May 2020 02:15:57 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::32d; envelope-from=theophilusx@gmail.com; helo=mail-ot1-x32d.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN 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:251312 Archived-At: --00000000000069fddf05a6614fa3 Content-Type: text/plain; charset="UTF-8" On Sun, 24 May 2020 at 13:53, Richard Stallman wrote: > > > You mention 'within the limits of our basic goals'. I don't think this > has > > been clearly defined > > The goal of the GNU Project is to develop the entirely-free operating > system GNU and rid the world of nonfree software. It is a very > ambitious goal, but we will push as far as we can, and we will not > give up. > Yes, but more specifically, what are the goals of ELPA (and the proposed ELPA without copyright assignment)? How are these to fit into the GNU Emacs eco-system? What should go into ELPA, what should go into Emacs 'core'? How will these ELPA archives work with GNU Emacs releases? (e.g. Do the packages in these archives need to be compliant with new release, such as not using functions flagged obsolete, using updated versions of libs/modules in emacs core etc). Will an Emacs release be held up if there is a package in ELPA that does not work with new version? When can packages be updated and what backwards compatibility with older versions of Emacs should they support? What about platforms - do packages need to support all the same platforms that Emacs supports? for the archive where copyright is assigned to the FSF, who is responsible for maintenance and updates? When should packages be removed? > > > Something which will need to > > be considered at this point is available maintenance resources. For > > example, at a high level, having a stable and reliable archive of elisp > > packages which are guaranteed to be GPL compliant and do not reference, > > link-to or encourage the use of non-free software, but does not require > > assignment of copyright to the FSF may be a worthy goal. However, if > the > > resources are not available to maintain such an archive and or > > adding/updating code in the archive becomes a slow process because > > approvals take too long (because there are insufficient resources), it > > simply won't work. > > Since we will put less effort into checking and maintaining these > packages than into GNU ELPA packages, we can surely handle more > packages in it. > > How many more? It isn't useful to worry about. If this is the > right approach, we will try it and see how many. > You seem to be focusing on just the new proposed non-copyright assignment repository. There is much unclear about the existing repository, including what should and should not be put there, who is responsible for making decisions and managing that resource, maintenance and life cycle maintenance of packages etc. > > > Document process workflow, the steps a developer needs to follow in > order > > to get their code into the appropriate place and how to manage bugs, > > Our usual approach is to try things, develop a practice that works, > then write it down. Too much advance planning is a pain, and often it > turns out not to be useful. Once we have real experience we can make > a better plan. > Which is fine provided it does get done. Has this been done for the existing ELPA repository? If so, can you point me to it as I'd like to read it to improve my understanding? > > > developer should be confident [perse] now know[s] what is the > appropriate > > location for [per] code > > When would that question arise? In what scenario? > > To put it back into context, what I wrote was - Define guidelines to help developers decide where is the best location for their library, module, extension etc. After reading these guidelines, a developer should be confident they now know what is the appropriate location for their code. I think this is a common question developers would ask themselves. Simple scenario - I have an elisp package which I wrote, which is licensed under the GPL and which I think others might find useful. I need to decide how to make it available. The package.el packaging system seems to be a popular choice, I now need to decide which repository to put it in. My choices are - GNU ELPA (if I'm prepared to assign copyright to FSF) - GNU Unassigned Copyright ELPA - MELPA - Public archive on my web site All of these options have pros and cons. However, without adequate documentation regarding the GNU repositories, workflows and guidelines on using them and what the commitments and expectations are with respect to having a package in one of these two repositories, I'm in the dark. I cannot assess whether they are appropriate for me. To get clarification, all i can do is send a message to the list, which too often will end up in a long thread going back and forth and with little definitive outcome. I may get some clarification, but likely end up with more questions. In the end, I decide to initially release through MELPA as it is simple and quick. I can always change later should things become clearer. Six months later, I'm still using MELPA. Most of my questions have been answered, but now I'm use to MELPA and it is working fine and has achieved my goal, which was simply to make my package available to others who may find it useful. I'll just leave it as it is. Most Emacs users use MELPA anyway and while I believe my package could be in an official GNU archive, the work required to do that is hard to justify, plus I now have other things to work on. The above is not an uncommon scenario. I have asked a number of package owners why they put their package in MELPA rather than GNU ELPA and the answer generally came down to two things. Number one was a perception it was just too hard - process was unclear, time it takes too long and there were just too many unknowns. The second common response was about copyright assignment - most of the time it wasn't so much about assigning copyright so much as uncertainty about what that really meant (i.e. and education issue). Having a non-copyright assignment repository may help, but only if all the rest becomes clearer and easier. A 'build it and they will come' approach is unlikely to work - there is already a solution, MELPA. While that is not a good solution from a philosophical point of view, it is a fine solution for many who have released packages that are GPL'd and don't use or encourage non-free software. Those authors have met their moral obligations by release their software with a GPL and by avoiding use of or encourage use of non-free software. The fact other software in the repository is not compliant is not really their concern. You could argue it should be, but then you also have to take into account individual capacity and freedoms and the fact they probably would have used a more complaint repository if one had been available that did not have too many barriers. -- regards, Tim -- Tim Cross --00000000000069fddf05a6614fa3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, 24 May 2020 at 13:53, Richard= Stallman <rms@gnu.org> wrote:
=

=C2=A0 > You mention 'within the limits of our basic goals'. I d= on't think this has
=C2=A0 > been clearly defined

The goal of the GNU Project is to develop the entirely-free operating
system GNU and rid the world of nonfree software.=C2=A0 It is a very
ambitious goal, but we will push as far as we can, and we will not
give up.

Yes, but more specifically, wh= at are the goals of ELPA (and the proposed ELPA without copyright assignmen= t)? How are these to fit into the GNU Emacs eco-system? What should go into= ELPA, what should go into Emacs 'core'? How will these ELPA archiv= es work with GNU Emacs releases? (e.g. Do the packages in these archives ne= ed to be compliant with new release, such as not using functions flagged ob= solete, using updated versions of libs/modules in emacs core etc). Will an = Emacs release be held up if there is a package in ELPA that does not work w= ith new version? When can packages be updated and what backwards compatibil= ity with older versions of Emacs should they support? What about platforms = - do packages need to support all the same platforms that Emacs supports? f= or the archive where copyright is assigned to the FSF, who is responsible f= or maintenance and updates? When should packages be removed?=C2=A0

=C2=A0

=C2=A0 >=C2=A0 Something which will need to
=C2=A0 > be considered at this point is available maintenance resources.= For
=C2=A0 > example, at a high level, having a stable and reliable archive = of elisp
=C2=A0 > packages which are guaranteed to be GPL compliant and do not re= ference,
=C2=A0 > link-to or encourage the use of non-free software, but does not= require
=C2=A0 > assignment of copyright to the FSF may be a worthy goal. Howeve= r, if the
=C2=A0 > resources are not available to maintain such an archive and=C2= =A0 or
=C2=A0 > adding/updating code in the archive becomes a slow process beca= use
=C2=A0 > approvals take too long (because there are insufficient resourc= es), it
=C2=A0 > simply won't work.

Since we will put less effort into checking and maintaining these
packages than into GNU ELPA packages, we can surely handle more
packages in it.

How many more?=C2=A0 It isn't useful to worry about.=C2=A0 If this is t= he
right approach, we will try it and see how many.

<= /div>
You seem to be focusing on just the new proposed non-copyright as= signment repository. There is much unclear about the existing repository, i= ncluding what should and should not be put there, who is responsible for ma= king decisions and managing that resource, maintenance and life cycle maint= enance of packages etc.=C2=A0=C2=A0

=C2=A0 > Document process workflow, the steps a developer needs to follo= w in order
=C2=A0 > to get their code into the appropriate place and how to manage = bugs,

Our usual approach is to try things, develop a practice that works,
then write it down.=C2=A0 Too much advance planning is a pain, and often it=
turns out not to be useful.=C2=A0 Once we have real experience we can make<= br> a better plan.

Which is fine provided i= t does get done. Has this been done for the existing ELPA repository? If so= , can you point me to it as I'd like to read it to improve my understan= ding?=C2=A0

=C2=A0 > developer should be confident [perse] now know[s] what is t= he appropriate
=C2=A0 > location for [per] code

When would that question arise?=C2=A0 In what scenario?

<= div>

To put it back into co= ntext, what I wrote was -

=C2=A0Define guidelines = to help developers decide where is the best location for their library, mod= ule, extension etc. After reading these guidelines, a developer should be c= onfident they now know what is the appropriate location for their code.=C2= =A0

I think this is a common question developers w= ould ask themselves. Simple scenario -

I have an e= lisp package which I wrote, which is licensed under the GPL and which I thi= nk others might find useful. I need to decide how to make it available. The= package.el packaging system seems to be a popular choice, I now need to de= cide which repository to put it in. My choices are

- GNU ELPA (if I'm prepared to assign copyright to FSF)
- GN= U Unassigned Copyright ELPA
- MELPA
- Public archive on= my web site

All of these options have pros and co= ns. However, without adequate documentation regarding the GNU repositories,= workflows and guidelines on using them and what the commitments and expect= ations are with respect to having a package in one=C2=A0 of these two repos= itories, I'm in the dark. I cannot assess whether they are appropriate = for me. To get clarification, all i can do is send a message to the list, w= hich too often will end up in=C2=A0a long thread going back and forth and w= ith little definitive outcome. I may get some clarification, but likely end= up with more questions.=C2=A0

In the end, I decid= e to initially release through MELPA as it is simple and quick. I can alway= s change later should things become clearer.=C2=A0

Six months later, I'm still using MELPA. Most of my questions have bee= n answered, but now I'm use to MELPA and it is working fine and has ach= ieved my goal, which was simply to make my package available to others who = may find it useful. I'll just leave it as it is. Most Emacs users use M= ELPA anyway and while I believe my package could be in an official GNU arch= ive, the work required to do that is hard to justify, plus I now have other= things to work on.=C2=A0

The above is not an unco= mmon scenario. I have asked a number of package owners why they put their p= ackage in MELPA rather than GNU ELPA and the answer generally came down to = two things. Number one was a perception it was just too hard - process was = unclear, time it takes too long and there were just too many unknowns. The = second common response was about copyright assignment - most of the time it= wasn't so much about assigning copyright so much as uncertainty about = what that really meant (i.e. and education issue).=C2=A0

Having a non-copyright assignment repository may help, but only if a= ll the rest becomes clearer and easier. A 'build it and they will come&= #39; approach is unlikely to work - there is already a solution, MELPA. Whi= le that is not a good solution from a philosophical point of view, it is a = fine solution for many who have released packages that are GPL'd and do= n't use or encourage non-free software. Those authors have met their mo= ral obligations by release their software with a GPL and by avoiding use of= or encourage use of non-free software. The fact other software in the repo= sitory is not compliant is not really their concern. You could argue it sho= uld be, but then you also have to take into account individual capacity and= freedoms and the fact they probably would have used a more complaint repos= itory if one had been available that did not have too many barriers.=C2=A0<= /div>


--
regards,

Tim=

--
Tim Cross

<= /div> --00000000000069fddf05a6614fa3--