make change-history on non-master branches

make change-history on non-master branches

[Glenn Morris]

Why does 'make change-history' refuse to run on non-master branches?
It's going to need to be run on the emacs-25 branch, isn't it?

And the resulting ChangeLog.2 entries (and more importantly, any
corrections) will have to be merged to master, just like in the old days?
(I presume gitmerge.el should handle it though.)

(It seems to me that it would be simpler if the corrections to commit
logs were versioned, not the whole generated ChangeLog; but I've said
that before.)

Re: make change-history on non-master branches

[Paul Eggert]

Glenn Morris wrote:
> Why does 'make change-history' refuse to run on non-master branches?
> It's going to need to be run on the emacs-25 branch, isn't it?

'make change-history' refuses to run on non-master branches because I thought 
there would be problems if people ran it on their own branches.  Feel free to 
remove that check if you want to deal with the fallout.

> (It seems to me that it would be simpler if the corrections to commit
> logs were versioned, not the whole generated ChangeLog; but I've said
> that before.)

That's what coreutils does.  Only one person uses that facility, which is hard 
to use, and my impression is that nobody else understands how it works.

Re: make change-history on non-master branches

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Sat, 14 Nov 2015 21:15:57 -0500
> Cc: emacs-devel@gnu.org
> 
> And the resulting ChangeLog.2 entries (and more importantly, any
> corrections) will have to be merged to master, just like in the old days?

Maybe I'm missing something, but why do we have to merge it?  Won't
"make change-history" create on each branch the file that branch
wants?

If we can avoid merging, we could teach gitmerge.el skip that file.

Re: make change-history on non-master branches

[Glenn Morris]

Eli Zaretskii wrote:

>> And the resulting ChangeLog.2 entries (and more importantly, any
>> corrections) will have to be merged to master, just like in the old days?
>
> Maybe I'm missing something, but why do we have to merge it?  Won't
> "make change-history" create on each branch the file that branch
> wants?
>
> If we can avoid merging, we could teach gitmerge.el skip that file.

The issue is the hand-written corrections.

Someone makes a commit to emacs-25.
The commit log message has an error on it (eg wrong author).
ChangeLog.2 is generated (to reiterate, currently it refuses to do so on
non-master branches) and corrected. Now the correction needs to be
propagated to master.

If you make gitmerge.el ignore ChangeLog.2 you'll lose the
corrections, or have to make them twice.

BTW, gitmerge.el should not ignore any other (non-generated) ChangeLog.

Re: make change-history on non-master branches

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Wed, 18 Nov 2015 13:10:11 -0500
> 
> Eli Zaretskii wrote:
> 
> >> And the resulting ChangeLog.2 entries (and more importantly, any
> >> corrections) will have to be merged to master, just like in the old days?
> >
> > Maybe I'm missing something, but why do we have to merge it?  Won't
> > "make change-history" create on each branch the file that branch
> > wants?
> >
> > If we can avoid merging, we could teach gitmerge.el skip that file.
> 
> The issue is the hand-written corrections.

Right.  But if we merge ChangeLog.2 from the release branch to master,
then this will produce a mess when "make change-history" is run on
master, no?  I mean, some entries will appear twice, once after
corrections, the other without.  No?

Re: make change-history on non-master branches

[Glenn Morris]

Eli Zaretskii wrote:

> Right.  But if we merge ChangeLog.2 from the release branch to master,
> then this will produce a mess when "make change-history" is run on
> master, no?  I mean, some entries will appear twice, once after
> corrections, the other without.  No?

Quite possibly. I don't know exactly what happens if the commit hash
from the ChangeLog.2 footer were to get merged between branches.

I don't know how to solve this problem, but it seems to me that it needs
to be solved, and the more master and emacs-25 diverge, the worse it
gets.

(All I can say, which I know isn't helpful, is that if the corrections
were stored on a per commit-basis, this issue would not arise, AFAICS.)

Re: make change-history on non-master branches

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Wed, 18 Nov 2015 13:28:08 -0500
> 
> Eli Zaretskii wrote:
> 
> > Right.  But if we merge ChangeLog.2 from the release branch to master,
> > then this will produce a mess when "make change-history" is run on
> > master, no?  I mean, some entries will appear twice, once after
> > corrections, the other without.  No?
> 
> Quite possibly. I don't know exactly what happens if the commit hash
> from the ChangeLog.2 footer were to get merged between branches.
> 
> I don't know how to solve this problem, but it seems to me that it needs
> to be solved, and the more master and emacs-25 diverge, the worse it
> gets.

I agree.

Perhaps Git gurus could help us out?  Andreas, any suggestions?

TIA

Re: make change-history on non-master branches

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 18 Nov 2015 13:28:08 -0500
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> Quite possibly. I don't know exactly what happens if the commit hash
> from the ChangeLog.2 footer were to get merged between branches.
> 
> I don't know how to solve this problem, but it seems to me that it needs
> to be solved, and the more master and emacs-25 diverge, the worse it
> gets.
> 
> (All I can say, which I know isn't helpful, is that if the corrections
> were stored on a per commit-basis, this issue would not arise, AFAICS.)

Btw, one other issue that needs to be taken care of is
admin/authors.el, which needs to be taught about top-level ChangeLog.2
file.

Re: make change-history on non-master branches

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Glenn Morris <rgm@gnu.org>
>> Cc: eggert@cs.ucla.edu,  emacs-devel@gnu.org
>> Date: Wed, 18 Nov 2015 13:28:08 -0500
>> 
>> Eli Zaretskii wrote:
>> 
>> > Right.  But if we merge ChangeLog.2 from the release branch to master,
>> > then this will produce a mess when "make change-history" is run on
>> > master, no?  I mean, some entries will appear twice, once after
>> > corrections, the other without.  No?
>> 
>> Quite possibly. I don't know exactly what happens if the commit hash
>> from the ChangeLog.2 footer were to get merged between branches.
>> 
>> I don't know how to solve this problem, but it seems to me that it needs
>> to be solved, and the more master and emacs-25 diverge, the worse it
>> gets.
>
> I agree.
>
> Perhaps Git gurus could help us out?  Andreas, any suggestions?

man git-log

	--cherry-pick
	    Omit any commit that introduces the same change as
	    another commit on the "other side" when the set of
	    commits are limited with symmetric difference.

	    For example, if you have two branches, A and B, a usual
	    way to list all commits on only one side of them is with
	    --left-right (see the example below in the description
	    of the --left-right option). However, it shows the
	    commits that were cherry-picked from the other branch
	    (for example, "3rd on b" may be cherry-picked from
	    branch A). With this option, such pairs of commits are
	    excluded from the output.

[...]

	--cherry
	    A synonym for --right-only --cherry-mark --no-merges;
	    useful to limit the output to the commits on our side
	    and mark those that have been applied to the other side
	    of a forked history with git log --cherry
	    upstream...mybranch, similar to git cherry upstream
	    mybranch.


-- 
David Kastrup

Re: make change-history on non-master branches

[Glenn Morris]

Eli Zaretskii wrote:

> Btw, one other issue that needs to be taken care of is
> admin/authors.el, which needs to be taught about top-level ChangeLog.2
> file.

Yes, I think there is a lot of work needed there.

http://debbugs.gnu.org/20337 has received zero interest to date.

Re: make change-history on non-master branches

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Glenn Morris <rgm@gnu.org>
>> Cc: eggert@cs.ucla.edu,  emacs-devel@gnu.org
>> Date: Wed, 18 Nov 2015 13:28:08 -0500
>> 
>> Eli Zaretskii wrote:
>> 
>> > Right.  But if we merge ChangeLog.2 from the release branch to master,
>> > then this will produce a mess when "make change-history" is run on
>> > master, no?  I mean, some entries will appear twice, once after
>> > corrections, the other without.  No?
>> 
>> Quite possibly. I don't know exactly what happens if the commit hash
>> from the ChangeLog.2 footer were to get merged between branches.

You get a merge conflict.

> Perhaps Git gurus could help us out?  Andreas, any suggestions?

You need to resolve the merge conflict one way or the other.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: make change-history on non-master branches

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: Glenn Morris <rgm@gnu.org>,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Thu, 19 Nov 2015 09:35:50 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Glenn Morris <rgm@gnu.org>
> >> Cc: eggert@cs.ucla.edu,  emacs-devel@gnu.org
> >> Date: Wed, 18 Nov 2015 13:28:08 -0500
> >> 
> >> Eli Zaretskii wrote:
> >> 
> >> > Right.  But if we merge ChangeLog.2 from the release branch to master,
> >> > then this will produce a mess when "make change-history" is run on
> >> > master, no?  I mean, some entries will appear twice, once after
> >> > corrections, the other without.  No?
> >> 
> >> Quite possibly. I don't know exactly what happens if the commit hash
> >> from the ChangeLog.2 footer were to get merged between branches.
> 
> You get a merge conflict.

Even if I have git-merge-changelog installed?

> > Perhaps Git gurus could help us out?  Andreas, any suggestions?
> 
> You need to resolve the merge conflict one way or the other.

Thanks.  Maybe we could get some help from gitmerge.el, even if that
would require some specific pattern in the log messages of commits
that correct ChangeLog.2.  David, WDYT?

Re: make change-history on non-master branches

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@suse.de>
>> Cc: Glenn Morris <rgm@gnu.org>,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
>> Date: Thu, 19 Nov 2015 09:35:50 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Glenn Morris <rgm@gnu.org>
>> >> Cc: eggert@cs.ucla.edu,  emacs-devel@gnu.org
>> >> Date: Wed, 18 Nov 2015 13:28:08 -0500
>> >> 
>> >> Eli Zaretskii wrote:
>> >> 
>> >> > Right.  But if we merge ChangeLog.2 from the release branch to master,
>> >> > then this will produce a mess when "make change-history" is run on
>> >> > master, no?  I mean, some entries will appear twice, once after
>> >> > corrections, the other without.  No?
>> >> 
>> >> Quite possibly. I don't know exactly what happens if the commit hash
>> >> from the ChangeLog.2 footer were to get merged between branches.
>> 
>> You get a merge conflict.
>
> Even if I have git-merge-changelog installed?

I don't know, but I would be surprised if it could handle that
correctly.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: make change-history on non-master branches

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: David Engster <deng@randomsample.de>,  rgm@gnu.org,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Thu, 19 Nov 2015 17:35:44 +0100
> 
> >> >> Quite possibly. I don't know exactly what happens if the commit hash
> >> >> from the ChangeLog.2 footer were to get merged between branches.
> >> 
> >> You get a merge conflict.
> >
> > Even if I have git-merge-changelog installed?
> 
> I don't know, but I would be surprised if it could handle that
> correctly.

Yes, that's exactly what I'm afraid of: a conflict-less merge that
does the wrong thing.

Thanks.

Re: make change-history on non-master branches

[David Engster]

Eli Zaretskii writes:
> Thanks.  Maybe we could get some help from gitmerge.el, even if that
> would require some specific pattern in the log messages of commits
> that correct ChangeLog.2.  David, WDYT?

Well, at least the current situation will have to be handled manually
for sure. If you now update ChangeLog.2 on emacs-25, you'll get lots of
entries which are already in the 'master' ChangeLog, but in unfixed
form. Not only that, but many of those commits have entered emacs-25 at
a different time, so the dates don't match up.

For further ChangeLog updates, at least in the current form, I don't see
how to automate this. IMHO, for automatic merges, we would need the
following:

- Generating the ChangeLog on the 'master' branch ignores commits from
  emacs-25 merges.

- Generating the ChangeLog on the 'emacs-25' branch ignores cherry-picks
  from 'master' (can be detected by git or through a magic word in the
  commit message).

- when cherry-picking from 'master', we copy the generated&fixed
  ChangeLog entry and commit it separately. Then gitmerge.el could skip
  that during the merge into master, just like it skips the backported
  commit itself.

-David

Re: make change-history on non-master branches

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: Andreas Schwab <schwab@suse.de>,  rgm@gnu.org,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Thu, 19 Nov 2015 20:48:15 +0100
> 
> For further ChangeLog updates, at least in the current form, I don't see
> how to automate this. IMHO, for automatic merges, we would need the
> following:
> 
> - Generating the ChangeLog on the 'master' branch ignores commits from
>   emacs-25 merges.
> 
> - Generating the ChangeLog on the 'emacs-25' branch ignores cherry-picks
>   from 'master' (can be detected by git or through a magic word in the
>   commit message).
> 
> - when cherry-picking from 'master', we copy the generated&fixed
>   ChangeLog entry and commit it separately. Then gitmerge.el could skip
>   that during the merge into master, just like it skips the backported
>   commit itself.

I'm not sure I understand the practical meaning of the last item
(which AFAIU is the only one that needs to be done by humans).  You
seem to say that each cherry-pick should require an update to
ChangeLog.2 both on master and on emacs-25, and application of fixes
to them?  Normally, ChangeLog.2 is updated once a week from Git, and
then whoever has a habit of looking at the results makes corrections
there when they feel like it.  So there's no guarantee that the
corrected entry is in place when you cherry-pick.  Moreover, the
person who cherry-picks does not necessarily know whether the log
message of the cherry-picked commit needs fixing, or how to fix it.

Or maybe I misunderstood the proposal.

Thanks.

Re: make change-history on non-master branches

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <deng@randomsample.de>
>> Cc: Andreas Schwab <schwab@suse.de>, rgm@gnu.org,
>> eggert@cs.ucla.edu, emacs-devel@gnu.org
>
>> Date: Thu, 19 Nov 2015 20:48:15 +0100
>> 
>> For further ChangeLog updates, at least in the current form, I don't see
>> how to automate this. IMHO, for automatic merges, we would need the
>> following:
>> 
>> - Generating the ChangeLog on the 'master' branch ignores commits from
>>   emacs-25 merges.
>> 
>> - Generating the ChangeLog on the 'emacs-25' branch ignores cherry-picks
>>   from 'master' (can be detected by git or through a magic word in the
>>   commit message).
>> 
>> - when cherry-picking from 'master', we copy the generated&fixed
>>   ChangeLog entry and commit it separately. Then gitmerge.el could skip
>>   that during the merge into master, just like it skips the backported
>>   commit itself.
>
> I'm not sure I understand the practical meaning of the last item
> (which AFAIU is the only one that needs to be done by humans).  You
> seem to say that each cherry-pick should require an update to
> ChangeLog.2 both on master and on emacs-25, and application of fixes
> to them?

Yes.

> Normally, ChangeLog.2 is updated once a week from Git, and then
> whoever has a habit of looking at the results makes corrections there
> when they feel like it.  So there's no guarantee that the corrected
> entry is in place when you cherry-pick.  Moreover, the person who
> cherry-picks does not necessarily know whether the log message of the
> cherry-picked commit needs fixing, or how to fix it.

I'm aware of these problems. But if you simply cherry-pick and let 'make
change-history' do its job on both branches, you will have to fix the
ChangeLog entry twice (preferably the same way), and you'll get a
conflict when you merge emacs-25 into master.

-David

Re: make change-history on non-master branches

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

On Thu, Nov 19, 2015 at 9:38 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Normally, ChangeLog.2 is updated once a week from Git, and
> then whoever has a habit of looking at the results makes corrections
> there when they feel like it.

Whoever has an habit of looking at the results and makes corrections (or at
least one specific instance of that "whoever") could refrain of doing so
during the pretest if it makes life easier for the whoevers who merge the
branches.

[-- Attachment #2: Type: text/html, Size: 611 bytes --]

Re: make change-history on non-master branches

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 20 Nov 2015 01:31:58 +0100
> Cc: David Engster <deng@randomsample.de>, schwab@suse.de, Paul Eggert <eggert@cs.ucla.edu>, 
> 	Emacs developers <emacs-devel@gnu.org>, Glenn Morris <rgm@gnu.org>
> 
> Whoever has an habit of looking at the results and makes corrections (or at
> least one specific instance of that "whoever") could refrain of doing so during
> the pretest if it makes life easier for the whoevers who merge the branches.

Alas, it's not just the pretest, it's the entire life time of the
release branch.  That life time is just starting for the emacs-25
branch; I'm quite certain that at lease Emacs 25.2 and probably also
25.3 will be delivered from that branch.  That's another 2 years.  I
don't think we want to wait that long for your useful corrections and
general loving care of ChangeLog.2 ;-)

I hope we will find a better solution to this.

Future release schedules (was: make change-history on non-master branches)

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> Alas, it's not just the pretest, it's the entire life time of the release
> branch. That life time is just starting for the emacs-25 branch; I'm quite
> certain that at lease Emacs 25.2 and probably also 25.3 will be delivered
> from that branch. That's another 2 years. I don't think we want to wait that
> long for your useful corrections and general loving care of ChangeLog.2 ;-)
>
> I hope we will find a better solution to this.

Once 25.1 is out -- and this could take up to six months -- I'd like us to
switch to a different process for point releases: A new .x release every two
months, with whatever bug fixes have been accomplished in that interim.

Once the emacs-25 branch is stable, say at 25.2, primary development would
resume on master towards emacs-26. However, bugs will continue to be fixed and
back-ported to emacs-25, with regular point releases from that branch, until
it's stable enough to no longer need our attention. Beyond that point, it
becomes a frozen branch -- unless a critical bug fix occurs justifying a point
release solely for that fix.

This requires a two-pronged approach: Attention to bugs on emacs-25, and
attention to new features coming into master from patches and feature
branches. This should allow us to maintain a faster turn-around time on bug
fix releases, while not holding up integration of new feature work towards the
next major release.

The intention here is to maximize the utility of Git, now that we have it, and
to make use of its branching, merging and cherry-picking capabilities to
accelerate development, without sacrificing attention to stability for the
current "release series". I like that we have gitmerge.el, for example; I hope
we can adapt our release process to take full advantage of it.

John

Re: Future release schedules (was: make change-history on non-master branches)

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Juanma Barranquero <lekktu@gmail.com>,  schwab@suse.de,  eggert@cs.ucla.edu,  rgm@gnu.org,  deng@randomsample.de,  emacs-devel@gnu.org
> Date: Fri, 20 Nov 2015 08:38:35 -0800
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Alas, it's not just the pretest, it's the entire life time of the release
> > branch. That life time is just starting for the emacs-25 branch; I'm quite
> > certain that at lease Emacs 25.2 and probably also 25.3 will be delivered
> > from that branch. That's another 2 years. I don't think we want to wait that
> > long for your useful corrections and general loving care of ChangeLog.2 ;-)
> >
> > I hope we will find a better solution to this.
> 
> Once 25.1 is out -- and this could take up to six months -- I'd like us to
> switch to a different process for point releases: A new .x release every two
> months, with whatever bug fixes have been accomplished in that interim.
> 
> Once the emacs-25 branch is stable, say at 25.2, primary development would
> resume on master towards emacs-26. However, bugs will continue to be fixed and
> back-ported to emacs-25, with regular point releases from that branch, until
> it's stable enough to no longer need our attention. Beyond that point, it
> becomes a frozen branch -- unless a critical bug fix occurs justifying a point
> release solely for that fix.

That's what we did with emacs-24 branch as well.  So this is not a new
process, it's a continuation of the process we've been practicing for
several years.

> The intention here is to maximize the utility of Git, now that we have it, and
> to make use of its branching, merging and cherry-picking capabilities to
> accelerate development, without sacrificing attention to stability for the
> current "release series". I like that we have gitmerge.el, for example; I hope
> we can adapt our release process to take full advantage of it.

We had all that before, with Bazaar as well.

Re: Future release schedules

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> That's what we did with emacs-24 branch as well. So this is not a new
> process, it's a continuation of the process we've been practicing for
> several years.

Ok, great, I didn't know.

> We had all that before, with Bazaar as well.

All responses to emacs-tangents, please. :)

John

Re: Future release schedules (was: make change-history on non-master branches)

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

> That's what we did with emacs-24 branch as well.  So this is not a new
> process, it's a continuation of the process we've been practicing for
> several years.
>

Really? I recall the 24.5 release had quite a bit of new content (not just
bug fixes). Were people adding this new content to the release branch or
was 24.5 branched off from master instead of from emacs-24?

[-- Attachment #2: Type: text/html, Size: 448 bytes --]

Re: Future release schedules (was: make change-history on non-master branches)

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

On 20 Nov 2015 6:41 pm, "Artur Malabarba" <bruce.connor.am@gmail.com> wrote:
>
> > That's what we did with emacs-24 branch as well.  So this is not a new
> > process, it's a continuation of the process we've been practicing for
> > several years.
> >
>
> Really? I recall the 24.5 release had quite a bit of new content

Sorry. Here I meant 24.4.

[-- Attachment #2: Type: text/html, Size: 532 bytes --]

Re: Future release schedules (was: make change-history on non-master branches)

[Eli Zaretskii]

> Date: Fri, 20 Nov 2015 18:41:30 +0000
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: schwab@suse.de, emacs-devel <emacs-devel@gnu.org>, John Wiegley <jwiegley@gmail.com>, 
> 	lekktu@gmail.com, rgm@gnu.org, deng@randomsample.de, eggert@cs.ucla.edu
> 
> > That's what we did with emacs-24 branch as well. So this is not a new
> > process, it's a continuation of the process we've been practicing for
> > several years.
> 
> Really? I recall the 24.5 release had quite a bit of new content (not just bug
> fixes).

No, v24.5 was a pure bugfix release.  The previous 24.x releases saw
some small amount of changes.  See NEWS.24.

Re: Future release schedules (was: make change-history on non-master branches)

[Eli Zaretskii]

Actually, if you really mean zero changes on the emacs-25 branch that
are not bugfixes, that's indeed not what we have been doing in the
past, and I expect it to be a hard sell to the community.  With the
time between major release around 4 to 5 years on the average, I don't
think we can let users wait so long for small improvements.  The
emacs-24 branch allowed changes that were deemed "safe" (the exact
meaning of that needs a judgment call, of course).

IOW, I think we can only switch to this model if we drastically reduce
the time interval between major releases, to something like a year or
less, or if we start maintaining 3 branches, not 2.  Both alternatives
require radical changes in the process and the procedures, to say
nothing about the manpower.

Re: Future release schedules

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> IOW, I think we can only switch to this model if we drastically reduce the
> time interval between major releases, to something like a year or less, or
> if we start maintaining 3 branches, not 2. Both alternatives require radical
> changes in the process and the procedures, to say nothing about the
> manpower.

I'd like to cut new major releases once a year, even if they only introduce a
few new features. That is, there should always be two active branches: the
current release branch, and 'master' leading up to the next release branch.

There could also be a third branch, the previous release (i.e., emacs-24 right
now), if we really want to nail stability for people still on that version,
but I expect involvement on such a branch to remain low.

I'm not sure this requires a radical change in process and procedure. We keep
doing what we're doing today, we just release with shorter NEWS entries.

John

Re: Future release schedules

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: bruce.connor.am@gmail.com,  rgm@gnu.org,  eggert@cs.ucla.edu,  deng@randomsample.de,  lekktu@gmail.com,  emacs-devel@gnu.org,  schwab@suse.de
> Date: Fri, 20 Nov 2015 11:14:46 -0800
> 
> I'd like to cut new major releases once a year, even if they only introduce a
> few new features.
> [...]
> I'm not sure this requires a radical change in process and procedure.

I think it does, because currently putting out a major release takes
between 6 and 10 months.  That leaves no time for working on any
significant new features, because who if not the most dedicated
developers are the driving force behind making a new major version
release-grade stable?  We don't have enough manpower to divide the
efforts between 2 branches while working on a major release.

Re: Future release schedules

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> I think it does, because currently putting out a major release takes between
> 6 and 10 months. That leaves no time for working on any significant new
> features, because who if not the most dedicated developers are the driving
> force behind making a new major version release-grade stable? We don't have
> enough manpower to divide the efforts between 2 branches while working on a
> major release.

Ok, how about a tick-tock schedule then, while we lack such manpower? Release
focus year 1, next release feature focus year 2, etc. Perhaps this is even
what you meant.

John

Re: Future release schedules

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: bruce.connor.am@gmail.com,  rgm@gnu.org,  eggert@cs.ucla.edu,  deng@randomsample.de,  lekktu@gmail.com,  emacs-devel@gnu.org,  schwab@suse.de
> Date: Fri, 20 Nov 2015 13:33:20 -0800
> 
> Ok, how about a tick-tock schedule then, while we lack such manpower? Release
> focus year 1, next release feature focus year 2, etc. Perhaps this is even
> what you meant.

We could try that.  It all depends on how long it takes to develop and
integrate a few significant features.  Based on recent experience, a
year might not be enough, but we could set that as a goal and see
where it takes us.

Re: make change-history on non-master branches

[Glenn Morris]

Glenn Morris wrote:

> I don't know how to solve this problem, but it seems to me that it needs
> to be solved, and the more master and emacs-25 diverge, the worse it
> gets.

Over a month has passed with no merge from release branch to master.

Still, at least we seem to have finally found a way to get more people
to use the release branch! ;)

Re: make change-history on non-master branches

[Paul Eggert]

Glenn Morris wrote:
> Over a month has passed with no merge from release branch to master.
>
> Still, at least we seem to have finally found a way to get more people
> to use the release branch!;)

The *exact same* thought had occurred to me, and that's why fixing merges has 
been lower priority for me.

I have made only a bit of progress since my last proposed patch in this area, 
and will eventually propose a revised patch. Perhaps the best bet will be for me 
to just do a merge, which will undoubtedly have problems, and then we can fix 
the problems and come up with a revised merge procedure after that. It may well 
take two or more merges to get it right.

Re: make change-history on non-master branches

[Glenn Morris]

Thanks for working on this.

Re: make change-history on non-master branches

[John Wiegley]

>>>>> Glenn Morris <rgm@gnu.org> writes:

> Thanks for working on this.

Yes, thank you, Paul, and can you keep me up-to-date on where you are with
this? I'd like to get merges going on my machine too, it just hasn't happened
yet.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: make change-history on non-master branches

[Paul Eggert]

John Wiegley wrote:
> Yes, thank you, Paul, and can you keep me up-to-date on where you are with
> this?

Will do, the next time I make progress. Currently lagging because it is the 
holiday season, and my development machine's power supply died and I wasted time 
fixing it and upgrading to Fedora 23, plus I have real work to do. The usual 
story. But I should be able to make progress on it after Christmas.

Re: make change-history on non-master branches

[Glenn Morris]

I see this is being discussed again, but for some reason with no obvious
reference to the previous discussion we had that explained what the
problems were, nor the solution that was apparently being worked on.

Ref http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01461.html
http://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00914.html

Re: make change-history on non-master branches

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Mon, 25 Jan 2016 11:55:54 -0500
> 
> I see this is being discussed again, but for some reason with no obvious
> reference to the previous discussion we had that explained what the
> problems were, nor the solution that was apparently being worked on.
> 
> Ref http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01461.html
> http://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00914.html

The solution is not ready yet, and we did conclude that the solution
will have to happen on master, not on the branch.  So I see no reasons
not to invoke that target on the branch.  Moreover, it is a must to do
so when preparing a pretest, which is what Nicolas does.