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: Wed, 20 May 2020 10:28:42 +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="00000000000020f4ac05a6097b88" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="109854"; 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 Wed May 20 02:29:42 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 1jbCcA-000SRN-2W for ged-emacs-devel@m.gmane-mx.org; Wed, 20 May 2020 02:29:42 +0200 Original-Received: from localhost ([::1]:51318 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbCc8-0001Nr-7Y for ged-emacs-devel@m.gmane-mx.org; Tue, 19 May 2020 20:29:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56342) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbCbR-0000wm-KN for Emacs-devel@gnu.org; Tue, 19 May 2020 20:28:57 -0400 Original-Received: from mail-oo1-xc29.google.com ([2607:f8b0:4864:20::c29]:46731) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jbCbQ-000287-F4; Tue, 19 May 2020 20:28:57 -0400 Original-Received: by mail-oo1-xc29.google.com with SMTP id g22so362205oop.13; Tue, 19 May 2020 17:28:55 -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=W4vSJoKjMqMfWKMJRtT8SnK5hGotmFteFKO3vRLVENM=; b=XMBmshcnw1BZOqO9AMUnc/EvGuUx5K5RDMmW9kemRDunzgjM5X4tluWbhv+iKDPJt/ YAhi5/N97QcMbrhFkAkA3XrE34b8ljJWZMdR/qzzxfbZdRHk0Rqctf0Qfw8A6RUqxXzz I/Wa2rP18SD5rk4nuFP3n2Htn7l0CBUtJodVS1dhUlkX+sHit0twgv45PEnktAJ37ITB vZRSouwsFiZj0O7MMILHCkSz46UQdj16vSw93BI6kNOPLOBxdQumOnU6tDa3zOaF64BD lxLsYe8s/dYZTthphf8gCpwPfgDb5L3I85dn2yuIZR3Y8WV5ltAXADEmq+Vc7JTRrRiS NWmA== 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=W4vSJoKjMqMfWKMJRtT8SnK5hGotmFteFKO3vRLVENM=; b=T6S3RhUCsZZXP6E9fga62l+VDSLFywf19LxL7vTTIi4sbaAR9tcTBokV6ubGHcKv9N E29nhxRLkjApln0Ha3bUJQgTO90Bxchxv0UL6CYyw3X9F+ygF4lxTnK5Ch+oj0K0X2ne zqdVoc9yIHS2vfA3nkI7kWkAUXa/U29lPIwoEBDErXWDqa/O3ZX7iFVsYGBM4Oi+s7YU Ho6SrGSjTjCUiy8M/g+5ReFKaI9mXwL1w9oVIKjgcJR/uHFnr30XbmD0c3E2LZX8eCeR jH79/Y3aGtxU7KCMJq790AbUSQc2eDcEq+FWQ5j3hU+UvdxoP0vyLE15wjJU0V8ZfeuO D67w== X-Gm-Message-State: AOAM533hgUYiHMTPd7TJhLjl6o/HqOSPAFWg93SX/FieRcFuKgjVgwFd T2kStvE6UbMrG9bQ+lzLh8MmTKcerugVKEDh6SDDVw== X-Google-Smtp-Source: ABdhPJwSlwcVFSLeWibn/3Xode6wRCCL+r8uttrQBcM5gd5yh0enqj7xWPOi1A0mDtf/Lau6BR3MfxXtzvaU0eUOICU= X-Received: by 2002:a4a:9442:: with SMTP id j2mr1453724ooi.37.1589934534226; Tue, 19 May 2020 17:28:54 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::c29; envelope-from=theophilusx@gmail.com; helo=mail-oo1-xc29.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:250992 Archived-At: --00000000000020f4ac05a6097b88 Content-Type: text/plain; charset="UTF-8" On Tue, 19 May 2020 at 14:01, 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. ]]] > > > > Better in which sense? Do you mean, better for you in maintaining > the > > > package? > > > As explained in another email: better discoverability. Better at > helping > > the users notice the package. > > > Simply including a file in the Emacs distro doesn't do much. > > Do people have any concrete suggestions for how to improve this? > > Is there actually a discoverability problem for GNU ELPA packages? After over 25 years of Emacs use, I think discovering and trying out new packages and features has never been easier. I really don't miss the old days of hunting around various ftp servers trying to find the latest and current version of some library or package. I know for me at least, as soon as I need some new functionality (setting up for a new language, needing to do something new, looking for alternatives etc), or just check out what new feaqtures, packages etc are available, one of the first things I do is M-x list-packages. This gives me a list of all the available packages from all the package archives I have listed. The source (archive) for each package is clearly identified and since I added all the additional archives, I know what the differences is between them. If a package is available in both GNU ELPA and another archive, like MELPA, I will typically select the one from ELPA, because rightly or wrongly, I expect it to be more stable and comply with GNU philosophy. I might later change (as is the case for org because I want both the latest org version and the additional packages from org contrib). The only real issue I see is the apparent confusion within the GNU Emacs project itself regarding ELPA, what role it should play and how it should be maintained. This is based on some of the threads seen in this list. Perhaps the below has already been done and if so, then we just need to make that information more prominent or accessible and point people to this information when questions regarding ELPA arise. Anyway, I think the following might help - Define the rationale and objectives that underpins ELPA. Forget about historical context and focus on current context. - Define what should be and what should not be included in ELPA. This should be based on objective criteria - Define an ELPA custodian responsible for deciding whether a package should or should not be added/removed from ELPA. This custodian should be able to appoint a team of people who can assist. There will probably need to be some appeal process as well, but I'd keep it simple to begin with. - Ensure the custodian is supported and is seen as the 'official voice'. Any ideas, concerns or need for clarification re: policy etc should first be discussed with the ELPA custodian (they may delegate some of the work, but announcements, decisions etc should come from them). Note that this does not mean they are the decision maker or benevolent dictator - they are just the spokesperson and what they say can be take as the official position. - Develop guidelines on when a package or library should be included in core Emacs i.e. is in the Emacs source code distribution and when it should be in ELPA. - Decide if we really need the ability to have some sort of category or split i.e the 'blessed' and 'neutral' packages (I'm not convinced this is a good idea). Some of the above steps will be challenging and likely involve considerable debate and things may evolve and change over time. However, it would at least provide a more consistent base from which to develop and expand. Once this is done, a review of existing ELPA packages and GNU Emacs libraries/packages could be performed to decide if the current split is correct. Some things may need to move from ELPA back to Emacs and vice versa. More importantly, once we have this level of clarity, it should be easier to decide whether there needs to be more done to inform and educate the wider user community regarding emacs lisp archives, the roles they fulfill, address identified discoverability issues, add infrastructure to encourage/support underlying philosophy etc. -- regards, Tim -- Tim Cross --00000000000020f4ac05a6097b88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, 19 May 2020 at 14:01, 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 > > Better in which sense?=C2=A0 Do you mean, better for you i= n maintaining the
=C2=A0 > > package?

=C2=A0 > As explained in another email: better discoverability. Better a= t helping
=C2=A0 > the users notice the package.

=C2=A0 > Simply including a file in the Emacs distro doesn't do much= .

Do people have any concrete suggestions for how to improve this?

=C2=A0
Is there actually a discov= erability problem for GNU ELPA packages? After over 25 years of Emacs use, = I think discovering and trying out new packages and features has never been= easier. I really don't miss the old days of hunting around various ftp= servers trying to find the latest and current version of some library or p= ackage.

I know for me at least, as soon as I = need some new functionality (setting up for a new language, needing to do s= omething new, looking for alternatives etc),=C2=A0 or just check out what n= ew feaqtures, packages etc are available, one of the first things I do is M= -x list-packages. This gives me a list of all the available packages from a= ll the package archives I have listed. The source (archive) for each packag= e is clearly identified and since I added all the additional archives, I kn= ow what the differences is between them. If a package is available in both = GNU ELPA and another archive, like MELPA, I will typically select the one f= rom ELPA, because rightly or wrongly, I expect it to be more stable and com= ply with GNU philosophy. I might later change (as is the case for org becau= se I want both the latest org version and the additional packages from org = contrib).

The only real issue I see is the ap= parent confusion within the GNU Emacs project itself regarding ELPA, what r= ole it should play and how it should be maintained. This is based on some o= f the threads seen in this list. Perhaps the below has already been done an= d if so, then we just need to make that information more prominent or acces= sible and point people to this information when questions regarding ELPA ar= ise. Anyway, I think the following might help

- Define the rationale and objectives that underpins ELPA. Forget about hi= storical context and focus on current context.

- Define what should be and what should not be included in ELPA. This sho= uld be based on objective criteria

- Define a= n ELPA custodian responsible for deciding whether a package should or shoul= d not be added/removed from ELPA. This custodian should be able to appoint = a team of people who can assist. There will probably need to be some appeal= process as well, but I'd keep it simple to begin with.
=
- Ensure the custodian is supported and is seen as the '= official voice'. Any ideas, concerns or need for clarification re: poli= cy etc should first be discussed with the ELPA custodian (they may delegate= some of the work, but announcements, decisions etc should come from them).= Note that this does not mean they are the decision maker or benevolent dic= tator - they are just the spokesperson and what they say can be take as the= official position.

- Develop guidelines on = when a package or library should be included in core Emacs i.e. is in the E= macs source code distribution and when it should be in ELPA.

- Decide if we really need the ability to have some sort of= category or split i.e the 'blessed' and 'neutral' packages= (I'm not convinced this is a good idea).

Some of the above steps will be challenging and likely involve considerabl= e debate and things may evolve and change over time. However, it would at l= east provide a more consistent base from which to develop and expand. Once = this is done, a review of existing ELPA packages and GNU Emacs libraries/pa= ckages could be performed to decide if the current split is correct. Some t= hings may need to move from ELPA back to Emacs and vice versa. More importa= ntly, once we have this level of clarity, it should be easier to decide whe= ther there needs to be more done to inform and educate the wider user commu= nity regarding emacs lisp archives, the roles they fulfill, address identif= ied discoverability issues, add infrastructure to encourage/support underly= ing philosophy etc.


--
regards,

Tim

--
Tim Cross

=
--00000000000020f4ac05a6097b88--