From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs] Date: Mon, 18 May 2020 14:07:07 +0300 Message-ID: References: <35DBF02E-44D7-41E5-A217-7D6EC84ED221@icloud.com> <4e937898-ae46-710a-cbca-e452a1156fa1@yandex.ru> <405FCFAB-30E4-4F98-81DA-3B09933E86D0@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="115783"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: Emacs-devel@gnu.org To: rms@gnu.org, eliz@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 18 13:07:48 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 1jadcZ-000U37-Bi for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 13:07:47 +0200 Original-Received: from localhost ([::1]:40552 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jadcY-0005YQ-DC for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 07:07:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38344) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jadc5-00057d-IO for Emacs-devel@gnu.org; Mon, 18 May 2020 07:07:17 -0400 Original-Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]:40775) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jadc4-0004Bg-9D; Mon, 18 May 2020 07:07:17 -0400 Original-Received: by mail-wm1-x344.google.com with SMTP id n18so5602975wmj.5; Mon, 18 May 2020 04:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5gikwhEMdL3ZcGjT784x3Bm/bl/VZT4MuoGQ6eMpsZ8=; b=Gh+u90mOSQRn/iDirX7Ac9Wjk4U7KaDT6MkuBO4iL3auakD0DcpNIvHPB6xHSBEcYt 8dfIH8kv43A2ldRj3c9U8U746iRphe44X/5seYHzU3+q7ot03jLHItqvzchx1oEdL6w0 Bj+mOggAQwJkonas1+PykTgvn251LA5davIIFVpyddaFKazdvapwB6bsuGFEHlNqcCjO 6NeELCUfHrygjta1Jmp5R2LCcvKq/P/VNTBXjOB5F7fg5hA1fMmzs2HDMtS2A2qnlWJx 1xJ7vW5k21x0aS8/MA5krHMaoxh278KyhhtBma8QD6nWmVMhVZ+oa97lkI3cG/kNtgNP BGsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5gikwhEMdL3ZcGjT784x3Bm/bl/VZT4MuoGQ6eMpsZ8=; b=jYu3W+R+GG6fRb44QyVsKnPh2Myc3Q+CAZTrNJrak4CmOBruYMSgJ3jOeHH2aKfPXg 6Rt17wIFbEghhCdWM3iJNqnwvJ8Oo2xu0SKvj93pPRfSomwWboTKGt+dETV8FqVwlmGH fy35qJOualO4scFRinqdmaE8Y/Lg+meSPgANPkrSN0uyTTQ9yf8UCwCs6PVcpcKmMRib WQ3xzXjvCUTwgZGmOKBX7p4zoceXfR/sNT4qscxnoQ0jVY5xSrYpj28DA7oG5j7vHkug AeGgbvrL7mU7G3xg5DRkHkWs7SCHWTinM5CGpZxHp0B14AX7ld8DqHl2gD4jyKGPbU1H hBVg== X-Gm-Message-State: AOAM531f5p2lnjllFmNmYjOCUibJ+4MpFnA/SefeDLMAWMpFZnkXsFox ckxLxMz5ore4sKi1OIymTGrFqvTs X-Google-Smtp-Source: ABdhPJwBAdaALGaSMcaFu/ezqDR/qDpdrALGPrRVVU2N/ZAl+Ngce+XuQIx0sHvzSAUEkvr2P6//YQ== X-Received: by 2002:a1c:7f86:: with SMTP id a128mr19043995wmd.95.1589800030377; Mon, 18 May 2020 04:07:10 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id p9sm16347635wrj.29.2020.05.18.04.07.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2020 04:07:09 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::344; envelope-from=raaahh@gmail.com; helo=mail-wm1-x344.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: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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:250727 Archived-At: On 18.05.2020 06:49, Richard Stallman wrote: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > I'd say it all depends. We probably aren't going to simply follow what > > the author will be asking for, either. > > > Do they want code review? We could do it once (couldn't we?), but if the > > author wants all the changes reviewed all the time, we would probably do > > that only for most important packages. Ones that will be enabled for > > default, maybe? > > If we are going to continue saying, of GNU ELPA, that "You can trust > it", I think that we need to do some code review for every package in > GNU ELPA. We had better treat serious bugs in GNU ELPA the way we > treat serious bugs in Emacs. I'm all for it, personally. As far as I know, this has only been limited by our developers' free time (or its deficit), and by their general disinterest (seems like). I don't think any package author would really object to an external review, people pointing out serious bugs, etc. (Enforcing commit message format and documentation standards are a somewhat different matter.) > If we want to have two different ways of treating those packages, > we need to show the users which category each package is in. > > The reliable way to do that is to have two archives: one we say you > can trust, and one that provides only a place to distribute them. Personally, I don't know if we really need two archives, or packages we don't "trust". We could somehow annotate packages without copyright assignment, but its lack alone doesn't make a package untrustworthy. > Good names might be "GNU Emacs Exocore" for the ones we review, and > "GNU ELPA" for those we don't. I suggest "Exocore" as meaning "like > the core, but hosted separately." > > Or maybe, GNU ELPA for the ones we review, and Alt-ELPA for what we don't. > > For now, let's call them reviewed and unreviewed. We still could do that, if we find that we don't have enough manpower for reviewing all. > MAYBE it will work well if we get papers for the reviewed packages > but not for the unreviewed. Then the reviewed packages might be > merged into the core, and the unreviewed are ones we don't consider > moving into the core. So if we think a package might be good to put > in the core, we should review it AND get papers for it. Not sure this would be best for the users, but it does make some economical sense.