From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Corwin Brust Newsgroups: gmane.emacs.erc.general,gmane.emacs.devel Subject: Re: [ELPA] New package: ERC Date: Tue, 21 Sep 2021 00:31:41 -0500 Message-ID: References: <87tuih3jfq.fsf@gnu.org> <871r5i941n.fsf@zoho.eu> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3165"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs developers To: Emanuel Berg , emacs-erc@gnu.org Original-X-From: emacs-erc-bounces+sf-erc-help=m.gmane-mx.org@gnu.org Tue Sep 21 07:32:12 2021 Return-path: Envelope-to: sf-erc-help@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 1mSYO3-0000bH-NV for sf-erc-help@m.gmane-mx.org; Tue, 21 Sep 2021 07:32:11 +0200 Original-Received: from localhost ([::1]:59836 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mSYO1-0003Tr-OV for sf-erc-help@m.gmane-mx.org; Tue, 21 Sep 2021 01:32:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39558) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSYNr-0003Ro-54; Tue, 21 Sep 2021 01:31:59 -0400 Original-Received: from mail-ed1-f52.google.com ([209.85.208.52]:45701) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mSYNn-0000rk-8n; Tue, 21 Sep 2021 01:31:58 -0400 Original-Received: by mail-ed1-f52.google.com with SMTP id c22so69618807edn.12; Mon, 20 Sep 2021 22:31:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VJe4xi9HiSm3SwCeOuKdSSfY8VfgaMEHNo5D3Ch5BRA=; b=2S4mWPsYN0nvaFiFUrNYvcpRPgDoQYI6oA15yoTuz3hiiUwjyj889kYlC0kRo3Pq3r LnFfwrn690NocSEJq7y/FLwKUqBUMow4M6d+uKHVCyVtV74tzbNjoQ87iFbt5v0qDRoy nNEJLphb4XS+qb2nvJuUiIGz7Jl8BYvp1+9ypT45E4BfdkoTyU4UzZIsdwoLtR7ouTTS sHqc0ETjC4LJOxKvECg4ZTQ6RRKsYr/RFMGwfgE0L/6YGfwy8fBA1d7Hz19zGagD1Gby vgavl4dZVMzFIsYNdXdq15oZ5kPts72slfEEclYyA35sAi+C80+88HqSFhQjEhsYyqBq 31Qg== X-Gm-Message-State: AOAM531Akqh5uMux9GKMtVSiKyY6ClIQX+LXrXLiI/9rYiPx6aI8/Xh8 qbUISimX6CIuKLvLXZoGhNVAzcemoEpt0kXGyADoDGqh X-Google-Smtp-Source: ABdhPJzq9KS2PGuUfGHirEha+1ijNhr2FsjCnWguPZP1NFk45PNrMX+A4cwgHR0NGUSiAX0RvOR+xNVdfGPpijMRrbo= X-Received: by 2002:a17:906:4ad1:: with SMTP id u17mr21323250ejt.407.1632202311213; Mon, 20 Sep 2021 22:31:51 -0700 (PDT) In-Reply-To: <871r5i941n.fsf@zoho.eu> Received-SPF: pass client-ip=209.85.208.52; envelope-from=mplscorwin@gmail.com; helo=mail-ed1-f52.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-erc@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General discussion about ERC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-erc-bounces+sf-erc-help=m.gmane-mx.org@gnu.org Original-Sender: "emacs-erc" Xref: news.gmane.io gmane.emacs.erc.general:1596 gmane.emacs.devel:275194 Archived-At: Hi Emanuel! On Mon, Sep 20, 2021 at 7:16 PM Emanuel Berg via General discussion about ERC wrote: > > Amin Bandali wrote: > > > It's about time we added ERC to GNU ELPA. :) > > I'm obviously out of the loop here but isn't ERC shipped > with/in vanilla Emacs already? > > So why would one put it in ELPA (no disrespect)? > I think there are several reasons why it makes sense to place a core package also in ELPA. In this case, I see a bunch of benefits; I find these three most exciting: 1. Getting new ERC versions from ELPA means easier, more rapid access to fixes and new features. Currently, our options for updating ERC are a) building Emacs from the main development branch (not everyone finds this easy), b) merging elisp from that branch (when that works, the ERC that will come with Emacs 28 will have need of at least Emacs 27, IIUC), or c) waiting for new Emacs releases to be cut, publishing the accumulated ERC changes since the last Emacs release. My sense is that this last is most common, at present though I won't claim I have any data to support that theory ;) 2. Releasing ERC more frequently can improve ERC's quality. Currently, we release ERC once per Emacs version. As ERC starts to release more frequently than Emacs people will be able to experiment with and provide feedback and bug reports on each. That additional testing should (eventually) lead to more stability from the ERC that ships with each Emacs release. 3. Shorter development cycles will make hacking on ERC more fun. Development is more exciting the more people who, and the more rapidly people do see our changes. By releasing ERC more often (vs Emacs releases), we make it easier for ERC to be a "proving ground". This can help increase the desire of others to try contributing to ERC and thereby gain feedback, skill, and confidence, and get encouraged to contribute to other ways, such as developing contributions to other parts of Emacs. More frequent releases can also make ERC more useful for experimenting with new approaches/techniques that we (aspiring) ERC hackers consider may be useful in other parts of Emacs (if they work, people like them, they don't turn out to be difficult to maintain, ...). Cheers! -- Corwin corwin@bru.st