From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs-24.5-rc3.tar.xz modified in place Date: Fri, 10 Apr 2015 13:22:17 +0300 Message-ID: <833848uvty.fsf@gnu.org> References: <87pp7dro0p.fsf@netris.org> <83iod4v38r.fsf@gnu.org> <21799.38453.712043.482146@a1i15.kph.uni-mainz.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1428661363 28854 80.91.229.3 (10 Apr 2015 10:22:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Apr 2015 10:22:43 +0000 (UTC) Cc: mhw@netris.org, emacs-devel@gnu.org To: Ulrich Mueller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 10 12:22:29 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YgW4z-0005as-6X for ged-emacs-devel@m.gmane.org; Fri, 10 Apr 2015 12:22:29 +0200 Original-Received: from localhost ([::1]:38448 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgW4y-0001OH-Bn for ged-emacs-devel@m.gmane.org; Fri, 10 Apr 2015 06:22:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52988) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgW4u-0001Ny-O6 for emacs-devel@gnu.org; Fri, 10 Apr 2015 06:22:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgW4r-0000Z6-GL for emacs-devel@gnu.org; Fri, 10 Apr 2015 06:22:24 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:48033) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgW4r-0000Yo-8L for emacs-devel@gnu.org; Fri, 10 Apr 2015 06:22:21 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NML00I005RUES00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Fri, 10 Apr 2015 13:22:18 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NML00I8N6557WB0@a-mtaout22.012.net.il>; Fri, 10 Apr 2015 13:22:18 +0300 (IDT) In-reply-to: <21799.38453.712043.482146@a1i15.kph.uni-mainz.de> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:185252 Archived-At: > Date: Fri, 10 Apr 2015 11:21:57 +0200 > Cc: Mark H Weaver , emacs-devel@gnu.org > From: Ulrich Mueller > > >>>>> On Fri, 10 Apr 2015, Eli Zaretskii wrote: > > > It was done on purpose, to shorten the release time. Nicolas did as > > instructed. > > What sort of excuse is this? It's not an excuse, it's an explanation of what happened. > Please, never ever modify a distfile in place without updating its > version number. It would have been no problem to use -rc4 here. The > modified file in question, emacs-24.5-rc3.tar.xz, had already been > fetched by the Gentoo mirror system. I have updated it now (and the > checksums recorded in our package's manifest), but it will take some > time for the new files to propagate, so in the mean time users will > get checksum failures. I'm sorry for the effort you had to invest, but I don't see how it is relevant to what we do during the release process. These tarballs are only there for the last-minute testing of the tarball, so you are well-advised not to carry them. > What do you do if you receive a bug report for rc3? We will handle it. > Also this isn't the first time that such a thing has happened: > http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00028.html And probably also not the last, as much as we want to avoid that. > > Distributions should not pick up alpha releases without asking > > first. > > It is entirely the decision of a distro what they include and what > they don't. Then you should be prepared for such contingencies. I can assure you this last-minute omission is not something that was done on purpose, so the probability of its happening again is very low. But we cannot promise it won't happen. > And it's not an alpha release but supposedly the final release > candidate, so it should be in everyone's interest if it gets as much > testing as possible. No, that's not true. The only reason for that RC's existence is that Nicolas does this job the first time, so he is naturally uncertain about his procedures (which look just fine from my POV). We had all the testing we needed before the first RC.