emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ANNOUNCE] Emacs 25.3 released


From: Paul Eggert
Subject: Re: [ANNOUNCE] Emacs 25.3 released
Date: Wed, 13 Sep 2017 01:53:08 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

Nicolas Petton wrote:
First, if I'm not being trusted with the release tarballs, somebody else
can build them next time.

Second, you can easily diff the emacs-25.3 tarball against emacs-25.2.

Even if I did create a branch and tag before publishing the tarball,
you'd have no guarantee that the tarball actually contains the content
of the git commit.  Diffing is the only way for you to see the actual
changes.
All quite true. Still, trust is typically established by multiple means. Many 
users won't have time to track down where the diff was published or to read the 
diff, or they won't have the technical ability to understand the diff's 
implications. And many users won't know who you are. But if these users trust 
savannah.gnu.org, a tagged commit there can be enough for them so that they 
don't have to do the other stuff. (And there may be some very cautious users who 
want to do all of the above....)
So it is helpful to have a tagged commit at the time of release, even though a 
tag by itself is not enough to satisfy the most-cautious, and even though many 
users don't care about the tag.
Some background here. I've managed releases for the public-domain time zone 
database (tzdb) for several years. Some of my correspondents there are *quite* 
cautious, way more cautious than anything mentioned in this thread. They have 
asked for multiple ways to verify that each release is what it purports to be, 
beyond what I thought was needed. But they're *users*. They know their needs 
better than I do. And if they say they want SHA-512 checksums in addition to GPG 
checksums, who am I to tell them that they're redundant? I want them to trust 
the tzdb distribution, so I try to accommodate their concerns, not to argue with 
them.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]