Re: GNU ELPA package discoverability

[Tim Cross <theophilusx@gmail.com>]

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

On Wed, 27 May 2020 at 00:42, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Tim Cross <theophilusx@gmail.com>
> > Date: Tue, 26 May 2020 10:24:01 +1000
> > Cc: Richard Stallman <rms@gnu.org>, Emacs developers <
> Emacs-devel@gnu.org>
> >
> >  So basically what's missing is the write access issue.  That should be
> >  a single sentence: we don't have ELPA write access, only access to the
> >  entire Emacs repository, so they need to request membership in the
> >  Emacs project.
> >
> > That would certainly be a good start. However, is that a maintainable
> approach.
>
> That's what we have now.  IMO information for contributors should
> reflect the present state of affairs.
>

Except it isn't. There is nothing in the README about how to obtain
write/push rights to the repository or that it is the same rights as you
need to add code to the Emacs repository. It also states that if you don't
have the necessary rights, someone will do it all for you, but with no
indication on how to find that someone or provide them with the code. In a
single file package, I guess sending the file to emacs-devel might be
sufficient, but for larger projects that won't work. Relying on 'someone'
to do the work is a vague proposition and will often result in a rather
slow process.

>
> > Assume we are successful in getting more packages into ELPA, increasing
> the discoverability of appropriate
> > packages without the need to add repositories like MELPA. Will all of
> those developers be entitled to write
> > access to the GNU git repository? What about Richard's proposed
> non-copyrighted repository? Perhaps now
> > is the right time to look at the architecture and consider breaking off
> ELPA into a separate authentication
> > realm?
>
> If and when the situation changes, we will update the information.  It
> is not useful to worry about issues that didn't yet materialize, and
> are anybody's guess when they will.
>

I disagree with this approach. All it does is maintain the status quo.

As demonstrated by this thread and others, the current situation is not
working. GNU ELPA has relatively few packages. A far larger number of
packages which could be in a GNU repository are being provided via MELPA,
which also includes packages that do not support the philosophy and goals
of the GNU project. Richard and others are talking about creating an
additional repository which has packages that are philosophically aligned
with the GNU project, but which do not assign copyright to the FSF.  All in
an attempt to reduce the need for users to add a repository which does not
promote core GNU project objectives and to make more appropriate packages
easily to discover without the need to add 3rd party repositories. To
achieve this goal, we need to actively change the situation. A passive 'we
will change it when it is needed' will never work.  If we want people to
consider ELPA as the repository to use, we need to facilitate their ability
to do that.  To make it maintainable, we need to design a solution which
minimises the time burden on those few volunteers prepared to put in the
effort. Improvements and change is something which needs to be driven.

>
> >  > Questions about what can/should go into ELPA, what should be included
> in Emacs
> >  > core and what cannot go into ELPA are not addressed at all (the
> README is
> >  > probably not the right place for this information)
> >
> >  It's quite expected that this is not described, because we are still
> >  arguing about that.
> >
> > I think this is an important argument to resolve in order to address the
> other issues that have been raised,
> > such as improving package discoverability or implementation of a
> non-copyrights assigned repository. ELPA
> > has existed for quite some time now and we still don't have a clear
> definition of what should go into it. How
> > long do we need to argue about it before making a decision? Is anything
> being recorded regarding the
> > various arguments or is it just endless unconnected threads in the mail
> list? In other words, how far have we
> > moved towards a consensus?
>
> I don't know.  A proposal was put on the table, but some of the
> important stakeholders didn't yet respond to it.


How long ago? Perhaps that proposal needs to be res erected? Any proposal
which is just thrown out into the ether is rarely going to achieve
anything. It usually needs a champion that will drive the proposal until an
eventual resolution (which may be for or against - either are valid and
provide a means to move forward).

Do you have a copy of this proposal and are you able to share it?


> If you know what
> that means and can predict whether, when and how a decision will be
> reached, maybe you can advise me which shares to buy to become rich.
>

Maybe I can. My portfolio has done nicely. In fact, it is because of it I
have the time to spend contributing to various open source projects.

-- 
regards,

Tim

--
Tim Cross

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