From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: New sync'd branch Date: Sun, 23 Aug 2009 18:21:03 -0400 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1251066121 19788 80.91.229.12 (23 Aug 2009 22:22:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Aug 2009 22:22:01 +0000 (UTC) To: miles@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 24 00:21:54 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MfLRh-00061D-V4 for ged-emacs-devel@m.gmane.org; Mon, 24 Aug 2009 00:21:54 +0200 Original-Received: from localhost ([127.0.0.1]:44179 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MfLRh-0004vk-AD for ged-emacs-devel@m.gmane.org; Sun, 23 Aug 2009 18:21:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MfLR9-0004Pw-4t for emacs-devel@gnu.org; Sun, 23 Aug 2009 18:21:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MfLR3-0004Jb-UR for emacs-devel@gnu.org; Sun, 23 Aug 2009 18:21:18 -0400 Original-Received: from [199.232.76.173] (port=47469 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MfLR3-0004J9-DA for emacs-devel@gnu.org; Sun, 23 Aug 2009 18:21:13 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]:31642 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MfLR0-00032p-M0; Sun, 23 Aug 2009 18:21:10 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroFAOddkUpFpYuS/2dsb2JhbACBU89ghBoFh1o X-IronPort-AV: E=Sophos;i="4.44,260,1249272000"; d="scan'208";a="44048504" Original-Received: from 69-165-139-146.dsl.teksavvy.com (HELO ceviche.home) ([69.165.139.146]) by ironport2-out.teksavvy.com with ESMTP; 23 Aug 2009 18:20:16 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 1B12BB40F3; Sun, 23 Aug 2009 18:21:03 -0400 (EDT) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:114538 Archived-At: We'd like to have a new release in the first half of next year with some new features. Given the short time, the new features need to be non-intrusive, like new packages. Until now, we've had 2 active branches: the EMACS_23_1 and the trunk, where the first is limited to bugfixes (and mostly unused, really), and the second is aiming to become the next release. But two things make me think we should change this arrangement: 1- the desire and need to plan for Emacs-24: if we want to keep releasing regularly, we need to have 2 active branches, one for short-term localized improvements, and the other for longer term changes. 2- the fact that Emacs-23.1 seems not to suffer from any serious problems that would call for a quick new release from the EMACS_23_1 branch. So I believe we should create a new branch EMACS_23 which will play the role currently played by the trunk, so the trunk can now be open to more experimental development (bidi, cpp->autoconf conversion, lexbind, ...), targetted for Emacs-24. There are some problem with this: - Changes on the 23 branch need to be sync'd to the trunk. As long as we haven't switched to Bzr, that means we need Miles to do the sync for us. Miles, could you do that? - People installing changes need to carefully choose whether to install it on the 23 branch (from where it will be sync'd to the "24 branch" aka "trunk"), or on the trunk. Basically, the most important aspect is that any bugfix which makes sense on the 23 branch need to be installed on the 23 branch rather than on the trunk. - The 23 branch will not see as much testing any more. So we need to be more conservative on what can go there. And we need to make a conscious effort to try and use the 23 branch on a regular basis. Maybe if the trunk is sufficiently unstable, this will not be too problematic. What do you all think about this? Stefan