From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.devel Subject: Re: Package proposal: greader, an audio emacs reader for blind and dislexic people Date: Thu, 31 Jan 2019 17:08:54 +1300 Message-ID: <965f7e5c3c7be56ae4c6141eabe13d8a@webmail.orcon.net.nz> References: <87tvhpx0fr.fsf@web.de> <87ftt9wpfh.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="47640"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Orcon Webmail Cc: Michael Heerdegen , Michelangelo Rodriguez , emacs devel To: Tim Cross Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 31 05:09:44 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gp3fa-000CI4-Tw for ged-emacs-devel@m.gmane.org; Thu, 31 Jan 2019 05:09:43 +0100 Original-Received: from localhost ([127.0.0.1]:48440 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gp3fZ-0001lF-Sp for ged-emacs-devel@m.gmane.org; Wed, 30 Jan 2019 23:09:41 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35515) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gp3ez-0001jo-B7 for emacs-devel@gnu.org; Wed, 30 Jan 2019 23:09:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gp3ey-0000fs-5o for emacs-devel@gnu.org; Wed, 30 Jan 2019 23:09:05 -0500 Original-Received: from smtp-2.orcon.net.nz ([60.234.4.43]:36828) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gp3ex-0000dN-Rb for emacs-devel@gnu.org; Wed, 30 Jan 2019 23:09:04 -0500 Original-Received: from [10.253.37.70] (port=9460 helo=webmail.orcon.net.nz) by smtp-2.orcon.net.nz with esmtpa (Exim 4.86_2) (envelope-from ) id 1gp3eo-0007FS-NB; Thu, 31 Jan 2019 17:08:54 +1300 Original-Received: from wlgwil-nat-office.catalyst.net.nz ([202.78.240.7]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Thu, 31 Jan 2019 17:08:54 +1300 In-Reply-To: X-Sender: psainty@orcon.net.nz X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 60.234.4.43 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:232848 Archived-At: On 2019-01-31 16:13, Tim Cross wrote: > The thing about GNU ELPA is that all the packages in there are > actively maintained and kept up to date with current version of Emacs. > The mor packages in there, the more work is required to release new > versions of Emacs. I don't believe that's the case at all. GNU ELPA packages are not part of core Emacs, and anyone can contribute them (within the FSF rules). If new Emacs releases might be held back on account of any arbitrary ELPA package not working, this is the first I've heard of it. Maybe certain packages which are considered particularly important might have such status in effect, and obviously if bugs are reported against ELPA packages then they could be fixed, but I don't think adding ELPA packages increases the amount of work required to release new versions of Emacs? After all, one of the acknowledged advantages of ELPA packages is that they can be updated outside of Emacs release cycles, so it is *less* important that ELPA bugs be fixed prior to an Emacs release, because they can be fixed afterwards without the need of another Emacs release. > IMO the GNU ELPA repository is really for packages that represent > core Emacs functionality. For non-core things, we have MELPA, which > sounds like a better fit for this package. Definitely not true. GNU ELPA and MELPA are simply two instances of package archives. There are plenty of packages in GNU ELPA which are nothing like "core" functionality, and plenty of packages in MELPA that I wish had been contributed to either GNU ELPA or Emacs core. It's not the case that the two archives were established for the purposes you've described. The only distinction I draw between them is that one requires contributors to follow the FSF rules, and the other does not. > Regardless, I think the better approach is to first develop and > release the package in MELPA. If it becomes popular and the community > believes it would be a good fit for GNU ELPA, it can be moved over to > that repository. That can be a recipe for failure. Too many packages get contributed to MELPA, get popular, and then *can't* be "moved over" to GNU ELPA because the author wasn't taking care of the copyright issue while it was on MELPA, and suddenly finds that they've accepted code contributions into their package which are blocking that move. The more popular the package becomes, the more likely that situation is to occur. It's better to start in GNU ELPA and ensure that this problem is avoided from the outset. (There's a LOT of good elisp out there which would benefit Emacs core, but which will never do so because by the time it was "good enough" for that to happen, it was also completely impractical to assign the copyright to the FSF.) -Phil