Re: When do we merge the commits from emacs-25 onto master?

[David Engster <deng@randomsample.de>]

Eli Zaretskii writes:
>> From: David Engster <deng@randomsample.de>
>> Date: Mon, 23 Nov 2015 23:43:21 +0100
>> Cc: Paul Eggert <eggert@cs.ucla.edu>, emacs-devel <emacs-devel@gnu.org>
>> 
>> We still haven't figured out how to deal with the generated ChangeLogs,
>> so I'm not sure we should merge at the moment.
>
> Would it work to somehow teach gitmerge.el to use the (fixed) text
> from ChangeLog.2 as the merge-commit log message, instead of the
> original log message at emacs-25 commit time?

I'm not entirely sure what you mean, but the original commits will enter
'master' through the merge, so gitlog-to-changelog will generate entries
for them.

I think at first we must decide between two options:

i) Generate ChangeLog.2 separately for the two branches and exclude it
   from merges.

ii) Devise some workflow which will allow to merge ChangeLog.2 from
   emacs-25 into master. Cherry-picks from master to emacs-25 are also a
   problem, obviously, but they will comprise far less commits
   (hopefully), so I think it's OK if they involve more work.

Option i) is simple, but will create more work for the people fixing the
ChangeLogs. Most importantly, when emacs-25 is merged into master, all
the ChangeLogs will have to be fixed again. It will be easier if merging
and ChangeLog-fixing is done at the same time by one person, since then
one can pretty much copy&paste, but I'm not sure how realistic that
is.

We could also do an extreme version of i): only create ChangeLog.2 for
emacs-25 once, immediately before the release. We will have fixed
ChangeLogs for all the commits already in master; the job is then to
extract only those which are in emacs-25. Maybe gitlog-to-changelog
could mark those commits with a special string? We could remove that
mark again when emacs 25.1 is released.

I already described one workflow for ii) in the other thread. Different
workflows are possible, of course, but I'd claim they all will be of the
same complexity.

-David