emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU ELPA package discoverability


From: Tim Cross
Subject: Re: GNU ELPA package discoverability
Date: Wed, 27 May 2020 11:06:37 +1000

On Wed, 27 May 2020 at 00:42, Eli Zaretskii <address@hidden> wrote:
> From: Tim Cross <address@hidden>
> Date: Tue, 26 May 2020 10:24:01 +1000
> Cc: Richard Stallman <address@hidden>, Emacs developers <address@hidden>
>
>  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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]