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: Thu, 05 Apr 2012 06:04:55 +0300 Message-ID: <837gxudgko.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> <83d37ncob5.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1333595093 7442 80.91.229.3 (5 Apr 2012 03:04:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 5 Apr 2012 03:04:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 05 05:04:52 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 1SFd0D-0003wM-R6 for ged-emacs-devel@m.gmane.org; Thu, 05 Apr 2012 05:04:49 +0200 Original-Received: from localhost ([::1]:47437 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFd0C-00071J-9M for ged-emacs-devel@m.gmane.org; Wed, 04 Apr 2012 23:04:48 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFd09-00070z-85 for emacs-devel@gnu.org; Wed, 04 Apr 2012 23:04:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFd05-00015a-TI for emacs-devel@gnu.org; Wed, 04 Apr 2012 23:04:44 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:65395) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFd05-00014f-LW for emacs-devel@gnu.org; Wed, 04 Apr 2012 23:04:41 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0M1Z00500KAUY100@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Thu, 05 Apr 2012 06:04:39 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.229.252.114]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M1Z005Z3KJQW860@a-mtaout23.012.net.il>; Thu, 05 Apr 2012 06:04:39 +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.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:149390 Archived-At: > From: Stefan Monnier > Cc: schwab@linux-m68k.org, cyd@gnu.org, emacs-devel@gnu.org > Date: Wed, 04 Apr 2012 18:01: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. > > No: history is something that gets recorded "for eternity", whereas its > rendition in human form is done on the fly and can be fixed by > subsequent releases (or by the use of other tools, options, ...). > Hence history is of utmost importance, whereas its rendition is secondary. And you still didn't say what is it important _for_, if not for being investigated by humans. Until you explain that, I consider your arguments void, because all they say is what history _is_, not what's its purpose. > > 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? > > But that depends on not forgetting to install it on both sides, which is > error prone and is more work than installing only once on the release > branch and merging later since merging can be batched and largely automated. How is it more error prone or more work? All it takes is one merge command and one ci command. Since those immediately follow the original commit, even getting the revision right is easy and thus error free.