Starting the Emacs 27 release cycle

Starting the Emacs 27 release cycle

[Eli Zaretskii]

I'm planning on cutting the emacs-27 release branch in a week or so.
If someone has plans for changes that must be done before that, so
that they end up in Emacs 27.1, please make it happen till then, or
ask here for an extension.  After the branch is cut, only bugfixes
will be allowed on the release branch, per our usual practices (see
CONTRIBUTE).

Thanks.

Re: Starting the Emacs 27 release cycle

[Robert Pluim]

>>>>> On Sat, 23 Nov 2019 18:59:39 +0200, Eli Zaretskii <eliz@gnu.org> said:

    Eli> I'm planning on cutting the emacs-27 release branch in a week or so.
    Eli> If someone has plans for changes that must be done before that, so
    Eli> that they end up in Emacs 27.1, please make it happen till then, or
    Eli> ask here for an extension.  After the branch is cut, only bugfixes
    Eli> will be allowed on the release branch, per our usual practices (see
    Eli> CONTRIBUTE).

Iʼll push the change for the default value of
network-stream-use-client-certificates this weekend.

Iʼd like to get the network-interface-list change in as well, but that
might be too risky. It works for me on various GNU/Linux
distributions, and in my Windows VM, but I haven't seen any feedback
on it.

Robert

Re: Starting the Emacs 27 release cycle

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 23 Nov 2019 18:25:28 +0100
> 
> Iʼd like to get the network-interface-list change in as well, but that
> might be too risky. It works for me on various GNU/Linux
> distributions, and in my Windows VM, but I haven't seen any feedback
> on it.

I'd say merge it, and let's take it from there.  We can always revert
if push comes to shove, but since it worked for you, I think that's
unlikely.

Thanks.

Re: Starting the Emacs 27 release cycle

[Robert Pluim]

>>>>> On Sat, 23 Nov 2019 19:41:48 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: emacs-devel@gnu.org
    >> Date: Sat, 23 Nov 2019 18:25:28 +0100
    >> 
    >> Iʼd like to get the network-interface-list change in as well, but that
    >> might be too risky. It works for me on various GNU/Linux
    >> distributions, and in my Windows VM, but I haven't seen any feedback
    >> on it.

    Eli> I'd say merge it, and let's take it from there.  We can always revert
    Eli> if push comes to shove, but since it worked for you, I think that's
    Eli> unlikely.

OK, Iʼll do that once savannah is back up.

Robert

Re: Starting the Emacs 27 release cycle

[Philipp Stephani]

Am Sa., 23. Nov. 2019 um 18:01 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> I'm planning on cutting the emacs-27 release branch in a week or so.
> If someone has plans for changes that must be done before that, so
> that they end up in Emacs 27.1, please make it happen till then, or
> ask here for an extension.  After the branch is cut, only bugfixes
> will be allowed on the release branch, per our usual practices (see
> CONTRIBUTE).


As detailed in https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg00444.html,
I'd request to wait until the module interface for big integers is
sorted out.

Thanks!

Re: Starting the Emacs 27 release cycle

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 23 Nov 2019 21:02:30 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> As detailed in https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg00444.html,
> I'd request to wait until the module interface for big integers is
> sorted out.

Do you have an ETA for that?  Any chance for sorting this out this
week?

Thanks.

Re: Starting the Emacs 27 release cycle

[Philipp Stephani]

Am So., 24. Nov. 2019 um 04:30 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Sat, 23 Nov 2019 21:02:30 +0100
> > Cc: Emacs developers <emacs-devel@gnu.org>
> >
> > As detailed in https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg00444.html,
> > I'd request to wait until the module interface for big integers is
> > sorted out.
>
> Do you have an ETA for that?  Any chance for sorting this out this
> week?

It depends on whether you want to get Paul's approval.

Re: Starting the Emacs 27 release cycle

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Mon, 25 Nov 2019 22:48:27 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> Am So., 24. Nov. 2019 um 04:30 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
> >
> > > From: Philipp Stephani <p.stephani2@gmail.com>
> > > Date: Sat, 23 Nov 2019 21:02:30 +0100
> > > Cc: Emacs developers <emacs-devel@gnu.org>
> > >
> > > As detailed in https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg00444.html,
> > > I'd request to wait until the module interface for big integers is
> > > sorted out.
> >
> > Do you have an ETA for that?  Any chance for sorting this out this
> > week?
> 
> It depends on whether you want to get Paul's approval.

AFAIU, you and Paul are discussing some aspects of this, and it's up
to you two when and how to finish the discussion.  I'm not waiting for
approval for anything I asked in this matter.

Re: Starting the Emacs 27 release cycle

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm planning on cutting the emacs-27 release branch in a week or so.
> If someone has plans for changes that must be done before that, so
> that they end up in Emacs 27.1, please make it happen till then, or
> ask here for an extension.  After the branch is cut, only bugfixes
> will be allowed on the release branch, per our usual practices (see
> CONTRIBUTE).

A few months ago I made changes to Gnus so that non-ascii group names
(which used to mostly stay encoded) were mostly decoded. But I preserved
the original odd encoding in Gnus' persistence files, so that developers
could move back and forth between Emacs versions.

For the 27.1 release I'd like to use Gnus' upgrade mechanism to switch
to properly-encoded persistence files. The mechanism includes a prompt
to the user, so they'll be aware of what happened, and it will only
affect Gnus users with non-ascii group names. But it would mean that
those users couldn't switch back to Emacs 26 without seeing encoding
weirdness.

Hope that's okay...

Eric

Re: Starting the Emacs 27 release cycle

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Sat, 23 Nov 2019 13:30:35 -0800
> Cc: Lars Ingebrigtsen <larsi@gnus.org>
> 
> A few months ago I made changes to Gnus so that non-ascii group names
> (which used to mostly stay encoded) were mostly decoded. But I preserved
> the original odd encoding in Gnus' persistence files, so that developers
> could move back and forth between Emacs versions.
> 
> For the 27.1 release I'd like to use Gnus' upgrade mechanism to switch
> to properly-encoded persistence files. The mechanism includes a prompt
> to the user, so they'll be aware of what happened, and it will only
> affect Gnus users with non-ascii group names. But it would mean that
> those users couldn't switch back to Emacs 26 without seeing encoding
> weirdness.
> 
> Hope that's okay...

I don't know enough about Gnus to have an opinion about the potential
risks in this change.  So I'll leave it to you, Lars, and the rest of
the Gnus team to make the decision whether this should be in Emacs 27
or not.

Thanks.

Re: Starting the Emacs 27 release cycle

[Juri Linkov]

> I'm planning on cutting the emacs-27 release branch in a week or so.
> If someone has plans for changes that must be done before that, so
> that they end up in Emacs 27.1, please make it happen till then, or
> ask here for an extension.  After the branch is cut, only bugfixes
> will be allowed on the release branch, per our usual practices (see
> CONTRIBUTE).

The remaining tabs feature is to add support for a new display action
display-buffer-in-tab for display-buffer-alist to be implemented in
bug#38354 that takes about a week.

PS: I also have an unfinished implementation of more fancy looking tabs
with rounded corners that would take more than 2 weeks to complete
but this is of lesser importance and thus has lower priority.

Re: Starting the Emacs 27 release cycle

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

> PS: I also have an unfinished implementation of more fancy looking tabs
> with rounded corners that would take more than 2 weeks to complete
> but this is of lesser importance and thus has lower priority.

That sounds very nice, and will help Emacs look more modern and user
friendly.  Is there any way to make an exception to include this on
the Emacs 27.1 branch?  It's hard to imagine that it would drastically
affect the stability of that branch, in my opinion.  OTOH, of course,
this is a slippery slope.  Please shoot my idea down if it's not
wanted.

Best regards,
Stefan Kangas

Re: Starting the Emacs 27 release cycle

[Phil Sainty]

On 2019-11-24 12:49, Stefan Kangas wrote:
> Juri Linkov <juri@linkov.net> writes:
> 
>> PS: I also have an unfinished implementation of more fancy looking
>> tabs with rounded corners that would take more than 2 weeks to
>> complete but this is of lesser importance and thus has lower
>> priority.
> 
> That sounds very nice, and will help Emacs look more modern and user
> friendly.  Is there any way to make an exception to include this on
> the Emacs 27.1 branch?

I've just tried the tab modes for the first time, and would describe
the current default look as "functional", so if the proposed fancier
look is a substantial improvement, then I'd be in favour of either
allowing the extra time to develop them, or else allowing them to be
merged later as bug-fixes.

Perhaps it would be useful to see a screenshot showing the difference?


-Phil

Re: Starting the Emacs 27 release cycle

[Juri Linkov]

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

>>> PS: I also have an unfinished implementation of more fancy looking
>>> tabs with rounded corners that would take more than 2 weeks to
>>> complete but this is of lesser importance and thus has lower
>>> priority.
>> That sounds very nice, and will help Emacs look more modern and user
>> friendly.  Is there any way to make an exception to include this on
>> the Emacs 27.1 branch?
>
> I've just tried the tab modes for the first time, and would describe
> the current default look as "functional", so if the proposed fancier
> look is a substantial improvement, then I'd be in favour of either
> allowing the extra time to develop them, or else allowing them to be
> merged later as bug-fixes.
>
> Perhaps it would be useful to see a screenshot showing the difference?

I'm still not sure if a fancier look is worth the trouble,
especially since in some sense it's a change for the worse:
it takes too much screen space, so less tabs can fit into the tab bar.

Please see the difference: the first image is the current tab shapes,
on the second image you can see that less tabs can be displayed
on the tab bar:


[-- Attachment #2: tabs_current.png --]
[-- Type: image/png, Size: 5361 bytes --]

[-- Attachment #3: tabs_rounded.png --]
[-- Type: image/png, Size: 5847 bytes --]

Re: Starting the Emacs 27 release cycle

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

> I'm still not sure if a fancier look is worth the trouble,
> especially since in some sense it's a change for the worse:
> it takes too much screen space, so less tabs can fit into the tab bar.
>
> Please see the difference: the first image is the current tab shapes,
> on the second image you can see that less tabs can be displayed
> on the tab bar:

FWIW, and this is of course highly subjective, but I think the rounded
style looks much better, more professional and more modern.  The
trade-off with regards to screen real estate will be well worth it for
the default case, I think.  If we decide to go that way, we could
always keep the other look around as an option for those working on
smaller screens.

Best regards,
Stefan Kangas

Re: Starting the Emacs 27 release cycle

[Robert Pluim]

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

>>>>> On Thu, 28 Nov 2019 06:55:28 +0100, Stefan Kangas <stefan@marxist.se> said:

    Stefan> Juri Linkov <juri@linkov.net> writes:
    >> I'm still not sure if a fancier look is worth the trouble,
    >> especially since in some sense it's a change for the worse:
    >> it takes too much screen space, so less tabs can fit into the tab bar.
    >> 
    >> Please see the difference: the first image is the current tab shapes,
    >> on the second image you can see that less tabs can be displayed
    >> on the tab bar:

    Stefan> FWIW, and this is of course highly subjective, but I think the rounded
    Stefan> style looks much better, more professional and more modern.  The
    Stefan> trade-off with regards to screen real estate will be well worth it for
    Stefan> the default case, I think.  If we decide to go that way, we could
    Stefan> always keep the other look around as an option for those working on
    Stefan> smaller screens.

Is it possible to emulate the chrome/chromium method, where the curve
of the active tab covers the inactive tabs to the right/left? That
solves the spacing issue.


[-- Attachment #2: chrome-tab.png --]
[-- Type: image/png, Size: 665 bytes --]

Re: Starting the Emacs 27 release cycle

[VanL]

Robert Pluim <rpluim@gmail.com> writes:

>     Stefan> FWIW, and this is of course highly subjective, but I think the rounded
>     Stefan> style looks much better, more professional and more modern.  The
>
> Is it possible to emulate the chrome/chromium method, where the curve
> of the active tab covers the inactive tabs to the right/left? That
> solves the spacing issue.

The fashion for the moment is the Tesla Cybertruck low polygon count laser
look.  Browsers discontinued the stretched bell curve tab-look some time
ago.

-- 
© 2019 VanL
gpg using EEF2 37E9 3840 0D5D 9183  251E 9830 384E 9683 B835
          'If the bug bites,don't fight it.' -Nancy S. Steinhardt

Re: Starting the Emacs 27 release cycle

[Juri Linkov]

>>     Stefan> FWIW, and this is of course highly subjective, but I think the rounded
>>     Stefan> style looks much better, more professional and more modern.  The
>>
>> Is it possible to emulate the chrome/chromium method, where the curve
>> of the active tab covers the inactive tabs to the right/left? That
>> solves the spacing issue.
>
> The fashion for the moment is the Tesla Cybertruck low polygon count laser
> look.  Browsers discontinued the stretched bell curve tab-look some time
> ago.

Exactly my thoughts - functional design is trending.

Re: Starting the Emacs 27 release cycle

[Juri Linkov]

>> PS: I also have an unfinished implementation of more fancy looking tabs
>> with rounded corners that would take more than 2 weeks to complete
>> but this is of lesser importance and thus has lower priority.
>
> That sounds very nice, and will help Emacs look more modern and user
> friendly.  Is there any way to make an exception to include this on
> the Emacs 27.1 branch?  It's hard to imagine that it would drastically
> affect the stability of that branch, in my opinion.  OTOH, of course,
> this is a slippery slope.  Please shoot my idea down if it's not
> wanted.

These fancy looks with rounded corners should not be overrated.  They
have their disadvantages: fancy curves take screen space on both sides
on every tab, thus less tabs fit into the tab bar than now.  I guess
this is the reason why web browsers and other editors abandoned curves
for square shapes.  Chromium uses rounded corners only for the current tab,
and no shapes at all for other tabs, just separates them by a vertical bar.
Firefox uses a square shape for the current tab, and no special styles
for other tabs, only a vertical separator.  So currently tabs in Emacs
are already fancier than even in Chromium and Firefox.

Re: Starting the Emacs 27 release cycle

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > These fancy looks with rounded corners should not be overrated.  They
  > have their disadvantages: fancy curves take screen space on both sides
  > on every tab, thus less tabs fit into the tab bar than now.  I guess
  > this is the reason why web browsers and other editors abandoned curves
  > for square shapes.

In a choice between real capabilities and prettiness, we should choose
real capabilities.

-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Starting the Emacs 27 release cycle

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org
> Date: Sun, 24 Nov 2019 01:16:00 +0200
> 
> The remaining tabs feature is to add support for a new display action
> display-buffer-in-tab for display-buffer-alist to be implemented in
> bug#38354 that takes about a week.
> 
> PS: I also have an unfinished implementation of more fancy looking tabs
> with rounded corners that would take more than 2 weeks to complete
> but this is of lesser importance and thus has lower priority.

Thanks, so it sounds like we will be good to go in about a week.

Re: Starting the Emacs 27 release cycle

[Bastien]

Hi Eli,

I just released Org 9.3, a major release with some new features.
All these features have been heavily tested since a year or so.

If Org can make it for the next Emacs major release, that would
be great.

Thanks,

-- 
 Bastien

Re: Starting the Emacs 27 release cycle

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Tue, 03 Dec 2019 17:13:56 +0100
> 
> I just released Org 9.3, a major release with some new features.
> All these features have been heavily tested since a year or so.
> 
> If Org can make it for the next Emacs major release, that would
> be great.

Feel free to merge to master, and thanks.

Re: Starting the Emacs 27 release cycle

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

> Feel free to merge to master, and thanks.

Done, thanks!

-- 
 Bastien

Re: Starting the Emacs 27 release cycle

[Juanma Barranquero]

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

On Tue, Dec 3, 2019 at 11:52 PM Bastien <bzg@gnu.org> wrote:

> Done, thanks!

In org-babel-execute:eshell:
org/ob-eshell.el:51:26:Warning: reference to free variable
    `eshell-last-output-end'
org/ob-eshell.el:56:24:Warning: reference to free variable
    `eshell-last-input-end'
org/ob-eshell.el:57:53:Warning: reference to free variable
    `eshell-last-output-start'

In end of data:
org/ob-eshell.el:103:1:Warning: the function `eshell-send-input' is not
known
    to be defined.

In toplevel form:
org/org-keys.el:245:1:Warning: Alias for `org-replace-disputed-keys' should
be
    declared before its referent

In end of data:
org/org-keys.el:925:1:Warning: the function `cl-find-if' might not be
defined
    at runtime.

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

Re: Starting the Emacs 27 release cycle

[Bastien]

Hi Juanma,

I see you already fixed this in Emacs master, thanks a lot!

-- 
 Bastien

Re: Starting the Emacs 27 release cycle

[Juanma Barranquero]

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

Yep, I was bored this morning ;-)

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

Starting the Emacs 27 release cycle

[Eli Zaretskii]

I've created the emacs-27 release branch, and bumped Emacs version on
master to 28.0.50.  A pretest of Emacs 27.1 will follow some time
soon, I hope.

Please from now on push safe bugfixes and documentation fixes to the
release branch; all the other development should happen on master.
When in doubt whether a bugfix is safe enough, please ask.

CONTRIBUTE has more about working with master and the release branch,
please review those practices.

Please also checkout and build the release branch and use the version
there to find potential bugs sooner rather than later.

TIA

Re: Starting the Emacs 27 release cycle

[Alan Mackenzie]

Hello, Eli.

On Mon, Dec 23, 2019 at 18:05:19 +0200, Eli Zaretskii wrote:
> I've created the emacs-27 release branch, and bumped Emacs version on
> master to 28.0.50.  A pretest of Emacs 27.1 will follow some time
> soon, I hope.

Thanks!

> Please from now on push safe bugfixes and documentation fixes to the
> release branch; all the other development should happen on master.
> When in doubt whether a bugfix is safe enough, please ask.

> CONTRIBUTE has more about working with master and the release branch,
> please review those practices.

> Please also checkout and build the release branch and use the version
> there to find potential bugs sooner rather than later.

> TIA

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Starting the Emacs 27 release cycle

[Pankaj Jangid]

> I've created the emacs-27 release branch, and bumped Emacs version on
> master to 28.0.50.  A pretest of Emacs 27.1 will follow some time
> soon, I hope.

Thanks a lot everyone. Thanks Eli. _/\_

Re: Starting the Emacs 27 release cycle

[Eli Zaretskii]

> Date: Mon, 23 Dec 2019 18:05:19 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> I've created the emacs-27 release branch, and bumped Emacs version on
> master to 28.0.50.  A pretest of Emacs 27.1 will follow some time
> soon, I hope.
> 
> Please from now on push safe bugfixes and documentation fixes to the
> release branch; all the other development should happen on master.
> When in doubt whether a bugfix is safe enough, please ask.

I see that people continue fixing bugs on master, disregarding what I
said above.  Please fix bugs on the release branch instead.  In
particular, documentation bugs should always be fixed on the release
branch as long as it is active.

Thanks.

Re: Starting the Emacs 27 release cycle

[Robert Pluim]

>>>>> On Mon, 23 Dec 2019 18:05:19 +0200, Eli Zaretskii <eliz@gnu.org> said:

    Eli> I've created the emacs-27 release branch, and bumped Emacs version on
    Eli> master to 28.0.50.  A pretest of Emacs 27.1 will follow some time
    Eli> soon, I hope.

    Eli> Please from now on push safe bugfixes and documentation fixes to the
    Eli> release branch; all the other development should happen on master.
    Eli> When in doubt whether a bugfix is safe enough, please ask.

    Eli> CONTRIBUTE has more about working with master and the release branch,
    Eli> please review those practices.

    Eli> Please also checkout and build the release branch and use the version
    Eli> there to find potential bugs sooner rather than later.

Eli, unless you prefer otherwise, my pending changes for setting the
thread name and for allowing specifying the source address for UDP
connections will go to master, not emacs-27.

Iʼve just pushed the XFT colour font changes and the macos -nw crash
changes to the emacs-27 branch.

Robert

Re: Starting the Emacs 27 release cycle

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 29 Dec 2019 21:17:31 +0100
> 
> Eli, unless you prefer otherwise, my pending changes for setting the
> thread name and for allowing specifying the source address for UDP
> connections will go to master, not emacs-27.

Thread name changes should go to emacs-27, as the Windows part is
already there (since before the branching).  The other one... I guess
it isn't too important, and could wait?  WDYT?

> Iʼve just pushed the XFT colour font changes and the macos -nw crash
> changes to the emacs-27 branch.

Thanks.

Re: Starting the Emacs 27 release cycle

[Robert Pluim]

>>>>> On Sun, 29 Dec 2019 22:22:24 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: emacs-devel@gnu.org
    >> Date: Sun, 29 Dec 2019 21:17:31 +0100
    >> 
    >> Eli, unless you prefer otherwise, my pending changes for setting the
    >> thread name and for allowing specifying the source address for UDP
    >> connections will go to master, not emacs-27.

    Eli> Thread name changes should go to emacs-27, as the Windows part is
    Eli> already there (since before the branching).  The other one... I guess
    Eli> it isn't too important, and could wait?  WDYT?

OK, Iʼll push those sometime this week to emacs-27 and master respectively.

Thanks

Robert