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: patch vs. overwrite in bzr Date: Wed, 04 Apr 2012 20:09:46 +0300 Message-ID: <83iphfctk5.fsf@gnu.org> References: <87k42cwys8.fsf@gnu.org> <87limhuldm.fsf@gnu.org> <871uo7g4j6.fsf@gnu.org> <87iphjhbm8.fsf@wanadoo.es> <87398lgrat.fsf_-_@niu.edu> <871uo5c7r0.fsf@wanadoo.es> <87pqbpj5j3.fsf@altern.org> <87aa2szgig.fsf@gnu.org> <87ehs4yrhz.fsf@gnu.org> <87vclg804u.fsf@gmx.de> <87ehs3sxm1.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1333559729 22374 80.91.229.3 (4 Apr 2012 17:15:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Apr 2012 17:15:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Thierry Volpiatto Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 04 19:15:28 2012 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 1SFTnq-0007s3-Af for ged-emacs-devel@m.gmane.org; Wed, 04 Apr 2012 19:15:26 +0200 Original-Received: from localhost ([::1]:51147 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFTne-00032H-Qn for ged-emacs-devel@m.gmane.org; Wed, 04 Apr 2012 13:15:14 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38032) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFTnX-0002yO-BS for emacs-devel@gnu.org; Wed, 04 Apr 2012 13:15:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFTnM-0006ws-8y for emacs-devel@gnu.org; Wed, 04 Apr 2012 13:15:05 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:56556) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFTnM-0006wZ-0q for emacs-devel@gnu.org; Wed, 04 Apr 2012 13:14:56 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0M1Y00400SZHFA00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Wed, 04 Apr 2012 20:09:32 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.55.144]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M1Y004IYSZVDB30@a-mtaout23.012.net.il>; Wed, 04 Apr 2012 20:09:32 +0300 (IDT) In-reply-to: <87ehs3sxm1.fsf@gmail.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:149375 Archived-At: > From: Thierry Volpiatto > Date: Wed, 04 Apr 2012 10:35:34 +0200 > > I never understood why Emacs have not a developing branch to continue > developing new features during the feature freeze. Read the archives for past discussions of this issue, and you will understand. The reason is insufficient resources. It takes a significant effort to run a pretest, triage the bugs and fix important ones, update the manuals, etc. The extremely small number of core maintainers does not leave resources to overview both the branch and the trunk, as long as there's lots of work on each one of them. People who want this to change should volunteer to do the tasks that are needed to be done for the pretest and release. Then 2 things will happen: (1) there will be more people who can take a responsibility for a release, thus freeing more time for the head maintainers to take care of the trunk; and (2) the number of people who are familiar with Emacs enough to become core maintainers will also grow. > I think Emacs lost a lot a new features during this process, especially > from contributors that send patches; most patches are lost or > are unusable after several months of modifications in trunk. If you use bzr or any other dVCS, you can simply put your changes on a branch or even a shelf, and then when the time comes to push them, you will have much less trouble than you think. Modern VCSes do a very good job at merging.