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: Tue, 26 May 2020 10:24:01 +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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000006ae5a705a6821da0" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="126055"; 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 Tue May 26 02:24:51 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 1jdNOl-000Whi-Bv for ged-emacs-devel@m.gmane-mx.org; Tue, 26 May 2020 02:24:51 +0200 Original-Received: from localhost ([::1]:57096 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdNOk-0007LM-AO for ged-emacs-devel@m.gmane-mx.org; Mon, 25 May 2020 20:24:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52206) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdNOC-0006uM-9J for Emacs-devel@gnu.org; Mon, 25 May 2020 20:24:16 -0400 Original-Received: from mail-oi1-x232.google.com ([2607:f8b0:4864:20::232]:39976) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jdNOB-0006Kh-9l; Mon, 25 May 2020 20:24:15 -0400 Original-Received: by mail-oi1-x232.google.com with SMTP id v128so17264938oia.7; Mon, 25 May 2020 17:24:14 -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=MDHxwZVOzWj+COGHmwIIvRVpF+Y8USTk9l5Jc3RB8aw=; b=LiwzF4FFUaNWmAZF1coFrSZroo7WUPc6szojtg1cQVykHdCHVrQkY3AKo/fJteXtO1 woZyXX2936UEe/7kONk47eAgCu4eYiB3RhBw/CeKWRuY2nhal2PpFN3nOXb5XLOztBAT +cmx5hd8J/aEw0ujcVwbtjHOOPGuLDwq0qf5sIQ6uFm4uiAwctbFu/C0xtjRR0aZG5uy en3dw6vqTFtTvDzvIPcCD+X8CeSsETqesG+6RMX+2rUzmRfPHFGPUFvLx5x0ayQRvcV2 aS941W4BP9coRNwluecIW6S9Z3uT+5UjvytshY5rgml0LSAlTx1CRgozS/1/A9ktOE/G lyoA== 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=MDHxwZVOzWj+COGHmwIIvRVpF+Y8USTk9l5Jc3RB8aw=; b=LPs+YQo12DFmVWLlTqjGZivJfC4t0e6aWo7NVROWy46Ozln0FQvEaDxQtmaaFPV8EM 2b8tWc/Pndw/6/vcJUgaQ9ltO39ImR3H3bWFdtvBU76kQ8y3u/xF/obCmKKXB8/dL5u1 +zD1mPkx0dLdiEFkCYlNRtr+KUUz5QeDtMgq/j+t1HcXeE5HIt3694o3llio3s0BoAJs J1CtM2VBn2idVeMtzJH9oEkaujPj/UUSXAbz38GQHp1sPvqlOkoEC6pmOa6o8a3OvrHP u0lf+J3U8FsUT+7+W9tHh3Foh3GgGBJoy8ELXLbpygA3xOXDwWKpyLGVdRI2hZDTBpAJ KsMA== X-Gm-Message-State: AOAM531A/mIGnxZMvnnRpVQ/2HNxWbPGbuPUqSE1e7m9qjN+uMcY5xsq 0m3yAWfna34/KNcyVg7IYRNCkY97ob25N7rzGFl7fA== X-Google-Smtp-Source: ABdhPJxcehmtaAi24RZVqvBU3j0Ym0twwgPvXwVdK0ENftTJuPz2BKYtcVJo1fZFhan3B7mJhI1y0ZUfezf9r3IRZj4= X-Received: by 2002:aca:58c5:: with SMTP id m188mr1639848oib.171.1590452653056; Mon, 25 May 2020 17:24:13 -0700 (PDT) In-Reply-To: <831rn8vy6o.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::232; envelope-from=theophilusx@gmail.com; helo=mail-oi1-x232.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:251403 Archived-At: --0000000000006ae5a705a6821da0 Content-Type: text/plain; charset="UTF-8" On Tue, 26 May 2020 at 01:20, Eli Zaretskii wrote: > > From: Tim Cross > > Date: Mon, 25 May 2020 10:21:47 +1000 > > Cc: Richard Stallman , Emacs developers < > Emacs-devel@gnu.org> > > > > Aren't these questions answered in ELPA's README? > > > > No it doesn't. It does answer some of them, but not others (and is > probably not > > the right place to answer some of them). > > > > The ELPA README is certainly a start with respect to basic workflow. > Information > > which it lacks that a new developer may want to know or which needs > > clarification includes > > > > - Who can get push permission to the ELPA git repository? > > - How do you request push permission? > > - The README is a little weak on process when you don't have push > permission > > - The instructions re: email to emacs-devel for package developers who > do not > > have push permission does not indicate how to provide the package > > sources/updates. It says that someone will push it for you, but if you > > don't have push permission to the git repo, how do you get your code > in there > > to begin with? > > 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. 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? > > > 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? -- regards, Tim -- Tim Cross --0000000000006ae5a705a6821da0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, 26 May 2020 at 01:20, Eli Zar= etskii <eliz@gnu.org> wrote:
<= /div>
> From: Tim Cross= <theophilusx= @gmail.com>
> Date: Mon, 25 May 2020 10:21:47 +1000
> Cc: Richard Stallman <rms@gnu.org>, Emacs developers <Emacs-devel@gnu.org>
>
>=C2=A0 Aren't these questions answered in ELPA's README?
>
> No it doesn't. It does answer some of them, but not others (and is= probably not
> the right place to answer some of them).
>
> The ELPA README is certainly a start with respect to basic workflow. I= nformation
> which it lacks that a new developer may want to know or which needs > clarification includes
>
> - Who can get push permission to the ELPA git repository?
> - How do you request push permission?
> - The README is a little weak on process when you don't have push = permission
> - The instructions re: email to emacs-devel for package developers who= do not
>=C2=A0 =C2=A0have push permission does not indicate how to provide the = package
>=C2=A0 =C2=A0sources/updates. It says that someone will push it for you= , but if you
>=C2=A0 =C2=A0don't have push permission to the git repo, how do you= get your code in there
>=C2=A0 =C2=A0to begin with?

So basically what's missing is the write access issue.=C2=A0 That shoul= d be
a single sentence: we don't have ELPA write access, only access to the<= br> 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.=C2=A0
Assume we are successful in getting more packages into ELPA, in= creasing the discoverability of appropriate packages without the need to ad= d repositories like MELPA. Will all of those developers be entitled to writ= e access to the GNU git repository? What about Richard's proposed non-c= opyrighted repository? Perhaps now is the right time to look at the archite= cture and consider breaking off ELPA into a separate authentication realm?= =C2=A0

> 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 argu= ment to resolve in order to address the other issues that have been raised,= such as improving package discoverability or implementation of a non-copyr= ights 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 r= ecorded regarding the various arguments or is it just endless unconnected t= hreads in the mail list? In other words, how far have we moved towards a co= nsensus?

--
regards,

Tim
<= br>
--
Tim Cross

--0000000000006ae5a705a6821da0--