emacs-devel
[Top][All Lists]
Advanced

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

Re: emacs-24.5-rc3.tar.xz modified in place


From: Eli Zaretskii
Subject: Re: emacs-24.5-rc3.tar.xz modified in place
Date: Fri, 10 Apr 2015 13:22:17 +0300

> Date: Fri, 10 Apr 2015 11:21:57 +0200
> Cc: Mark H Weaver <address@hidden>, address@hidden
> From: Ulrich Mueller <address@hidden>
> 
> >>>>> 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.



reply via email to

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