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: Release branch plans Date: Wed, 04 Apr 2012 22:03:10 +0300 Message-ID: <83d37ncob5.fsf@gnu.org> References: <87d37q7ld4.fsf@gnu.org> <871uo6puac.fsf@gnu.org> <83ty12hxoa.fsf@gnu.org> <83zkauc96p.fsf@gnu.org> <83y5qec658.fsf@gnu.org> <83mx6sd6vt.fsf@gnu.org> <83ehs3ct46.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1333566443 12249 80.91.229.3 (4 Apr 2012 19:07:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Apr 2012 19:07:23 +0000 (UTC) Cc: cyd@gnu.org, schwab@linux-m68k.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 04 21:07:20 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 1SFVY2-00025p-0O for ged-emacs-devel@m.gmane.org; Wed, 04 Apr 2012 21:07:14 +0200 Original-Received: from localhost ([::1]:56124 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFVUk-0005v2-FJ for ged-emacs-devel@m.gmane.org; Wed, 04 Apr 2012 15:03:50 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58458) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFVUd-0005ty-Ow for emacs-devel@gnu.org; Wed, 04 Apr 2012 15:03:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFVUX-0001jl-4a for emacs-devel@gnu.org; Wed, 04 Apr 2012 15:03:42 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:64359) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFVUM-0001hf-Bv; Wed, 04 Apr 2012 15:03:26 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M1Y00800Y684B00@a-mtaout21.012.net.il>; Wed, 04 Apr 2012 22:02:56 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.55.144]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M1Y0073PY8UXY70@a-mtaout21.012.net.il>; Wed, 04 Apr 2012 22:02:56 +0300 (IDT) 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:149383 Archived-At: > From: Stefan Monnier > Cc: schwab@linux-m68k.org, cyd@gnu.org, emacs-devel@gnu.org > Date: Wed, 04 Apr 2012 13:41:59 -0400 > > > Yes, you do, at least what _I_ am talking about. I explained this at > > least twice in the past: the history is all messed up on the trunk as > > result of this. > > No, it's not messed up. Maybe you don't like it (not sure why), and > maybe `bzr log' shows it in a weird or messed up way (in which case you > should take it up with the bzr guys), but the history itself is very > much not messed up at all. If it shows to humans as messed up, then for all practical purposes it _is_ messed up. History is not an abstract feature, it is only important because it is useful to humans who use such bzr commands as "log", "diff", "annotate", etc. (Well, it is also useful to bzr for merging, but since the branch and the trunk diverge anyway, and will never converge, this part is not too important in this case.) > > You disagree with this being a problem, but I submit > > that this is akin to saying that the history is not important. > > I care a lot about the VCS history metadata, which is why I insist that > we merge from the release branch onto the trunk. If you care about history, you should care first and foremost about how it is presented through the bzr commands that explore it. Otherwise, the history is all but useless. > > Maybe we should take a step back and ask ourselves why do we need to > > merge from the stable branch to the trunk at all? > > Very simple: we want to make sure all the bug-fixes we install on the > stable branch don't get lost on the next release, and we want to reflect > this info into the VCS history so the VCS knows what's going on. What do you mean by "don't get lost"? Installing them on the trunk separately, or through cherry-picking, will get them to trunk all the same, no?