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 13:57:50 +0100 Message-ID: References: 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 1325509083 32516 80.91.229.12 (2 Jan 2012 12:58:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 Jan 2012 12:58:03 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 02 13:57:59 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 1RhhSg-0005P1-FH for ged-emacs-devel@m.gmane.org; Mon, 02 Jan 2012 13:57:58 +0100 Original-Received: from localhost ([::1]:37900 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhhSg-0007vx-52 for ged-emacs-devel@m.gmane.org; Mon, 02 Jan 2012 07:57:58 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:35857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhhSd-0007vf-39 for emacs-devel@gnu.org; Mon, 02 Jan 2012 07:57:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RhhSb-0003PB-MY for emacs-devel@gnu.org; Mon, 02 Jan 2012 07:57:55 -0500 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:50362) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhhSZ-0003Oe-SQ; Mon, 02 Jan 2012 07:57:52 -0500 Original-Received: by iacb35 with SMTP id b35so32008302iac.0 for ; Mon, 02 Jan 2012 04:57:50 -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=oXytd/qxrJB3WMJ7ipUQYhjxlvXtCkoBC56UWj5EFnE=; b=E+XYMK4eoEs3QXVn731meIF43Ly88M7/6fWSXcd6np4zA/5zwQzOL0M0eDLKmAMkQr VU4YWd1YlIgzJYFY6ByKxSTEX5GWAiNRfJECsrOi926wAn7SSNp06o2Cjsi460OrWJ+d ntqzn5DxEUUZkzcLJfHtZY5o4sCZeb9QgmdlI= Original-Received: by 10.50.195.129 with SMTP id ie1mr56858142igc.29.1325509070694; Mon, 02 Jan 2012 04:57:50 -0800 (PST) Original-Received: by 10.50.106.132 with HTTP; Mon, 2 Jan 2012 04:57:50 -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:147171 Archived-At: On Mon, Jan 2, 2012 at 12:36 PM, Eli Zaretskii wrote: >> Date: Mon, 2 Jan 2012 11:40:20 +0100 >> From: Carsten Mattner >> Cc: Emacs developers >> >> > These are fairly significant structural changes which are difficult to >> > perform piecemeal and tend to introduce significant breakage which tak= es >> > months if not years to test&debug (maybe partly for lack of a good >> > regression test suite, but also because of very complex semantics, mos= t >> > of which is the result of accidental interferences between >> > "independent" features). >> >> The solution for that is to let it evolve in a branch for longer than >> one release cycle > > Been there, done that. =A0In Emacs, this generally means leave the code > to bit-rot into oblivion. =A0Examples: > > =A0. The person who wrote the multi-tty code disappeared after merging > =A0 =A0the branch onto the trunk; if we would have waited longer with the > =A0 =A0merge, we would have no one who knew the code enough to merge it > =A0 =A0and take care of merge complications. > > =A0. The bidi branch actually did bitrot, for at least 3 years, until > =A0 =A0yours truly decided it was now or never, and somehow managed to > =A0 =A0find time to do the job. =A0Knowing now how much effort it took, I > =A0 =A0can assure you that work would never have been done had Stefan and > =A0 =A0Chong not supported me all the way and urged me to merge early. = =A0A > =A0 =A0year from now, I cannot even promise I will have enough time and > =A0 =A0health left to do anything comparable. > >> That way finished features like say package support, built-in colour >> theme support, cc-mode and other mode updates, etc., which are less >> invasive, are delivered in a stable release faster. > > That's a nice theory, but implementing it in practice needs a much > larger and probably different organization than Emacs development we > have now. =A0Unlike many other projects, Emacs is a hodgepodge of a > myriad of separate and almost independent subsystems, many of which > require very specific domain knowledge and target different audiences, > sometimes quite narrow ones. =A0Exposing significant changes to a wide > audience is perhaps the only practical way of testing those changes > efficiently; leaving them on a branch would mean features remain > largely untested (read: buggy) for many months if not years. > > If we want to move in the direction of periodical releases, we will > have to come up with a plan that includes organizational and > procedural changes, and we will have to convince ourselves that such a > plan is doable in practice. =A0First step in the plan should be to bring > much more developers on board. okay, this may not work for the current development workflow. Another proposal: Don't wait until "perfection" and release trunk more often with bug releases if needed. Emacs trunk has never been unstable for me. I'm even using the NS port and it's still stable. I would have less of a need to build emacs manually if there were more release and therefore standard emacs Linux distros was more up to date.