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 19:31:49 +0200 Message-ID: <83sjjyqad6.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1325525519 18656 80.91.229.12 (2 Jan 2012 17:31:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 Jan 2012 17:31:59 +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 18:31:54 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 1Rhljm-0002jo-AZ for ged-emacs-devel@m.gmane.org; Mon, 02 Jan 2012 18:31:54 +0100 Original-Received: from localhost ([::1]:50570 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rhljl-0000FR-L1 for ged-emacs-devel@m.gmane.org; Mon, 02 Jan 2012 12:31:53 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:55157) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rhljj-0000Eq-95 for emacs-devel@gnu.org; Mon, 02 Jan 2012 12:31:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rhlji-0005dD-18 for emacs-devel@gnu.org; Mon, 02 Jan 2012 12:31:51 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:40591) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rhljh-0005d9-PT for emacs-devel@gnu.org; Mon, 02 Jan 2012 12:31:49 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LX600B00M0NZK00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Mon, 02 Jan 2012 19:31:45 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.126.18.76]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LX600BNCM0WTL30@a-mtaout21.012.net.il>; Mon, 02 Jan 2012 19:31:45 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.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:147180 Archived-At: > Date: Mon, 2 Jan 2012 13:57:50 +0100 > From: Carsten Mattner > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > > 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. That could work, but it still needs: . a much more disciplined commit process, probably coupled with 1 more branch (3 instead of just 2) . more active patch review process (currently, lots of serious bugs are detected months if not years after being introduced) . several volunteers to review and update the manuals to keep them in sync with development You see, even for few months worth of development, the amount of changes in the Emacs repository is so large that it is impossible to release a dependable and accurately documented version without much more active "continuous integration" style maintenance. You may consider it stable enough for your workflows, but someone who constantly uses a certain mode that became broken by a release will feel otherwise. Now, a simple calculation will show that if it takes about a year to finish a pretest of a major release, doing a release every 2 months will need at least a month of pretest-style fixups. Unless this month is invested in parallel with development, 2 months become 3 months, which then need 1.5 months of fixups, and so on, ad nauseam. And without even a test suite with good coverage, how do you do a continuous integration? IOW, even this limited goal needs preconditions to become practical. Volunteers are welcome.