From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Periodical releases Date: Mon, 02 Jan 2012 06:36:16 -0500 Message-ID: References: Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1325504189 1445 80.91.229.12 (2 Jan 2012 11:36:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 Jan 2012 11:36:29 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Carsten Mattner Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 02 12:36:24 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 1RhgBi-0006hD-Im for ged-emacs-devel@m.gmane.org; Mon, 02 Jan 2012 12:36:22 +0100 Original-Received: from localhost ([::1]:45758 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhgBh-0000Ox-Mj for ged-emacs-devel@m.gmane.org; Mon, 02 Jan 2012 06:36:21 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:57840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhgBe-0000NK-HX for emacs-devel@gnu.org; Mon, 02 Jan 2012 06:36:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RhgBd-0007v0-7q for emacs-devel@gnu.org; Mon, 02 Jan 2012 06:36:18 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:60765) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhgBd-0007uw-54 for emacs-devel@gnu.org; Mon, 02 Jan 2012 06:36:17 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RhgBc-0001b4-Qz; Mon, 02 Jan 2012 06:36:16 -0500 In-reply-to: (message from Carsten Mattner on Mon, 2 Jan 2012 11:40:20 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:147165 Archived-At: > 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 takes > > months if not years to test&debug (maybe partly for lack of a good > > regression test suite, but also because of very complex semantics, most > > 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. In Emacs, this generally means leave the code to bit-rot into oblivion. Examples: . The person who wrote the multi-tty code disappeared after merging the branch onto the trunk; if we would have waited longer with the merge, we would have no one who knew the code enough to merge it and take care of merge complications. . The bidi branch actually did bitrot, for at least 3 years, until yours truly decided it was now or never, and somehow managed to find time to do the job. Knowing now how much effort it took, I can assure you that work would never have been done had Stefan and Chong not supported me all the way and urged me to merge early. A year from now, I cannot even promise I will have enough time and health 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. Unlike 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. Exposing 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. First step in the plan should be to bring much more developers on board.