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: Sat, 23 May 2020 10:29:59 +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="0000000000003c9b4c05a645d9e3" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="94801"; 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 Sat May 23 02:30:59 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 1jcI42-000OaW-Sa for ged-emacs-devel@m.gmane-mx.org; Sat, 23 May 2020 02:30:58 +0200 Original-Received: from localhost ([::1]:54704 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcI41-0002CJ-Va for ged-emacs-devel@m.gmane-mx.org; Fri, 22 May 2020 20:30:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35130) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jcI3K-0001hG-ED for Emacs-devel@gnu.org; Fri, 22 May 2020 20:30:14 -0400 Original-Received: from mail-oi1-x22b.google.com ([2607:f8b0:4864:20::22b]:32919) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jcI3J-0008Mr-9G; Fri, 22 May 2020 20:30:14 -0400 Original-Received: by mail-oi1-x22b.google.com with SMTP id o24so10871960oic.0; Fri, 22 May 2020 17:30:12 -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=4QKKmucvKiCNEX71gWcwO1cxh4kG3y1nX4tz87VttaE=; b=jHcuQ4smQgY/jIH+JDhU4CuVaDqlst832ScyTfXCzXRLVmvdsZA+SUEZpl+9mNoO+A W62rGcNFC7CsB/Kr99DkVGNjI91oLYZ7OneLUQc2SosWRVmnpcTnfymK8Vh0OgyelQQc o1o7eawgjd8G8prxuf3s6Kmg4U6kVFPgEclzyn3aS+vjIjUAC8dKaRys33nkgROTkAzD FGC4SwgLl10CqrI2MEjKaok/AJlKNnBWTNQ5dxY9KDhCdrU02c2WwIWiOq8tlDU+vooB 7clJE6JyDel7RsQZRAz1rETIykkVNCqx8cQL7z9vZDqjHO7Bq5BVRq48P3NpuCteR4Ka eynQ== 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=4QKKmucvKiCNEX71gWcwO1cxh4kG3y1nX4tz87VttaE=; b=sCL6OHTAq3c99Z1EUb0byPeS10VqYRFGXxsU4sB6YvfNIqc9ebNtPrLA2RzqMaQy8l Vcg2dkbqablgm4YNG8BX5DuixSYsmqCjgNCnVOp+/gA7N1FEpHFwdXqIRRtgvx9oxOwB bryUNnW+PEugvNotQK8aICV1KTKei6LNdjUZw+L4u+Y2eDDOHmE0vwLSB7QI0ypVZ+5X 2zk2QVT5PRuoLWFWCrMrkQO/VcYb7JfJzoHly+QenNL3EicjMw6r7Yg8A6xsD8Cc5Nbp 6c+m0315rOe/1ouTAE1Iw9OzjVmz845NCZLFveV2tgztt5v6Mm4qmP/Iy8At2gNWQbmy 5ALg== X-Gm-Message-State: AOAM533GpNGULDkHjR2YLFh+ER7IIhOuuMMssJbYm1GgD+BFzB5vunM7 hUwqCaZdFHgNMxgOiqwtgtb/DoQH1gTuRz16uiFiCA== X-Google-Smtp-Source: ABdhPJxdBjqJ5aWi4WSNjqU0qJh8ItHvbw3UoShU/grRzWaQAK3w3D+nVgwbPY7LamsLvFxKbp/E+CIxVs5m9MSGtTE= X-Received: by 2002:a54:4f0a:: with SMTP id e10mr4269339oiy.146.1590193811133; Fri, 22 May 2020 17:30:11 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::22b; envelope-from=theophilusx@gmail.com; helo=mail-oi1-x22b.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:251253 Archived-At: --0000000000003c9b4c05a645d9e3 Content-Type: text/plain; charset="UTF-8" On Fri, 22 May 2020 at 13:11, 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. ]]] > > > Clarify what ELPA is for, how it is managed and what the process is to > get > > a package into ELPA, then streamline this process and provide an > efficient > > workflow for package maintenance and many may begin to use ELPA more > and > > rely on MELPA less. Even more importantly, ELPA might become the > definitive > > archive for good quality, stable and GPL compliant Emacs packages. > > We are looking at how to do this, within the limits of our basic > goals. I'm thinking about making a second ELPA which won't require > copyright assignment. > > Which is possibly a good idea. However, I think there are more basic questions and issues which need addressing first. You mention 'within the limits of our basic goals'. I don't think this has been clearly defined and/or does not have consensus. Start by defining the core rationale and goals for a GNU elisp archive. Whether we do or do not need a second ELPA is just an implementation detail. First, have clarity and agreement on what the goals are and then consider the implementation. Decide whether we need just one or more GNU elisp archives (maybe called ELPA and XXX, maybe not, maybe actually separate archives or maybe tagged differently - again, implementation details). 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. A big reason MELPA has been so popular is the overhead associated with getting code into that repository is low and once in, maintenance overhead (updates, patching etc) is trivial. 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.e. Emacs core, a GNU ELPA repository or some external repository (which does not need to be specified or referenced in the guidelines, it is just an external repository). These guidelines should also articulate what the on-going responsibilities and expectations are with regard to on-going maintenance of the code in each location (Emacs core, GNU ELPA). 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, patches, updates and releases. Developers need to understand what they are committing to before making the commitment. -- regards, Tim -- Tim Cross --0000000000003c9b4c05a645d9e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, 22 May 2020 at 13:11, Richard= Stallman <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 > Clarify what ELPA is for, how it is managed and what the proces= s is to get
=C2=A0 > a package into ELPA, then streamline this process and provide a= n efficient
=C2=A0 > workflow for package maintenance and many may begin to use ELPA= more and
=C2=A0 > rely on MELPA less. Even more importantly, ELPA might become th= e definitive
=C2=A0 > archive for good quality, stable and GPL compliant Emacs packag= es.

We are looking at how to do this, within the limits of our basic
goals.=C2=A0 I'm thinking about making a second ELPA which won't re= quire
copyright assignment.

Which is possibly a good ide= a. However, I think there are more basic questions and issues which need ad= dressing first.=C2=A0

You mention 'within the = limits of our basic goals'. I don't think this has been clearly def= ined and/or does not have consensus. Start by defining the core rationale a= nd goals for a GNU elisp archive. Whether we do or do not need a second ELP= A is just an implementation detail. First, have clarity and agreement on wh= at the goals are and then consider the implementation.=C2=A0

=
Decide whether we need just one or more GNU elisp archives (mayb= e called ELPA and XXX, maybe not, maybe actually=C2=A0separate archives or = maybe tagged differently - again, implementation details). 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 eli= sp 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 ass= ignment of copyright to the FSF may be a worthy goal. However, if the resou= rces are not available to maintain such an archive and=C2=A0 or adding/upda= ting code in the archive becomes a slow process because approvals take too = long (because there are insufficient resources), it simply won't work. = A big reason MELPA has been so popular is the overhead associated with gett= ing code into that repository is low and once in, maintenance overhead (upd= ates, patching etc) is trivial.=C2=A0=C2=A0

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 the= ir code i.e. Emacs core, a GNU ELPA repository or some external repository = (which does not need to be specified or referenced in the guidelines, it is= just an external repository). These guidelines should also articulate what= the on-going responsibilities and expectations are with regard to on-going= maintenance of the code in each location (Emacs core, GNU ELPA).=C2=A0=C2= =A0

Document process workflow, the steps a develop= er needs to follow in order to get their code into the appropriate place an= d how to manage bugs, patches, updates and releases. Developers need to und= erstand what they are committing to before making the commitment.=C2=A0


--=C2=A0
regards,

<= /div>
Tim

--
Tim Cross

=
--0000000000003c9b4c05a645d9e3--