Moving Emacs 24.3 development to emacs-24 branch soon

Moving Emacs 24.3 development to emacs-24 branch soon

[Chong Yidong]

We are one month into the feature freeze.  As previously discussed, it's
time to move Emacs 24.3 development to the emacs-24 branch.

Here is the planned procedure:

1. In the `emacs-24' branch, `bzr tag emacs-24.3-base'.  This creates a
   `emacs-24.3-base' tag for the current contents of the emacs-24 branch
   (which has accumulated ~40 commits since the 24.2 release), for the
   unlikely event that we need it again.

2. In the `trunk' branch, 
   bzr push bzr+ssh://NAME@bzr.savannah.gnu.org/emacs/emacs-24
   This pushes the contents of `trunk' into `emacs-24'.

3. Once this is done, I'll announce the switch on emacs-devel, and open
   trunk for non-bugfix changes (though pervasive changes which would
   inhibit merging from emacs-24 would still be discouraged).

   Right after the switch, the commit policy for the emacs-24 branch
   will be "bug fixes for regressions against Emacs 23 only", with
   exceptions on a case by case basis.

Let me know if you see any flaws with the above.  Otherwise, I'll make
the switch sometime in the next 12 hours.  For sanity, please refrain
from making any commits to the emacs-24 branch from now until after the
switch is announced.

Re: Moving Emacs 24.3 development to emacs-24 branch soon

[Andreas Schwab]

Chong Yidong <cyd@gnu.org> writes:

> 1. In the `emacs-24' branch, `bzr tag emacs-24.3-base'.  This creates a
>    `emacs-24.3-base' tag for the current contents of the emacs-24 branch
>    (which has accumulated ~40 commits since the 24.2 release), for the
>    unlikely event that we need it again.

You should create a branch instead.  Your second step will lose the tag.

> 2. In the `trunk' branch, 
>    bzr push bzr+ssh://NAME@bzr.savannah.gnu.org/emacs/emacs-24
>    This pushes the contents of `trunk' into `emacs-24'.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Moving Emacs 24.3 development to emacs-24 branch soon

[Dani Moncayo]

>> 1. In the `emacs-24' branch, `bzr tag emacs-24.3-base'.  This creates a
>>    `emacs-24.3-base' tag for the current contents of the emacs-24 branch
>>    (which has accumulated ~40 commits since the 24.2 release), for the
>>    unlikely event that we need it again.
>
> You should create a branch instead.  Your second step will lose the tag.
>
>> 2. In the `trunk' branch,
>>    bzr push bzr+ssh://NAME@bzr.savannah.gnu.org/emacs/emacs-24
>>    This pushes the contents of `trunk' into `emacs-24'.

Also, Andreas' proposal of creating a new branch would avoid the
problem I pointed out here
http://lists.gnu.org/archive/html/emacs-devel/2012-08/msg00672.html


-- 
Dani Moncayo

Re: Moving Emacs 24.3 development to emacs-24 branch soon

[Chong Yidong]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> 1. In the `emacs-24' branch, `bzr tag emacs-24.3-base'.  This creates a
>>    `emacs-24.3-base' tag for the current contents of the emacs-24 branch
>>    (which has accumulated ~40 commits since the 24.2 release), for the
>>    unlikely event that we need it again.
>
> You should create a branch instead.  Your second step will lose the tag.

The problem is the naming.  It is desireable for the branch where the
24.3 work is done to be called emacs-24.

How about branching emacs-24 to emacs-24-fallback before pushing trunk
into emacs-24?

Re: Moving Emacs 24.3 development to emacs-24 branch soon

[Dani Moncayo]

>>> 1. In the `emacs-24' branch, `bzr tag emacs-24.3-base'.  This creates a
>>>    `emacs-24.3-base' tag for the current contents of the emacs-24 branch
>>>    (which has accumulated ~40 commits since the 24.2 release), for the
>>>    unlikely event that we need it again.
>>
>> You should create a branch instead.  Your second step will lose the tag.
>
> The problem is the naming.  It is desireable for the branch where the
> 24.3 work is done to be called emacs-24.
>
> How about branching emacs-24 to emacs-24-fallback before pushing trunk
> into emacs-24?

Surely I'm missing something, but as I tried to say, I think that
every "xx.y" released version of Emacs should have its own
"emacs-xx.y" bzr branch, cut off from the trunk at the release date.

-- 
Dani Moncayo

Re: Moving Emacs 24.3 development to emacs-24 branch soon

[Stefan Monnier]

>> You should create a branch instead.  Your second step will lose the tag.

I doubt we'll lose the tag because of a push.  If anything, getting rid
of a Bzr tag is incredibly difficult.

>>> 2. In the `trunk' branch,
>>> bzr push bzr+ssh://NAME@bzr.savannah.gnu.org/emacs/emacs-24
>>> This pushes the contents of `trunk' into `emacs-24'.

> Also, Andreas' proposal of creating a new branch would avoid the
> problem I pointed out here
> http://lists.gnu.org/archive/html/emacs-devel/2012-08/msg00672.html

The format of Emacs version numbers is used at various places, so we'd
rather not change it.  I.e. pretests will be "NN.MM.PP" and releases
will be "NN.MM".  But we could release the trunk as Emacs-25.1 instead
of Emacs-24.3.
OTOH, I do not intend to release a 24.3 that's not cut from the
current trunk.  It would have to be a truly super-extra incredibly
urgent bug-fix to justify such measures.  IOW I wouldn't even bother
with the "emacs-24-base" tag, since if we really need to take such
extreme measures, finding the "last revision on emacs-24 before the
merge from trunk" would be a trivial part of the work ("bzr log, look
for the merge message").


        Stefan

Re: Moving Emacs 24.3 development to emacs-24 branch soon

[Andreas Schwab]

Chong Yidong <cyd@gnu.org> writes:

> 2. In the `trunk' branch, 
>    bzr push bzr+ssh://NAME@bzr.savannah.gnu.org/emacs/emacs-24
>    This pushes the contents of `trunk' into `emacs-24'.

This won't work anyway, due to the append-only policy.

> Let me know if you see any flaws with the above.

The only sane way is to create a new release branch.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Moving Emacs 24.3 development to emacs-24 branch soon

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Date: Thu, 01 Nov 2012 10:12:16 +0800
> 
> 2. In the `trunk' branch, 
>    bzr push bzr+ssh://NAME@bzr.savannah.gnu.org/emacs/emacs-24
>    This pushes the contents of `trunk' into `emacs-24'.

I don't think you can do that.  "push" is only possible from a branch
that didn't diverge from the target.  You should "merge" (from trunk
to emacs-24) instead, and then commit.

However, merging will probably mess up the history in a way that will
make forensics difficult.  So I agree with Andreas and Dani who
proposed a separate branch instead.

Re: Moving Emacs 24.3 development to emacs-24 branch soon

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>>    bzr push bzr+ssh://NAME@bzr.savannah.gnu.org/emacs/emacs-24
>>    This pushes the contents of `trunk' into `emacs-24'.
>
> I don't think you can do that.  "push" is only possible from a branch
> that didn't diverge from the target.  You should "merge" (from trunk
> to emacs-24) instead, and then commit.
>
> However, merging will probably mess up the history in a way that will
> make forensics difficult.  So I agree with Andreas and Dani who
> proposed a separate branch instead.

As Stefan pointed out to me in a separate email, pushing will work, one
just has to set the bzr configuration variable append_revisions_only to
False.  The bzr tag doesn't seem to be discarded by the push, either; it
is still possible to check it out with -r TAGNAME afterward.

Re: Moving Emacs 24.3 development to emacs-24 branch soon

[Andreas Schwab]

Chong Yidong <cyd@gnu.org> writes:

> As Stefan pointed out to me in a separate email, pushing will work, one
> just has to set the bzr configuration variable append_revisions_only to
> False.

One more reason this should never be done.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Moving Emacs 24.3 development to emacs-24 branch soon

[Stephen J. Turnbull]

Chong Yidong writes:

 > As Stefan pointed out to me in a separate email, pushing will work, one
 > just has to set the bzr configuration variable append_revisions_only to
 > False.  The bzr tag doesn't seem to be discarded by the push, either; it
 > is still possible to check it out with -r TAGNAME afterward.

Just because you can do it doesn't mean you should.

It is best current practice, accepted in many projects, to make a
branch for each feature release.  The primary rationale (keeping
bugfix and security releases in different release branches from
stepping on each other, and keeping feature code from accidentally
leaking across releases) doesn't apply to Emacs since Emacs only
supports one release at a time.  Nevertheless, third parties do
maintain such branches for various reasons.  Things are simpler for
everybody if each release has its own branch.

Rebasing also theoretically messes up the bloodlines.  The code in the
24.3 release is *not* a child of the 24.2 release, it is a sibling.
The rebase ends up unnecessarily duplicating all the history on the
trunk in the branch.

If you have some specific benefit of rebasing onto the existing minor
release branch, OK, I don't see a *high* probability of *serious*
trouble from doing it.  But I don't really see any benefit from it,
except preserving a formal linearity of the 24.x branch, which doesn't
reflect the way development actually occurred.

Steve

Re: Moving Emacs 24.3 development to emacs-24 branch soon

[Glenn Morris]

Chong Yidong wrote:

> For sanity, please refrain from making any commits to the emacs-24
> branch from now until after the switch is announced.

Sorry, auto-commit did a commit via cron. I'll disable it in emacs-24
for now.

Re: Moving Emacs 24.3 development to emacs-24 branch soon

[Stefan Monnier]

> Rebasing also theoretically messes up the bloodlines.  The code in the
> 24.3 release is *not* a child of the 24.2 release, it is a sibling.

You're confused.  There is no rebasing going on.  The `push' will work
just fine because we've merged the emacs-24 branch into trunk (and have
done so regularly).
The only reason append_revisions_only needs to be switched off is
because this `push' will swap the mainline.


        Stefan

Re: Moving Emacs 24.3 development to emacs-24 branch soon

[Stephen J. Turnbull]

Stefan Monnier writes:
 > > Rebasing also theoretically messes up the bloodlines.  The code in the
 > > 24.3 release is *not* a child of the 24.2 release, it is a sibling.
 > 
 > You're confused.  There is no rebasing going on.  The `push' will
 > work just fine because we've merged the emacs-24 branch into trunk
 > (and have done so regularly).

Should have put quotes on "rebase".  The problems here are conceptual,
not technical.

 > The only reason append_revisions_only needs to be switched off is
 > because this `push' will swap the mainline.

That sounds like a bad idea to me, but looking at the graphs of
emacs-24 and the trunk, I guess it won't be a problem.  Good luck!

Re: Moving Emacs 24.3 development to emacs-24 branch soon

[Eli Zaretskii]

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

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Sat, 03 Nov 2012 21:28:21 +0900
> Cc: Eli Zaretskii <eliz@gnu.org>, Chong Yidong <cyd@gnu.org>,
> 	emacs-devel@gnu.org
> 
>  > The only reason append_revisions_only needs to be switched off is
>  > because this `push' will swap the mainline.
> 
> That sounds like a bad idea to me, but looking at the graphs of
> emacs-24 and the trunk, I guess it won't be a problem.

Actually, I find the graph of emacs-24 to be confusingly obscure.  See
the attached screenshots of "bzr qlog", where simple merges from (the
old) emacs-24 are now displayed as something utterly weird, and
backports from trunk look weirder still.

But since Stefan made it clear, both in the past and now, that he
isn't bothered by these "minor details", I see no reason to discuss
this any further.


[-- Attachment #2: qlog1.PNG --]
[-- Type: image/png, Size: 50234 bytes --]

[-- Attachment #3: qlog2.PNG --]
[-- Type: image/png, Size: 73659 bytes --]

[-- Attachment #4: qlog3.PNG --]
[-- Type: image/png, Size: 58278 bytes --]

[-- Attachment #5: qlog4.PNG --]
[-- Type: image/png, Size: 61295 bytes --]

Re: Moving Emacs 24.3 development to emacs-24 branch soon

[Juanma Barranquero]

On Sun, Nov 4, 2012 at 6:28 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> But since Stefan made it clear, both in the past and now, that he
> isn't bothered by these "minor details", I see no reason to discuss
> this any further.

Oh, don't worry too much. Given the current state of Bzr development,
soon we'll be discussing whether to switch to git or mercurial...

Only half joking,

    Juanma

Re: Moving Emacs 24.3 development to emacs-24 branch soon

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Actually, I find the graph of emacs-24 to be confusingly obscure.  See
 > the attached screenshots of "bzr qlog", where simple merges from (the
 > old) emacs-24 are now displayed as something utterly weird, and
 > backports from trunk look weirder still.

I don't understand what you find weird or "not simple" about these.
They indicate quite clearly what's happened.  In both cases the theme
is "work on a branch, test, and only when happy merge to mainline."
Yidong made a separate branch for the purpose of merging two public
branches.  Ken'ichi made a "feature" branch to develop some fixes.  If
you don't find that information useful, ignore it.  (Eg, use bzr log
--omit-merges.)  Is there some sense that it gets in your way?

(I had already written the following, but really the above summary is
what's relevant.  But if you're curious about how I interpret the
DAGs, read on.)

In your first screenshot, it seems that at r110121 Yidong simply made
a branch to ensure that any merge screwups didn't make it to trunk.
He then merged emacs-24 into the temporary branch at r110121.1.  He
made no mistakes and upon inspection the merge looked correct (ie, I
suppose he did a test build etc., and inspected the commit log to make
sure no emacs-24-only commits were added (from the word "backport" I
wonder about 107781.350, but I don't have all the context of that
patch).  So he merged the temporary branch back into trunk without
making any new commits himself.  It's possible that he had to fix
merge conflicts, but I would assume if he did it would be noted in the
log.

In the second one, the yellow branch created at r110016 appears to be
a "miscellaneous fix" branch that Ken'ichi is using as a testing
workspace or similar.  So he regularly merges up to trunk head, does
more work, and remerges from the branch to trunk.

I agree the duplicate commit messages do look weird, but every one of
them actually corresponds to a single commit on the branch, then
merged back to the trunk.  It is considered best practice in bzr to
provide a summary of the branch being merged so that bzr log -n1 gives
a "big picture" of the work being merged.  Since Ken'ichi is
committing a single change then merging, I think simply copying the
message makes sense.  If that bugs people, then Emacs could make a
style guide for commit messages that says "If you have multiple
commits, summarize in the merge log.  If there's only one, you can
copy that message, but prepend '(merge) '."  Or something like that.