Re: GNU ELPA package discoverability

[Tim Cross <theophilusx@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4401 bytes --]

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    ]]]
> [[[ 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

[-- Attachment #2: Type: text/html, Size: 5284 bytes --]