Re: [ANNOUNCE] Emacs 25.3 released

[Paul Eggert <eggert@cs.ucla.edu>]

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.