From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Carsten Mattner Newsgroups: gmane.emacs.devel Subject: Re: Periodical releases Date: Mon, 2 Jan 2012 22:36:09 +0100 Message-ID: References: <71588355363047528F16FE989690A488@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1325540179 18709 80.91.229.12 (2 Jan 2012 21:36:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 Jan 2012 21:36:19 +0000 (UTC) Cc: Emacs developers To: chad Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 02 22:36:15 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RhpYF-0002Wz-2i for ged-emacs-devel@m.gmane.org; Mon, 02 Jan 2012 22:36:15 +0100 Original-Received: from localhost ([::1]:54911 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhpYE-0003vU-MC for ged-emacs-devel@m.gmane.org; Mon, 02 Jan 2012 16:36:14 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:56989) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhpYC-0003sh-67 for emacs-devel@gnu.org; Mon, 02 Jan 2012 16:36:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RhpYA-0000D9-QJ for emacs-devel@gnu.org; Mon, 02 Jan 2012 16:36:12 -0500 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:36157) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhpYA-0000D1-Lx for emacs-devel@gnu.org; Mon, 02 Jan 2012 16:36:10 -0500 Original-Received: by iacb35 with SMTP id b35so32679539iac.0 for ; Mon, 02 Jan 2012 13:36:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rejioDwbqBTR9pyCwho0V6uWAtrQA4GQyEnmZgcItkE=; b=jRVkLotzv/xG+DBd3q63+tSaxJEnKoQXAbbRTZB6W1QEJjAsda22yPPqcEBs4r2QH2 pLeALii5mGQAL8bdER8Qp9QMlMK+6GfvRKv9yX4OwQfqtbfGoTgFNRGLZaR6ZlPIHPQ4 2Sm7+E1BSVM8G9dlfsXOyJYl+tJf/rfpnhBMU= Original-Received: by 10.50.195.129 with SMTP id ie1mr58827396igc.29.1325540169854; Mon, 02 Jan 2012 13:36:09 -0800 (PST) Original-Received: by 10.50.106.132 with HTTP; Mon, 2 Jan 2012 13:36:09 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:147197 Archived-At: On Mon, Jan 2, 2012 at 8:54 PM, chad wrote: > As far as I can tell, the primary motivator for more frequent releases > of emacs itself is `so emacs doesn't drift so far from its sub-parts', li= ke > as Gnus, Org, CEDET, CC-mode (in the past), etc. =A0This is a laudable > goal, but emacs doesn't seem to currently have the developer cycles > necessary to handle this - releases are frequently held up by documentati= on > changes and reviews even now, with the infrequent releases we have. > > Hopefully, the included package system can cover this gap, once it's full= y spread > through the userbase; users will be able to easily opt-in to newer Gnus r= eleases > (for example) via elpa(s)/packages. =A0If we get this working reliably, w= e could even > remove some packages from the emacs core, in favor of more frequent > package-based releases. =A0While this model might have once seemed burden= some > to users, several years of such systems (for example, in web browser exte= nsion > updates) will have already trained them to deal with such things before e= macs > starts doing something similar. > > That's my hope, anyway. I fully support removing non-essential modes from emacs, now that packaging is supported officially in a consistent way.