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: Why are so many great packages not trying to get included in GNU Emacs? Date: Fri, 24 Apr 2020 09:57:22 +1000 Message-ID: References: <9mmFgzvrBwjt_n_VJyaJdXINraNi5HsGpwq-0MLeKiJA7kG2BQA4uywrzjyz7lpRS0OZDpjEi8lspOKYUA7P_QsODsDew_8nbH960G55fmY=@protonmail.com> <97DA7804-F647-4A1D-B8E0-AFFE7A324C64@gmail.com> <87d07xamrg.fsf@ericabrahamsen.net> <878silajdl.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000002b554705a3fe0344" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="36927"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Yuan Fu , Emacs developers , Stefan Monnier , ndame To: Eric Abrahamsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 24 01:58:46 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 1jRljy-0009VY-0x for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Apr 2020 01:58:46 +0200 Original-Received: from localhost ([::1]:45588 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRljx-00074w-1w for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Apr 2020 19:58:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51646) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRlis-0005vU-CH for emacs-devel@gnu.org; Thu, 23 Apr 2020 19:57:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jRlip-0008Tc-OI for emacs-devel@gnu.org; Thu, 23 Apr 2020 19:57:37 -0400 Original-Received: from mail-ot1-x32b.google.com ([2607:f8b0:4864:20::32b]:44533) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jRlip-0008OF-4p for emacs-devel@gnu.org; Thu, 23 Apr 2020 19:57:35 -0400 Original-Received: by mail-ot1-x32b.google.com with SMTP id j4so9388592otr.11 for ; Thu, 23 Apr 2020 16:57:34 -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=WSkrbGdTZwFvuta9fe8Vmip7BDOziicFXCZg9URXl9s=; b=CFarSdEJvLzPqwg/c4hl7b0gxVtOpllo1ZfrauU4ODvFBcKKmnFNHoGAPWf5P5ukZ7 o8gt/pbRP3XP4WRKW/r2mKZryCwMbY3iUUbjp9vohRJgGJsUWzPAatwq2Up1f+JPt02G YoLn/TyNGV90ZI7ohhnrrIQv/C28B+uBBf5RscV+SI95qnauy7+1baizbC0U6KEEsM0E fHiRlTXH5UZYxTbBAqS+3n0fH16cRcfSYFabr6EK6m4a/9R+K/wMqf5YikfT0Oame7RD kymznik8bSm0EV+msg52cIuIdF3GQ0/qSsbrRkOzs30Tab5OMiwYGn1aBR17+TesP3uC NEBw== 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=WSkrbGdTZwFvuta9fe8Vmip7BDOziicFXCZg9URXl9s=; b=oDtb0hXGAXaV+Sdav3HT40F3hjn+Qgdd5x37MRFPn8iiU2SwODJxXlylNMrHafuaXU bBsJIBcW2dTKLul2aWvhPOK8FS3NbvVYagKfBzZK+Tq3DjDp7WT/hEPrmg+2cm3uSTOw IV8hAlTEjNWLPsR8qt4GofGm6m2ZPIXisg76jA4vH6kUDLhAomub5l8uH3N53LuBcncQ 5sxKxnyM49zQUEiyaPL33CHNqW+4CcYFTjoyJVYfjRwGtO1VK+UzKzIgNkbZxf2aqN28 DlOFfMBCzCi2G7qPNOcJ9HgfHGF8KV449k2Ekss+ze+v3eYs9Ui9QXzKt6nZUR44Smuo hwjw== X-Gm-Message-State: AGi0PubCBDvo6DAcCQBx9+rvNv/djWHmuchrCK+gIOv/BwU+QYGBJ4xR sSNu1DGGaoZhbx5prY8+zXIZ4Hhxl/O5+w3oJTI= X-Google-Smtp-Source: APiQypI3TgA4B8U9z7g5zQO+40SlW8w7573sKlugPm3IIodD6szUfqDK7sfdehhFBTnFAe6hqHaXB9yWMpr9sEJlB3Q= X-Received: by 2002:a9d:1786:: with SMTP id j6mr5326414otj.235.1587686253744; Thu, 23 Apr 2020 16:57:33 -0700 (PDT) In-Reply-To: <878silajdl.fsf@ericabrahamsen.net> Received-SPF: pass client-ip=2607:f8b0:4864:20::32b; envelope-from=theophilusx@gmail.com; helo=mail-ot1-x32b.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2607:f8b0:4864:20::32b 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:247645 Archived-At: --0000000000002b554705a3fe0344 Content-Type: text/plain; charset="UTF-8" I think a pull model wold actually be more secure and less maintenance. It would mean that the contents of ELPA is 100% under the control of GNU. You would have fewer access credentials to manage and would eliminate the risk associated with external people and their management of their access credentials. If wanted, you could also add processes to do any verification tasks e.g. has tests, documentation, no large commits from people without copyright assignment, code quality whatever. On Fri, 24 Apr 2020 at 09:12, Eric Abrahamsen wrote: > Stefan Monnier writes: > > >> I think it could be even simpler than that: ELPA is built every 24 hours > >> right now. If we just registered external repos with ELPA, part of the > >> build process could be pulling from those repos automatically, once per > >> day. Package authors already have a mechanism for manually triggering a > >> release: incrementing the package version number. There's no harm in > >> ELPA bringing in new commits from the externals, if the author is still > >> in control of when a new version is released. > > > > I think it's important that we don't "pull" from "random" places like > > Github repositories. More specifically, the "push to elpa.git" serves > > as a confirmation that someone thinks this code is appropriate for > > elpa.git (typically the concern being copyright). > > It doesn't seem much more random to say "we're adding your repo URL to > our list of approved ELPA pull-sources" than to say "you're now free to > push whatever you like", does it? An ELPA administrator still has to > make that explicit decision to add the URL, so there's still a level of > approval? > > -- regards, Tim -- Tim Cross --0000000000002b554705a3fe0344 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think a pull model wold actually be more secure and less= maintenance. It would mean that the contents of ELPA is 100% under the con= trol of GNU. You would have fewer access credentials to manage and would el= iminate the risk associated with external people and their management of th= eir access credentials. If wanted, you could also add processes to do any v= erification tasks e.g. has tests, documentation, no large commits from peop= le without copyright assignment, code quality whatever.

On Fri, 24 Apr = 2020 at 09:12, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I think it could be even simpler than that: ELPA is built every 24= hours
>> right now. If we just registered external repos with ELPA, part of= the
>> build process could be pulling from those repos automatically, onc= e per
>> day. Package authors already have a mechanism for manually trigger= ing a
>> release: incrementing the package version number. There's no h= arm in
>> ELPA bringing in new commits from the externals, if the author is = still
>> in control of when a new version is released.
>
> I think it's important that we don't "pull" from &qu= ot;random" places like
> Github repositories.=C2=A0 More specifically, the "push to elpa.g= it" serves
> as a confirmation that someone thinks this code is appropriate for
> elpa.git (typically the concern being copyright).

It doesn't seem much more random to say "we're adding your rep= o URL to
our list of approved ELPA pull-sources" than to say "you're n= ow free to
push whatever you like", does it? An ELPA administrator still has to make that explicit decision to add the URL, so there's still a level of=
approval?



--
regards,

Tim=

--
Tim Cross

--0000000000002b554705a3fe0344--