[Top][All Lists]

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

Re: Why wasn't the 25.3 release based on the then-head of the emacs-25 b

From: Paul Eggert
Subject: Re: Why wasn't the 25.3 release based on the then-head of the emacs-25 branch?
Date: Sun, 17 Sep 2017 10:40:45 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

Eli Zaretskii wrote:
Having more people who can upload tarballs to the GNU site is one
obvious improvement.

I'll volunteer to do that, if nobody else wants to. I generally delegate this task to others, in the other projects I contribute to, and would prefer that here too. But if we're shorthanded, I'll step in.

it only accounts for one-day delay of the 25.3 release.

25.3 was decided on by Sat, 9 Sep 2017 10:48:13 +0300 (this is the timestamp on private email from you). The release announcement was sent Mon, 11 Sep 2017 22:52:00 +0200. That's a delay of about 2.5 days to turn the crank. We should do better next time. A reasonable goal is to have a delay of at most one hour for turning the crank to generate a new release. Ideally you would do it, since you make the decision and that would avoid email lag; but it should be done reasonably quickly even if someone else has to do it.

Other ways to improve our process are much more important

Yes, as the gap between the original report (Mon, 4 Sep 2017 19:26:01 UTC) and the 25.3 decision was about 4.5 days, and this is bigger than 2.5 days and so offers more opportunity for streamlining.

As I think I mentioned, I had offers via savannah-hackers to help review Emacs security bug reports and proposed patches faster, and I'm inclined to take up these offers. I don't know of any other proposal for significantly speeding up this part of the process.

We should be able to do better than a one-week total turnaround for this sort of thing.

Debian testing is limited to Debian systems

Sure, but the patches in question were portable and Debian testing is quite a strong signal that they will work elsewhere. Obviously there is a judgment call here (how do we know the patches are portable? we have to read them) but that's OK. Going forward, we needn't come up with an elaborate bureaucracy here, nor do we have the resources for that.

The emacs-25 branch is not maintained since May.  It stopped being
updated when it became clear that no one is interested in releasing
Emacs 25.3 with a few bugs of 25.2 fixed.

OK, I'll stop updating it. If we need another emergency patch for Emacs 25, should we use the emacs-25-3 branch, or create a new branch emacs-25-4? It'd be nice to know that now so that we avoid confusion later. I suggest that we keep using emacs-25-3 rather than creating a new branch. In hindsight perhaps we should have named this branch emacs-25-security.

reply via email to

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