Marking changes to be backported

Marking changes to be backported

[Glenn Morris]

Stefan Monnier wrote:

> I think it's too late to do that for Emacs-24.4.  But we should apply
> such a change to `emacs-24' after the 24.4 release, so that it will be
> included in the next release regardless if the next release is 25.1 or
> a 24.5 bugfix.

There needs to be an agreed convention to mark trunk changes that should
be backported to the release branch at some later date. "Remember to do
it" doesn't scale.

A note in the commit log would do, but it should have some kind of
standard format. But if we only realize after the commit was made,
some other method is needed. Either a file in admin, or perhaps a git
notes file.

Re: Marking changes to be backported

[Glenn Morris]

A simple file in admin would do, one revision per line.
Someone could write a script to backport (labelling the commit with
"Backport...") each revision from trunk and remove it from the input
file.

Re: Marking changes to be backported

[Stefan Monnier]

> There needs to be an agreed convention to mark trunk changes that should
> be backported to the release branch at some later date. "Remember to do
> it" doesn't scale.

If it's really needed, we can have a "emacs-24-next" branch for that.
Then we merge emacs-24 into emacs-24-next, and then we merge
emacs-24-next into trunk.

But a few notes in an `admin' file sounds fine for now.


        Stefan

Re: Marking changes to be backported

[Glenn Morris]

Stefan Monnier wrote:

>> There needs to be an agreed convention to mark trunk changes that should
>> be backported to the release branch at some later date. "Remember to do
>> it" doesn't scale.
>
> If it's really needed, we can have a "emacs-24-next" branch for that.

I think it will be needed if: there are to be pure bug-fix releases, and
pretesting is going to continue to take months, and development is going
to continue at the same time. (There are probably tons of things fixed
in trunk today that should go into version 24.5, if there is one. Who's
going to dig them all out and backport them? No-one.)

> Then we merge emacs-24 into emacs-24-next, and then we merge
> emacs-24-next into trunk.

Yet more branches sounds more complicated to me (doesn't that mean you
need to know when you make a change where it should go?), but I don't
care about the system so long as there is one.

Re: Marking changes to be backported

[Stefan Monnier]

> Yet more branches sounds more complicated to me (doesn't that mean you
> need to know when you make a change where it should go?),

One way or another, someone will have to decide which change goes "in
the current pretest" (let's call it 24.4), "in the next bug-fix" (let's
call it 24.5), or "longer term" (let's call it 25.1).

If the committer knows before committing where that change should go,
then having 3 branches and committing to the proper branch is the
best solution.

If that's not the case, then having 3 branches doesn't help, indeed,
since the commit will have to be backported to the proper branch, if
applicable.  Note that this "backporting" will take place regardless of
whether we have 3 branches active at a time or not.  Having 3 branches
active at a time, does allow the backporting to be done any time you
want, whereas sticking to the "trunk vs emacs-24" scheme we have simply
means that some of the backporting will only take place once the
"emacs-24" branch is changed from "branch for 24.4" to "branch for
24.5".


        Stefan

Re: Marking changes to be backported

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Mon, 06 Oct 2014 02:37:30 -0400
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> Stefan Monnier wrote:
> 
> >> There needs to be an agreed convention to mark trunk changes that should
> >> be backported to the release branch at some later date. "Remember to do
> >> it" doesn't scale.
> >
> > If it's really needed, we can have a "emacs-24-next" branch for that.
> 
> I think it will be needed if: there are to be pure bug-fix releases, and
> pretesting is going to continue to take months, and development is going
> to continue at the same time. (There are probably tons of things fixed
> in trunk today that should go into version 24.5, if there is one. Who's
> going to dig them all out and backport them? No-one.)
> 
> > Then we merge emacs-24 into emacs-24-next, and then we merge
> > emacs-24-next into trunk.
> 
> Yet more branches sounds more complicated to me (doesn't that mean you
> need to know when you make a change where it should go?), but I don't
> care about the system so long as there is one.

I think using another (3rd) branch is on balance the most reliable and
least error prone method.  It is also much less effort to merge
between branches than to cherry-pick.

Re: Marking changes to be backported

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 06 Oct 2014 09:25:49 -0400
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > Yet more branches sounds more complicated to me (doesn't that mean you
> > need to know when you make a change where it should go?),
> 
> One way or another, someone will have to decide which change goes "in
> the current pretest" (let's call it 24.4), "in the next bug-fix" (let's
> call it 24.5), or "longer term" (let's call it 25.1).

The dilemma is only between the 2 out of 3 branches, those that get
bugfixes.  One of them should only get very safe fixes for serious
problems, which should then be merged to the other.

As for trunk vs the other 2 branches, I think the decision is simple:
new features and changes that don't fix bugs go to trunk only.

Re: Marking changes to be backported

[Glenn Morris]

Stefan Monnier wrote:

> One way or another, someone will have to decide which change goes "in
> the current pretest" (let's call it 24.4), "in the next bug-fix" (let's
> call it 24.5), or "longer term" (let's call it 25.1).

I was hoping that this was something that everyone would think about,
not just a singular someone, and that's why I wanted there to be a
system in place.

Re: Marking changes to be backported

[Stefan Monnier]

>> One way or another, someone will have to decide which change goes "in
>> the current pretest" (let's call it 24.4), "in the next bug-fix" (let's
>> call it 24.5), or "longer term" (let's call it 25.1).
> I was hoping that this was something that everyone would think about,
> not just a singular someone, and that's why I wanted there to be a
> system in place.

I hope so too: I meant "someone" per patch.


        Stefan