Re: [ANNOUNCE] Emacs 25.3 released

[Eli Zaretskii <eliz@gnu.org>]

> From: Thien-Thi Nguyen <ttn@gnu.org>
> Date: Tue, 12 Sep 2017 20:26:10 +0200
> 
> I think the lag is important because it represents "attack
> surface" (for FUD) to defend.  Look at all the noise already
> precipitated.

Experience shows that noise is unavoidable, no matter what we do or
don't do.  Thus, the fact that there is noise proves or disproves
nothing.

> If those operations are not sufficient to get the repo in order,
> then i suggest they be done prior to tarball publication,
> anyway, but on a provisional branch.  Afterwards, the proper
> "getting the repo in order" operations can work w/ that branch
> to merge it back to ‘master’ or whatever.

Experience taught me that Git is tricky enough to cause even
experience users of Git to make mistakes from time to time.  And in
this case even a slight risk of making a mistake was entirely
unacceptable.  So we've chosen a safer way, with Git issues out of the
critical path.  From my POV, the result was smashing success.

> In sum: IMHO it's fine to deviate from full release protocol if
> the deviation maintains transparency.  When transparency is
> lost, we need (annoying :-D) ml threads to find it again.

The transparency was not lost, because the patch was posted here in
advance.