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, 27 May 2020 11:06:37 +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> <83blmdxus4.fsf@gnu.org> <831rn8vy6o.fsf@gnu.org> <83lflevju7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000009ddb2d05a696d3ba" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="40088"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Stallman , Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 27 03:07:38 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 1jdkXg-000AKn-Os for ged-emacs-devel@m.gmane-mx.org; Wed, 27 May 2020 03:07:36 +0200 Original-Received: from localhost ([::1]:54076 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdkXf-0000Nw-Q1 for ged-emacs-devel@m.gmane-mx.org; Tue, 26 May 2020 21:07:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38738) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdkX2-0008C1-5S for Emacs-devel@gnu.org; Tue, 26 May 2020 21:06:56 -0400 Original-Received: from mail-ot1-x32d.google.com ([2607:f8b0:4864:20::32d]:41011) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jdkX0-00026x-UH; Tue, 26 May 2020 21:06:55 -0400 Original-Received: by mail-ot1-x32d.google.com with SMTP id 63so17948618oto.8; Tue, 26 May 2020 18:06:50 -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=sja49tiNwQqFMqKNav3/nF+xJKxcysvG4gOeuz7bEcg=; b=aL6U7MbfYKGBv7rnqtZZI6Bx9dH2tmRhXU3MAXuTy7LQXbiV+mNp/NuMFH89/Q2v3b a4tGYHgJaTvLs/lvPxh5nFs0Zqg6Gad40ggtM42Y5mYDh4ELsH3zhiTNUVdaIzI/M/bZ vQ3uJJ6gzkxpTgYN/HBvqlWxOs1NIjfbpqQy6bVAfIDJn0AHf7fromLLxOgpL2a57RUY wy46YutJLj3FePHJCMA/SCuob3lLIDTX3uxyKscF+wjLIf+dp2elTCB7UNuM6T2iB55q qysaKiqi+mAcq3DZJLHyM8E+RLRVchvoF4UQyClIvjbkrptBp97QM79fXD8g0C1dgQdp +g7Q== 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=sja49tiNwQqFMqKNav3/nF+xJKxcysvG4gOeuz7bEcg=; b=ORyGnL85Az6CcgVPVa4SQh/hjCp161EOrBWcrmLynv6LyTjF+dS3+AgGWO5tGJxfNp nxYmpnuedJjBhuuNZcCcSOw/uN03bcMhoRYBEIogT3f+ERBDlk6ONvo/t/jmMqwrxUuk 3fbRJYq2UfZlElcWXIIxuBQQUAYmIUVC3o67/5zVlkZ7DxPHHTV4HfiekfAheaFXu0UQ I49fgRtB0cAWc7cZyzeVGRmPTvrjuIbbRRhUayu/+AHSfyfAkKGNbz/K0Pbqrf2DI4Py 1IrBYRsVpci1JUwcRQc0I36Zhne0VcxNlVLv6tyR12MGGI2Sn2H7Sj6rqqWu6U9czd3O +//w== X-Gm-Message-State: AOAM532y7NxwqXa01M95LkOmjz8X1TOn3DkMJ68eXIO1jieeuqstBWry cmMSYg0QdH2FZN76watNUxbmaV9eERSG0251ENK0/g== X-Google-Smtp-Source: ABdhPJzPnzC2+rzYwcBfYvYdFHr+rqRDP02W8ulhOTb53IpfsQh7MKmrfJi9R3A9dWFpZfabj5xK9Ywur2YpNFeLa3E= X-Received: by 2002:a05:6830:11c6:: with SMTP id v6mr2713356otq.235.1590541609195; Tue, 26 May 2020 18:06:49 -0700 (PDT) In-Reply-To: <83lflevju7.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::32d; envelope-from=theophilusx@gmail.com; helo=mail-ot1-x32d.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:251483 Archived-At: --0000000000009ddb2d05a696d3ba Content-Type: text/plain; charset="UTF-8" On Wed, 27 May 2020 at 00:42, Eli Zaretskii wrote: > > From: Tim Cross > > Date: Tue, 26 May 2020 10:24:01 +1000 > > Cc: Richard Stallman , 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 --0000000000009ddb2d05a696d3ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 27 May 2020 at 00:42, Eli Zaretsk= ii <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>
>
>=C2=A0 So basically what's missing is the write access issue.=C2=A0= That should be
>=C2=A0 a single sentence: we don't have ELPA write access, only acc= ess to the
>=C2=A0 entire Emacs repository, so they need to request membership in t= he
>=C2=A0 Emacs project.
>
> That would certainly be a good start. However, is that a maintainable = approach.

That's what we have now.=C2=A0 IMO information for contributors should<= br> reflect the present state of affairs.

E= xcept it isn't. There is nothing in the README about how to obtain writ= e/push rights to the repository or that it is the same rights as you need t= o add code to the Emacs repository. It also states that if you don't ha= ve the necessary rights, someone will do it all for you, but with no indica= tion 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 slo= w process.=C2=A0

> Assume we are successful in getting more packages into ELPA, increasin= g 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 no= n-copyrighted repository? Perhaps now
> is the right time to look at the architecture and consider breaking of= f ELPA into a separate authentication
> realm?

If and when the situation changes, we will update the information.=C2=A0 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.=C2= =A0

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 ph= ilosophy and goals of the GNU project. Richard and others are talking about= creating an additional repository which has packages that are philosophica= lly aligned with the GNU project, but which do not assign copyright to the = FSF.=C2=A0 All in an attempt to reduce the need for users to add a reposito= ry which does not promote core GNU project objectives and to make more appr= opriate packages easily to discover without the need to add 3rd party repos= itories. To achieve this goal, we need to actively change the situation. A = passive 'we will change it when it is needed' will never work.=C2= =A0 If we want people to consider ELPA as the repository to use, we need to= facilitate their ability to do that.=C2=A0 To make it maintainable, we nee= d to design a solution which minimises the time burden on those few volunte= ers prepared to put in the effort. Improvements and change is something whi= ch needs to be driven.=C2=A0

>=C2=A0 > Questions about what can/should go into ELPA, what should b= e included in Emacs
>=C2=A0 > core and what cannot go into ELPA are not addressed at all = (the README is
>=C2=A0 > probably not the right place for this information)
>
>=C2=A0 It's quite expected that this is not described, because we a= re still
>=C2=A0 arguing about that.
>
> I think this is an important argument to resolve in order to address t= he other issues that have been raised,
> such as improving package discoverability or implementation of a non-c= opyrights assigned repository. ELPA
> has existed for quite some time now and we still don't have a clea= r definition of what should go into it. How
> long do we need to argue about it before making a decision? Is anythin= g being recorded regarding the
> various arguments or is it just endless unconnected threads in the mai= l list? In other words, how far have we
> moved towards a consensus?

I don't know.=C2=A0 A proposal was put on the table, but some of the important stakeholders didn't yet respond to it.=C2=A0

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 a= chieve anything. It usually needs a champion that will drive the proposal u= ntil an eventual resolution (which may be for or against - either are valid= and provide a means to move forward).=C2=A0

Do yo= u have a copy of this proposal and are you able to share it?
=C2= =A0
If you know wha= t
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 var= ious open source projects.=C2=A0

--
regards,

Tim

--
Tim Cross

--0000000000009ddb2d05a696d3ba--