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: "Write a new package" culture instead of patches? Date: Mon, 18 May 2020 11:55:49 +1000 Message-ID: References: <35DBF02E-44D7-41E5-A217-7D6EC84ED221@icloud.com> <4e937898-ae46-710a-cbca-e452a1156fa1@yandex.ru> <405FCFAB-30E4-4F98-81DA-3B09933E86D0@gnu.org> <207f6196-8df8-0941-b01f-1537c3e080e8@yandex.ru> <2A2E84A7-1737-4BAA-A603-39A328BF44B6@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f9902405a5e276b1" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="27089"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Yuan Fu , Richard Stallman , joostkremers@fastmail.fm, EMACS development team , "Alfred M. Szmidt" , Stefan Kangas , =?UTF-8?B?7KGw7ISx67mI?= , Dmitry Gutov , chad , Eli Zaretskii , Phillip Lord To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 18 03:56: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 1jaV1M-0006v9-0X for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 03:56:48 +0200 Original-Received: from localhost ([::1]:59972 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jaV1L-0005TM-3F for ged-emacs-devel@m.gmane-mx.org; Sun, 17 May 2020 21:56:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56708) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jaV0i-0004t6-Ax for Emacs-devel@gnu.org; Sun, 17 May 2020 21:56:08 -0400 Original-Received: from mail-oi1-x233.google.com ([2607:f8b0:4864:20::233]:39605) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jaV0h-0005zN-8e; Sun, 17 May 2020 21:56:07 -0400 Original-Received: by mail-oi1-x233.google.com with SMTP id s198so7758751oie.6; Sun, 17 May 2020 18:56:01 -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=jgHaGQ5AMj9QVQOhofPpQbi2AV0DLFV7BjpGwIVjhI8=; b=IQeX0+73afAzFqnbmnqHCW2HPcWlapBS2esHvn4lEjAg0olTWlwJoOlwntuxTqVEdz 6GuZbhjnqbAtfBC/kj+qUysBnI8FsPrI5baoes1mstJTxbKbT2Iwlp0m71gDPpVMxaix xM3A2CENh6FZr3nd9OTfElleqysUg+7kNoIZJOb3ZDe7uv8+oTKESkE0BEtQ0wTJl5k4 Ho55NDGbsmPG0980TEN2+ibwisnwvn+rjLHCbl1HcNoWfCYOEPbHhbjbfK9spK/KP1Pj UPu3wry7D3jLuPzXPQ3AbUdIyGGBx7kWTF+1eB5YPgOdDF2OBh9OZCglzjf9qkqtuwCY berg== 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=jgHaGQ5AMj9QVQOhofPpQbi2AV0DLFV7BjpGwIVjhI8=; b=UQRISP9uw2cuqEXLlLmN06kgpMBjathiOuMyPwefm2lP3Ag0SHRlFnLVemwJUI1C5P AcVx0pXMSDaS2ddtefyvH/soEzxjjt5eKPYDQYi8BcdqY9zGfVRk2RsZfioQZosyZlRL 8ceqFjvjNRDYOwpkdC09y9OK1+I7REG1WuANZAgelW4ogWDtOjIVHv5qaJC0GXtIuOqB 83f/R3gf/KifJp2AdfktDkIWV4jKUvOFuQMnm1UwYQfywvbSaxV5x7IPocV62V49oWSf RoVyUYHama/H8IHmrBl+8OmXhwg+UbTq86GHcO5h/QYH8NNBCeQ+bolbc2nIZLayD5fe V1hA== X-Gm-Message-State: AOAM532L6EijOrteTQh/KpRWSKeJvFNB/A4qCWPAyhmFbd+Re/BySR6C sJ0tUqezTYLoEqqoForGG48ThzQgUw0ukvHdVzI= X-Google-Smtp-Source: ABdhPJxDC5yyljRvSxFJigbcwU5AU2FfofcpS5MAaFORStszhpqCXtf5sPS2KuhucJGNT1KlqdaOVLLSicIO30/AenA= X-Received: by 2002:aca:7503:: with SMTP id q3mr9863828oic.47.1589766960810; Sun, 17 May 2020 18:56:00 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::233; envelope-from=theophilusx@gmail.com; helo=mail-oi1-x233.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:250690 Archived-At: --000000000000f9902405a5e276b1 Content-Type: text/plain; charset="UTF-8" On Mon, 18 May 2020 at 09:51, Stefan Monnier wrote: > Integration is hard. So yes, people prefer to make new packages, this > way whoever likes it can install it and those who don't like it won't > be affected. > > I don't think it's necessarily a problem. It just means integration has > to be done separately. Nowadays it's done at various places by > various people. It's done here on emacs-devel, of course, but it's also > done in all the "Emacs distributions" like Doom, Spacemacs, ... > > Having several distributions makes it easier, because the affected users > can go elsewhere when they're not happy, so while emacs-devel is quite > conservative, other distributions can be more daring. > > > +1. I don't think this is a big issue. There are pros/cons on both sides and neither has significant advantage over the other. Personally, I like having ELPA and Emacs be a minimal core which I can extend and add via packages to get the environment I want. This tends to keep the core stuff smaller and less complex, leading to less bugs and easier maintenance. The downside is that when things in core ELPA/Emacs are updated, add on packages may be broken until the author/maintainer gets around to updating them. As someone who has/does maintain code with a free and/or open source license, I know from experience that contributions, enhancements and extensions can be a real problem. I have one library which has become much harder to maintain because I accepted enhancements from others. While those enhancements were well written, now that they are part of my package, I'm left to maintain them even though they were not enhancements I needed or wanted. They have made my package harder to maintain and consequently, takes time I really don't have. However, because it is now part of my package, I either have to maintain it or remove it and the associated functionality, potentially frusrating some users. In hindsight, I wish these enhancements had been added as separate packages that extended my lib. I am now much less willing to accept pull requests that add new features or functionality. I think org-mode is probably a good example. There are many extensions and enhancements to org-mode and many of them are separate packages. There are still some things in org-mode core which probably should be separate packages. The majority of these separate extensions/enhancements are not things I'm interested in, so I don't want them installed. I'm pleased all these extensions have not been added into the core as if they did, development of core functionality would slow down and would likely become more complex and buggy. The downside is that when a new org-mode release occurs some of the add on packages I use may be broken for a time. However, perhaps that doesn't matter or perhaps I may choose to pin the version of org-mode to one where the add-on does work. If an add-on becomes really popular and used by a majority of org-mode users, then perhaps it becomes a good candidate for inclusion into org-mode or the functionality it represents can be added to org-mode (negating the need for the add-on, but possibly with a different implementation). -- regards, Tim -- Tim Cross --000000000000f9902405a5e276b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, 18 May 2020 at 09:51, Stefan = Monnier <monnier@iro.umontre= al.ca> wrote:
Integration is hard.=C2=A0 So yes, people prefer to make new packages,= this
way whoever likes it can install it and those who don't like it won'= ;t
be affected.

I don't think it's necessarily a problem.=C2=A0 It just means integ= ration has
to be done separately.=C2=A0 Nowadays it's done at various places by various people.=C2=A0 It's done here on emacs-devel, of course, but it&= #39;s also
done in all the "Emacs distributions" like Doom, Spacemacs, ...
Having several distributions makes it easier, because the affected users can go elsewhere when they're not happy, so while emacs-devel is quite<= br> conservative, other distributions can be more daring.


+1. I don't think this is a b= ig issue. There are pros/cons on both sides and neither has significant adv= antage over the other. Personally, I like having ELPA and Emacs be a minima= l core which I can extend and add via packages to get the environment I wan= t. This tends to keep the core stuff smaller and less complex, leading to l= ess bugs and easier maintenance. The downside is that when things in core E= LPA/Emacs are updated, add on packages may be broken until the author/maint= ainer gets around to updating them.

As someon= e who has/does maintain code with a free and/or open source license, I know= from experience that contributions, enhancements and extensions can be a r= eal problem. I have one library which has become much harder to maintain be= cause I accepted enhancements from others. While those enhancements were we= ll written, now that they are part of my package, I'm left to maintain = them even though they were not enhancements I needed or wanted. They have m= ade my package harder to maintain and consequently, takes time I really don= 't have. However, because it is now part of my package, I either have t= o maintain it or remove it and the associated functionality, potentially fr= usrating some users. In hindsight, I wish these enhancements had been added= as separate packages that extended my lib.=C2=A0 I am now much less willin= g to accept pull requests that add new features or functionality.

I think org-mode is probably a good example. There are= many extensions and enhancements to org-mode and many of them are separate= packages. There are still some things in org-mode core which probably shou= ld be separate packages. The majority of these separate extensions/enhancem= ents are not things I'm interested in, so I don't want them install= ed. I'm pleased all these extensions have not been added into the core = as if they did, development of core functionality would slow down and would= likely become more complex and buggy. The downside is that when a new org-= mode release occurs some of the add on packages I use may be broken for a t= ime. However, perhaps that doesn't matter or perhaps I may choose to pi= n the version of org-mode to one where the add-on does work. If an add-on b= ecomes really popular and used by a majority of org-mode users, then perhap= s it becomes a good candidate for inclusion into org-mode or the functional= ity it represents can be added to org-mode (negating the need for the add-o= n, but possibly with a different implementation).

=
--
regards,

Tim

--
Ti= m Cross

--000000000000f9902405a5e276b1--