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

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Paul Eggert <address@hidden>
> Date: Sun, 17 Sep 2017 10:40:45 -0700
> 
> 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.

Thanks.

> > 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.

That time included the time to make the tarball and test it.  The
delay between the decision and when Nicolas started to work on the
tarball was one day.

> 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 think I understand what that means.  How can people outside of
the project be charged with reviewing our bugs and patches?  How will
that work in practice?  And why wouldn't those people speak up here
and work with us within our procedures?

> > 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.

No one was arguing for additional bureaucracy.  What we need is data
and procedures to make the decision quickly and without ado.  And I
don't think Debian alone should be the basis, we need to be able to
quickly see which of our unreleased patches are backported by popular
distributions, including, but not limited to Debian.

> 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?

I don't think we can decide now, it will depend on the specific
circumstances when (if) such issues arise.

> I suggest that we keep using emacs-25-3 rather than creating a new
> branch.

That's definitely a possibility that should be one of the most
favorable ones, if not the favorable.  But it's impossible to make a
decision until the specific details of the issue are known.