Future release of emacs-26 (WAS: bug#34341)

Future release of emacs-26 (WAS: bug#34341)

[Noam Postavsky]

Eli Zaretskii <eliz@gnu.org> writes:

> and we don't even know whether emacs-26 will be
> used for another "regular" release.

So, I'm thinking we should be aiming for another "regular" release
around September, when the GNU ELPA package signing key expires.  After
that, people downloading Emacs 26.2 won't be able to install GNU ELPA
packages without either disabling signature checking, or manually
installing the new key.

https://debbugs.gnu.org/35414
https://elpa.gnu.org/packages/gnu-elpa-keyring-update.html

Re: Future release of emacs-26 (WAS: bug#34341)

[Nicolas Petton]

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

Noam Postavsky <npostavs@gmail.com> writes:

> So, I'm thinking we should be aiming for another "regular" release
> around September, when the GNU ELPA package signing key expires.  After
> that, people downloading Emacs 26.2 won't be able to install GNU ELPA
> packages without either disabling signature checking, or manually
> installing the new key.

I agree.

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Future release of emacs-26

[Stefan Monnier]

> So, I'm thinking we should be aiming for another "regular" release
> around September, when the GNU ELPA package signing key expires.

If the key is an important motivation, then I think we should do it
significantly before September, so that by the time the key expires
the various GNU/Linux distributions will have had time to update their
packages and their users will have had time to install those updates.


        Stefan

Re: Future release of emacs-26 (WAS: bug#34341)

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Mon, 13 May 2019 20:34:48 -0400
> 
> So, I'm thinking we should be aiming for another "regular" release
> around September, when the GNU ELPA package signing key expires.  After
> that, people downloading Emacs 26.2 won't be able to install GNU ELPA
> packages without either disabling signature checking, or manually
> installing the new key.

Fine with me, but then we should see what other issues we'd like to
fix in that version.  If there are none currently, I'd prefer to start
the pretest ASAP, so that we will definitely release 26.3 before
September, possibly sooner.

Re: Future release of emacs-26 (WAS: bug#34341)

[Richard Copley]

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

On Tue, 14 May 2019 at 09:10, Noam Postavsky <npostavs@gmail.com> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> > and we don't even know whether emacs-26 will be
> > used for another "regular" release.
>
> So, I'm thinking we should be aiming for another "regular" release
> around September, when the GNU ELPA package signing key expires.  After
> that, people downloading Emacs 26.2 won't be able to install GNU ELPA
> packages without either disabling signature checking, or manually
> installing the new key.
>
> https://debbugs.gnu.org/35414
> https://elpa.gnu.org/packages/gnu-elpa-keyring-update.html


The signature checking has never worked anyway, though. Will having a newer
signature make a difference? If I rename my .emacs.d/ and run "emacs"
(master),
then "M-x package-list", I get this:

Failed to verify signature archive-contents.sig:
Bad signature from 474F05837FBDEF9B GNU ELPA Signing Agent (2014) <
elpasign@elpa.gnu.org>
Command output:
gpg: Signature made 05/14/19 10:10:03 GMT Summer Time
gpg:                using DSA key CA442C00F91774F17F59D9B0474F05837FBDEF9B
gpg: BAD signature from "GNU ELPA Signing Agent (2014) <
elpasign@elpa.gnu.org>" [unknown]

This is on Windows, with gpg 2.2.11 on the path.

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

Re: Future release of emacs-26

[Stefan Monnier]

> The signature checking has never worked anyway, though.

Maybe not for you, but it's supposed to work, and AFAIK it works for
many people.

> Will having a newer
> signature make a difference? If I rename my .emacs.d/ and run "emacs"
> (master),
> then "M-x package-list", I get this:
>
> Failed to verify signature archive-contents.sig:
> Bad signature from 474F05837FBDEF9B GNU ELPA Signing Agent (2014) <
> elpasign@elpa.gnu.org>
> Command output:
> gpg: Signature made 05/14/19 10:10:03 GMT Summer Time
> gpg:                using DSA key CA442C00F91774F17F59D9B0474F05837FBDEF9B
> gpg: BAD signature from "GNU ELPA Signing Agent (2014) <
> elpasign@elpa.gnu.org>" [unknown]
>
> This is on Windows, with gpg 2.2.11 on the path.

Sounds like a bug.  Could you report it as such, so we can track it
(and hopefully fix it for 26.3)?


        Stefan

Re: Future release of emacs-26

[Richard Copley]

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

On Tue, 14 May 2019 at 22:08, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > The signature checking has never worked anyway, though.
>
> Maybe not for you, but it's supposed to work, and AFAIK it works for
> many people.
>

Oh, sorry. I always assumed this was why package-check-signatures defaulted
to allow-unsigned.


> > Will having a newer
> > signature make a difference? If I rename my .emacs.d/ and run "emacs"
> > (master),
> > then "M-x package-list", I get this:
> >
> > Failed to verify signature archive-contents.sig:
> > Bad signature from 474F05837FBDEF9B GNU ELPA Signing Agent (2014) <
> > elpasign@elpa.gnu.org>
> > Command output:
> > gpg: Signature made 05/14/19 10:10:03 GMT Summer Time
> > gpg:                using DSA key
> CA442C00F91774F17F59D9B0474F05837FBDEF9B
> > gpg: BAD signature from "GNU ELPA Signing Agent (2014) <
> > elpasign@elpa.gnu.org>" [unknown]
> >
> > This is on Windows, with gpg 2.2.11 on the path.
>
> Sounds like a bug.  Could you report it as such, so we can track it
> (and hopefully fix it for 26.3)?
>

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35739

Thanks.

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

Re: Future release of emacs-26

[Stefan Monnier]

>> > The signature checking has never worked anyway, though.
>> Maybe not for you, but it's supposed to work, and AFAIK it works for
>> many people.
> Oh, sorry. I always assumed this was why package-check-signatures defaulted
> to allow-unsigned.

No, this setting is to make it easier for the other ELPA archives which
(AFAIK) don't sign their packages (and in any case, Emacs doesn't come
with the keys for those).

> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35739

Thanks,


        Stefan

Re: Future release of emacs-26

[Stephen Leake]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> No, this setting is to make it easier for the other ELPA archives which
> (AFAIK) don't sign their packages (and in any case, Emacs doesn't come
> with the keys for those).

Perhaps package-check-signatures should be per-repository, so we are
warned when the Gnu ELPA signature check fails.

-- 
-- Stephe

Re: Future release of emacs-26

[Stefan Monnier]

>> No, this setting is to make it easier for the other ELPA archives which
>> (AFAIK) don't sign their packages (and in any case, Emacs doesn't come
>> with the keys for those).
> Perhaps package-check-signatures should be per-repository, so we are
> warned when the Gnu ELPA signature check fails.

You should be loudly warned already, if you use the default value
(unless you don't have GPG installed, IIRC).


        Stefan

Re: Future release of emacs-26

[Richard Copley]

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

On Fri, 17 May 2019 at 04:05, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> >> No, this setting is to make it easier for the other ELPA archives which
> >> (AFAIK) don't sign their packages (and in any case, Emacs doesn't come
> >> with the keys for those).
> > Perhaps package-check-signatures should be per-repository, so we are
> > warned when the Gnu ELPA signature check fails.
>
> You should be loudly warned already, if you use the default value
> (unless you don't have GPG installed, IIRC).
>

Also, you can get the effect of per-repository package-check-signatures
using
the defcustom 'package-unsigned-archives' ("List of archives where we do not
check for package signatures").

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

Re: Future release of emacs-26

[Phillip Lord]

Noam Postavsky <npostavs@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> and we don't even know whether emacs-26 will be
>> used for another "regular" release.
>
> So, I'm thinking we should be aiming for another "regular" release
> around September, when the GNU ELPA package signing key expires.  After
> that, people downloading Emacs 26.2 won't be able to install GNU ELPA
> packages without either disabling signature checking, or manually
> installing the new key.
>
> https://debbugs.gnu.org/35414
> https://elpa.gnu.org/packages/gnu-elpa-keyring-update.html


Another possibility would be to release Emacs-26.2.1 which is just
Emacs-26.2 with the key updated. This could be done with a single commit
and would not require an extensive pre-test period.

It seems problematic to me to tie a release cycle to a key running
out. There will be time that this is pragmatically just not possible,
while performing one (or a number of) point releases would always be
doable.

Phil

Re: Future release of emacs-26

[Stefan Monnier]

> Another possibility would be to release Emacs-26.2.1 which is just
> Emacs-26.2 with the key updated.

We'd call it emacs-26.3 ;-)

> This could be done with a single commit and would not require an
> extensive pre-test period.

Indeed, we could release 26.3 not from the tip of `emacs-26` but from
"26.2 + the new key".


        Stefan

Re: Future release of emacs-26

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Date: Wed, 22 May 2019 17:07:58 +0100
> Cc: emacs-devel@gnu.org
> 
> > So, I'm thinking we should be aiming for another "regular" release
> > around September, when the GNU ELPA package signing key expires.  After
> > that, people downloading Emacs 26.2 won't be able to install GNU ELPA
> > packages without either disabling signature checking, or manually
> > installing the new key.
> >
> > https://debbugs.gnu.org/35414
> > https://elpa.gnu.org/packages/gnu-elpa-keyring-update.html
> 
> 
> Another possibility would be to release Emacs-26.2.1 which is just
> Emacs-26.2 with the key updated.

We don't release X.Y.Z versions.  For starters, it gets in the way of
local build numbering.

We could, of course, release Emacs 26.3 with just the key update, but
IMO, given the effort required to put a tarball out the door, it would
make more sense to have the fixes we backported since 26.2 as well.

> This could be done with a single commit and would not require an
> extensive pre-test period.

26.3 from the current branch should not require an extensive pretest
either.

> It seems problematic to me to tie a release cycle to a key running
> out.

We don't.  We just use that as a pretense for another 26.x release.

Re: Future release of emacs-26

[Leo Liu]

On 2019-05-22 20:04 +0300, Eli Zaretskii wrote:
> 26.3 from the current branch should not require an extensive pretest
> either.

+1

I have been waiting for a 26.x release that doesn't break my workflow.
Looks like 26.3 might be it.

Thanks,
Leo

Re: Future release of emacs-26

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> It seems problematic to me to tie a release cycle to a key running
>> out.
>
> We don't.  We just use that as a pretense for another 26.x release.

Okay. But I would think that it needs to be sooner rather than
later. The time could disappear very rapidly with summer coming up. Even
as it stands, there may be many GNU/Linux distributions that will not
update before the key runs out which is a bit messy.

Phil

Re: Future release of emacs-26

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: npostavs@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 27 May 2019 11:05:08 +0200
> 
> Okay. But I would think that it needs to be sooner rather than
> later. The time could disappear very rapidly with summer coming up. Even
> as it stands, there may be many GNU/Linux distributions that will not
> update before the key runs out which is a bit messy.

I proposed to start a pretest more than a week ago, so I obviously
agree.  I still see many proposals for backporting fixes and fixing
regressions, so maybe others want to wait a bit.

Re: Future release of emacs-26

[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. ]]]

Please fix the handling of symlinks in the pdump case
before you make a pretest.

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

Re: Future release of emacs-26

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: phillip.lord@russet.org.uk, npostavs@gmail.com,
> 	emacs-devel@gnu.org
> Date: Mon, 27 May 2019 16:17:36 -0400
> 
> Please fix the handling of symlinks in the pdump case
> before you make a pretest.

Emacs 26 doesn't support pdump files, so we are good there.

Re: Future release of emacs-26

[Noam Postavsky]

On Mon, 27 May 2019 at 12:13, Eli Zaretskii <eliz@gnu.org> wrote:

> I proposed to start a pretest more than a week ago, so I obviously
> agree.  I still see many proposals for backporting fixes and fixing
> regressions, so maybe others want to wait a bit.

I've listed the remaining 4 bugs I want to see fixed in emacs-26 here:
https://debbugs.gnu.org/35968

Re: Future release of emacs-26

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Cc: npostavs@gmail.com,  emacs-devel@gnu.org
>> Date: Mon, 27 May 2019 11:05:08 +0200
>> 
>> Okay. But I would think that it needs to be sooner rather than
>> later. The time could disappear very rapidly with summer coming up. Even
>> as it stands, there may be many GNU/Linux distributions that will not
>> update before the key runs out which is a bit messy.
>
> I proposed to start a pretest more than a week ago, so I obviously
> agree.  I still see many proposals for backporting fixes and fixing
> regressions, so maybe others want to wait a bit.


Okay.

Perhaps the key on ELPA needs to be updated before a release, so that
there is a longer lead time?

Phil

Re: Future release of emacs-26

[Stefan Monnier]

> Perhaps the key on ELPA needs to be updated before a release, so that
> there is a longer lead time?

Ideally, we'd arrange for Emacs to pre-install the
`gnu-elpa-keyring-update` package, so that users are encouraged to keep
their keyring updated.

But yes, new keys need to be created and distributed much sooner ahead
of the actual key-change.  6 months ago, we hadn't even thought about
how to update the keys, so we were really unprepared.  Hopefully, it'll
go more smoothly for the next key update (around 2024).


        Stefan

Re: Future release of emacs-26

[Noam Postavsky]

On Mon, 27 May 2019 at 12:13, Eli Zaretskii <eliz@gnu.org> wrote:

> I proposed to start a pretest more than a week ago, so I obviously
> agree.  I still see many proposals for backporting fixes and fixing
> regressions, so maybe others want to wait a bit.

Any comments for https://debbugs.gnu.org/35264#8? That's the only
emacs-26 related patch left that I'm aware of.

Re: Future release of emacs-26

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Mon, 3 Jun 2019 10:22:10 -0400
> Cc: Phillip Lord <phillip.lord@russet.org.uk>, Emacs developers <emacs-devel@gnu.org>
> 
> On Mon, 27 May 2019 at 12:13, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > I proposed to start a pretest more than a week ago, so I obviously
> > agree.  I still see many proposals for backporting fixes and fixing
> > regressions, so maybe others want to wait a bit.
> 
> Any comments for https://debbugs.gnu.org/35264#8? That's the only
> emacs-26 related patch left that I'm aware of.

It wasn't in the original list, and the problem doesn't sound to me
urgent enough to fix.  Am I missing something?

Re: Future release of emacs-26

[Noam Postavsky]

On Mon, 3 Jun 2019 at 10:54, Eli Zaretskii <eliz@gnu.org> wrote:

> > Any comments for https://debbugs.gnu.org/35264#8? That's the only
> > emacs-26 related patch left that I'm aware of.
>
> It wasn't in the original list, and the problem doesn't sound to me
> urgent enough to fix.  Am I missing something?

Regarding urgency, I bumped into it while writing a test for
yasnippet, i.e., there's no case "in the wild" yet. Meaning not that
urgent. And looking at the history of that error check again, I see
it's protecting against segfaults which I had forgotten about. Which
means we probably shouldn't mess with it on emacs-26 anyway.

So from my point of view, there's no reason to delay the pretest any longer.

Re: Future release of emacs-26

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Mon, 3 Jun 2019 11:45:14 -0400
> Cc: Phillip Lord <phillip.lord@russet.org.uk>, Emacs developers <emacs-devel@gnu.org>
> 
> So from my point of view, there's no reason to delay the pretest any longer.

OK, thanks.  Let's do it.