From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Why not include all ELPA packages in an Emacs release? Date: Thu, 30 May 2024 15:19:36 +0300 Message-ID: <86h6efqyp3.fsf@gnu.org> References: <87bk4ql3u5.fsf@jeremybryant.net> <864jagu9ji.fsf@gnu.org> <878qzspd9j.fsf@gnu.org> <87y17rag37.fsf@yahoo.com> <86mso7r1f1.fsf@gnu.org> <87ttifa52l.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1504"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tsdh@gnu.org, arash@gnu.org, stefankangas@gmail.com, jb@jeremybryant.net, emacs-devel@gnu.org, monnier@iro.umontreal.ca, philipk@posteo.net To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 30 14:20:51 2024 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 1sCelz-000050-VU for ged-emacs-devel@m.gmane-mx.org; Thu, 30 May 2024 14:20:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sCeky-0001kq-Fw; Thu, 30 May 2024 08:19:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sCekx-0001gv-A3 for emacs-devel@gnu.org; Thu, 30 May 2024 08:19:43 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sCekv-000598-Rk; Thu, 30 May 2024 08:19:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=W8jXUh02siQwrWEj2c3JcZqTPvwYTpTZdDc3Jn8V8Yw=; b=o+FatrK8/9rr PKLiCUHUzyIkrIBJCFWnXIllvQAEt+qT2Lib3m9120vqd2Z1eQ32D5dC//9QqcVXiqzlheHA8r7ws F5GEeT6BPVyvmbgrC0W32mzCWU4VEj7GKbDUrCfCskj0LJMXkhBWt6+Yp2m9/pZiB+n/5RZtmaYP/ Wls8zE5Mjvtq4MEXYCnzJW8rszenfm9gMBFiFq1JNNMDWaSps0fnxY/HmLVEsl8XYiNFm6EAu1hmW oK1ddxdYb81ebpIKVml2gRbdc+eLPEgT9/R+nH36MZ3gzm+fOh+yLAm2B4UWjMYCwk6hv6l2jkkdS 2UlX3yAqVSeBCipe6Up3fw==; In-Reply-To: <87ttifa52l.fsf@yahoo.com> (message from Po Lu on Thu, 30 May 2024 19:53:54 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:319743 Archived-At: > From: Po Lu > Cc: tsdh@gnu.org, arash@gnu.org, stefankangas@gmail.com, > jb@jeremybryant.net, emacs-devel@gnu.org, monnier@iro.umontreal.ca, > philipk@posteo.net > Date: Thu, 30 May 2024 19:53:54 +0800 > > Eli Zaretskii writes: > > > Packages that will be moved to ELPA (when that happens) should have > > their dedicated maintainers, and it will be the job of those > > maintainers to adapt to any changes in Emacs that affect each package. > > > > I see no show-stoppers there, FWIW. > > Does Calc, or its ilk? Calc is not on ELPA yet, so the question's answer is "undefined". > And will such maintainers notice and be willing > to adapt their packages to minor changes that don't affect themselves > and their existing users, as, If they don't, someone will ping them, sooner or later. usually via a bug report. > 2023-06-26 Po Lu > > * lisp/calc/calc.el (calc-mode, calc): Make sure the on-screen > keyboard is not hidden when a Calc buffer is created or a Calc > Trail window is being created for the first time. > > * lisp/touch-screen.el (touch-screen-window-selection-changed): > Take touch-screen-display-keyboard in to account. > > during the development cycle of a new feature in a new Emacs release, as > was done here? Had Calc been transferred into an independent > repository, with its own maintainers, these changes would have been > considerably delayed at best, depriving Android users of a functioning > scientific calculator in the interim. Welcome to the real world. We have such problems in Emacs all the time, even without moving stuff to ELPA. Emacs is immense, and in many cases even identifying the places where such adaptations are needed takes a long time. How long do you think it took me to find all the places where bidi support needed changes, even though I was here all the time? There's nothing new here, and we shouldn't reject the idea of moving stuff to ELPA because of that. > > The issues which led us to seriously consider moving some core > > packages to ELPA are not imaginary, they are very real. > > Which issues and packages are you speaking of? Please re-read the discussions, I see no need to reiterate all that here again.