From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Package proposal: greader, an audio emacs reader for blind and dislexic people Date: Fri, 1 Feb 2019 09:32:44 +1100 Message-ID: References: <87tvhpx0fr.fsf@web.de> <87ftt9wpfh.fsf@web.de> <965f7e5c3c7be56ae4c6141eabe13d8a@webmail.orcon.net.nz> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000009b86720580c89bca" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="268777"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Michael Heerdegen , Michelangelo Rodriguez , emacs devel To: Phil Sainty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 31 23:33:49 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 1gpKu4-0017oh-EZ for ged-emacs-devel@m.gmane.org; Thu, 31 Jan 2019 23:33:48 +0100 Original-Received: from localhost ([127.0.0.1]:33890 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gpKu3-00011y-8h for ged-emacs-devel@m.gmane.org; Thu, 31 Jan 2019 17:33:47 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gpKtK-00011T-DK for emacs-devel@gnu.org; Thu, 31 Jan 2019 17:33:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gpKtI-0004O2-D5 for emacs-devel@gnu.org; Thu, 31 Jan 2019 17:33:02 -0500 Original-Received: from mail-oi1-x22e.google.com ([2607:f8b0:4864:20::22e]:43463) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gpKtG-0004NM-Dx for emacs-devel@gnu.org; Thu, 31 Jan 2019 17:33:00 -0500 Original-Received: by mail-oi1-x22e.google.com with SMTP id u18so4172136oie.10 for ; Thu, 31 Jan 2019 14:32:56 -0800 (PST) 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=FToAtRgdU4DsMSuSrdLMBZ5daXY4HJW7cnYMr4rcjcU=; b=sJ5kBrcwgw0soej9zjhhQhJLN9hEN210P61RGTz4GmVz/NmV0xdzXErozNoJ41D+Mq NPQaN3fezlHX8RxidP0BsvvOo1WhLpaslEIBEiFTTJ7fJUhmYrt1Q2ImZaMWgbENWkXH Y6p9hfal9fSGsmsM0KZx1xmt4wTkFZ5b61S1c21OooTN+azIb31+5Yi0YAAGFMNU51/g Sh/QXBDQdUlJ7+5c15Be89QfEV2xc4cUYLkwPwbbTp1lV41mwoLZm0YJ6P6Br96wORt8 rxbL//MSDj/oKmdRkQLxJRuAimxz3ZUqBUJBtQDBuFRVhbvfGW7zagF1DArd08Pf1eY2 bqTQ== 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=FToAtRgdU4DsMSuSrdLMBZ5daXY4HJW7cnYMr4rcjcU=; b=oNWWPGnas5gZPAywM4sys+1YiCDO5qADzT7dA/SZY/p31+hrPSwAy6es17eqM0nt/z 2TOoE7Ycv9XkVrTx9vYaf/5GJVd8yCulSjzhVFlPvgSCfHyJhnQSATeO3ddfbbIslzKJ vEy7Bw21k0mWJ7ibJiPxGbINPfcEOf2Bb60ru/5gpXjRrQBlWK1OB93TFS8qQCAQFz3M j9ixKjiqS9KTb+1U68/YoLvkLcI3pnpNPz2/a6Ai2M33enMhiQ2F9wxqXksUvcnHUnSy IVOKdrbaWhIPJ49JbuATaVbAt24E+izLrIKZj6o5IMJuaF/FvMKDGiZqsDeL+/d+fWYL UQEg== X-Gm-Message-State: AHQUAubTXw/YmvJ/yWdaDE8mKfUMDx3E8+o0aQXluCNoGWRv1vR8qMVX jD3m/X3jnNYTLuQReuc1bZxW8TCkr5Yf4wvDrVQ= X-Google-Smtp-Source: ALg8bN7lmk07FcoAqZ1+4zB/F8LW0ypQZ1ZAlbys0GRH9grzEZiL/+Qq8TVjERHvZPbmPS9172XmmUBIJHpjDs1hSqo= X-Received: by 2002:aca:a90f:: with SMTP id s15mr16962762oie.137.1548973976026; Thu, 31 Jan 2019 14:32:56 -0800 (PST) In-Reply-To: <965f7e5c3c7be56ae4c6141eabe13d8a@webmail.orcon.net.nz> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::22e 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:232870 Archived-At: --0000000000009b86720580c89bca Content-Type: text/plain; charset="UTF-8" OK, thanks for the correction. On Thu, 31 Jan 2019 at 15:08, Phil Sainty wrote: > 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 > > -- regards, Tim -- Tim Cross --0000000000009b86720580c89bca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, thanks for the correction.=C2=A0

On Thu, 31 Jan 2019 = at 15:08, Phil Sainty <psainty@o= rcon.net.nz> wrote:
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).=C2=A0 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.=C2=A0 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.=C2=A0 GNU ELPA and MELPA are simply two instances of package archives.=C2=A0 There are plenty of packages in GNU ELPA which are<= br> nothing like "core" functionality, and plenty of packages in MELP= A
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.=C2=A0 The only distinction I draw between th= em
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<= br> > believes it would be a good fit for GNU ELPA, it can be moved over to<= br> > that repository.

That can be a recipe for failure.=C2=A0 Too many packages get contributed to MELPA, get popular, and then *can't* be "moved over" to GN= U 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.=C2=A0 The more popular the=
package becomes, the more likely that situation is to occur.=C2=A0 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,<= br> but which will never do so because by the time it was "good enough&quo= t; for
that to happen, it was also completely impractical to assign the
copyright
to the FSF.)


-Phil



--
regards,

Tim

--
Tim Cross

--0000000000009b86720580c89bca--