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: Move to a cadence release model? Date: Wed, 11 Nov 2015 17:49:27 +0200 Message-ID: <83y4e4k03c.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1447257212 18000 80.91.229.3 (11 Nov 2015 15:53:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Nov 2015 15:53:32 +0000 (UTC) Cc: xfq.free@gmail.com, john@yates-sheets.org, rms@gnu.org, emacs-devel@gnu.org To: John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 11 16:53:23 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZwXi6-0000g8-P5 for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 16:53:22 +0100 Original-Received: from localhost ([::1]:41387 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwXi5-0002Sj-L4 for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 10:53:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwXgD-0001uB-DV for emacs-devel@gnu.org; Wed, 11 Nov 2015 10:53:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwXeM-0002GT-Nu for emacs-devel@gnu.org; Wed, 11 Nov 2015 10:51:25 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:36114) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwXeM-0002GM-GG; Wed, 11 Nov 2015 10:49:30 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NXN00100QL34C00@a-mtaout23.012.net.il>; Wed, 11 Nov 2015 17:49:29 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NXN0016NQMG1750@a-mtaout23.012.net.il>; Wed, 11 Nov 2015 17:49:29 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:194077 Archived-At: > From: John Wiegley > Date: Tue, 10 Nov 2015 15:58:20 -0800 > Cc: John Yates , rms@gnu.org, > Emacs-devel > > I would indeed like to see several .x releases within a cycle, fairly evenly > spaced. x.y releases would wait until we have a larger set of features ready. We more or less do this already, so no significant change there. Releases from emacs-24 branch were done approximately every 6 months. The intervals could be made shorter if we don't allow new features on the release branch. > Doing this properly may mean dividing how we develop Emacs, though, with > active development on both the "current release branch (25.x)", and the "next > major release (26.1)". Merges would proceed daily from the former to the > latter, but rarely in the other direction (and only by cherry-picking). Careful here: you are talking about maintaining more than 2 active branches. We still have veteran developers who regularly shoot themselves in the foot with even 2 branches, and others who evidently cannot safely work on a feature branch without messing up their DAG. Last, but not least, gitmerge.el is still very much in diapers, and doesn't support more than 2 branches. Most places I know about have separate teams working on each branch. Do we have enough people to do that? > We want an active focus on bugs -- toward a stabler .x -- but we don't want to > inhibit integration of feature branches toward the next x.y as they become > ready. As I wrote earlier, "active focus on bugs" is a pipe dream as long as the number of people who care about bugs enough to pick them up, investigate, and work with the submitters or by themselves to debug them is some prime number less than 3. We will never succeed in moving forward to some more elaborate development model if we don't have this issue covered much better than we do now.