From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: Imports / inclusion of s.el into Emacs Date: Sat, 2 May 2020 02:07:35 +0200 Message-ID: References: <266155d4-f9c0-8ed3-8df5-32feea171076@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="96020"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Philippe Vaucher , Emacs developers , Stefan Monnier , Dmitry Gutov To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 02 02:08:26 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 1jUfhh-000OuM-Vj for ged-emacs-devel@m.gmane-mx.org; Sat, 02 May 2020 02:08:25 +0200 Original-Received: from localhost ([::1]:54530 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUfhh-0003K8-1p for ged-emacs-devel@m.gmane-mx.org; Fri, 01 May 2020 20:08:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38674) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jUfh8-0002mD-U9 for emacs-devel@gnu.org; Fri, 01 May 2020 20:07:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jUfh7-00005q-4s for emacs-devel@gnu.org; Fri, 01 May 2020 20:07:50 -0400 Original-Received: from mail-yb1-f195.google.com ([209.85.219.195]:36021) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jUfh6-0008VI-ET for emacs-devel@gnu.org; Fri, 01 May 2020 20:07:48 -0400 Original-Received: by mail-yb1-f195.google.com with SMTP id v10so5809699ybk.3 for ; Fri, 01 May 2020 17:07:48 -0700 (PDT) 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:content-transfer-encoding; bh=dstSBoY7DOgspfglr3fQ9xcIn+/IRR7qqGzKpGUdgRc=; b=OtaMJjrH6yec1ZW0/tBiCxRwiWiFSuKa+lbxWTkzWIJpgAKUsJUcODs98pNKRNBzrD oajtxOnp1P32FPJhtkpzvUPE6z3Y7vPud9bk6aQ+C8nHmxswIPNhdVxfIAHV5z1FKz5C aoRm4Mdoo0N7x5xkxx+n/H3THGrlKe9da2/dvzmKsfew7RYDGfm3ZZWPu1+YHzae9z4G 8DsKlt0J8LxX3vUYPVmvgArqfxZOsj4wY+17iw4tNn3DQa4mS+VvPSkQ+EKj+7DpeuVB IRvMip5hvvCjlQqeTXwG7iCIRF8UBQdCQczcVYcmfQ0RppwA1YD0HbdwSVX3vQmolnDC uhng== X-Gm-Message-State: AGi0PuZbtCmXJ4VU2zG7nOMXRp3aZ98kPFKXFwtfJhBE5+140mt0gnFk Y6ui3UEnfYw0F0ei+TTuseCCtMv3sc+lXfdXJeU6oSQsZzU= X-Google-Smtp-Source: APiQypIZyJ4v9sWgMu1l0r1YMV1jKURz9vcthP6io3LsqeRZ9niEEID4KAq3L6UdqhzuHIXJB/DaLirJ2N1/55I6VXk= X-Received: by 2002:a25:c402:: with SMTP id u2mr9794754ybf.231.1588378067055; Fri, 01 May 2020 17:07:47 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=209.85.219.195; envelope-from=stefankangas@gmail.com; helo=mail-yb1-f195.google.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/01 20:07:47 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.219.195 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:248360 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > Yes. As they join the GNU Elpa flock, we cleanse them of the evil, broth= er! ;-) Personally, I'm not convinced there's a strong need to rename it. But I think it's important that any rename would be agreed upon by the current module author. The worst possible situation would be to have a "better" name but a maintainer that feels alienated. It's my impression that we've had a number of cases where we successfully got a package into GNU ELPA, only to have it fall out of sync with development within a couple of years. We've recently discussed that our copy dash.el is out of sync with recent development, and we have coffee-mode.el before that. Stefan Monnier said in relation to this that: "Other work to do is to make sure the GNU ELPA packages don't become stale. E.g. `dash` is out of date, IIRC." Is there something we could do to avoid such a situation before it arises? To my mind, we really need package authors to push (figuratively speaking) their changes to us, rather than us having to pull their changes. We seem to lack the necessary manpower to constantly "chase down" package authors or do the work to merge changes ourselves on a consistent basis. And as we are working to get even more packages into GNU ELPA, which I think we should, this problem will only tend to increase over time. Best regards, Stefan Kangas