Re: Release branch plans

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> 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.