From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Why wasn't the 25.3 release based on the then-head of the emacs-25 branch? Date: Mon, 18 Sep 2017 18:05:38 +0300 Message-ID: <83k20whwsd.fsf@gnu.org> References: <83ingkmqed.fsf@gnu.org> <52377n1qhv.fsf@fencepost.gnu.org> <83mv5vktlj.fsf@gnu.org> <83ingijbmo.fsf@gnu.org> <18aea83f-80ea-756e-106a-1d27eb5fc38e@cs.ucla.edu> <83fubljtiq.fsf@gnu.org> <80bc870f-4ce0-bf34-a9ae-4cc50c796266@cs.ucla.edu> <83y3pdi21z.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1505747199 28400 195.159.176.226 (18 Sep 2017 15:06:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 18 Sep 2017 15:06:39 +0000 (UTC) Cc: rgm@gnu.org, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 18 17:06:31 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dtxcx-0006yG-Ka for ged-emacs-devel@m.gmane.org; Mon, 18 Sep 2017 17:06:27 +0200 Original-Received: from localhost ([::1]:37147 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dtxd3-0004C3-Ck for ged-emacs-devel@m.gmane.org; Mon, 18 Sep 2017 11:06:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38750) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dtxcT-0004Bo-IP for emacs-devel@gnu.org; Mon, 18 Sep 2017 11:05:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dtxcN-0003qN-DN for emacs-devel@gnu.org; Mon, 18 Sep 2017 11:05:57 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dtxcN-0003qJ-96; Mon, 18 Sep 2017 11:05:51 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4521 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dtxcM-0002j0-7k; Mon, 18 Sep 2017 11:05:50 -0400 In-reply-to: (message from Paul Eggert on Sun, 17 Sep 2017 15:44:36 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:218467 Archived-At: > Cc: rgm@gnu.org, emacs-devel@gnu.org > From: Paul Eggert > Date: Sun, 17 Sep 2017 15:44:36 -0700 > > That time included the time to make the tarball and test it. > > If making the tarball and testing it takes 1.5 days, then that was 20% of the overall delay last time, and there is good opportunity for speeding up the process. Such a process should take minutes, not hours. The process of producing the tarball once you invoke make-dist is indeed very short. But the process of checking-out from Git, setting the version number, committing the changes and the corresponding tag, making the tarball itself, verifying its correctness, uploading it to the GNU servers, then downloading it to several different systems, and verifying the build--that process takes longer, especially if done by several people who have their lives and live in different timezones. Much of this involves tedious manual procedures, and is thus error-prone. It would be nice to automate at least some of that (tarball content verification comes to mind), which could shorten the time and eliminate the potential for errors. For example, in the case of Emacs 25.3, the original tarball included 2 minor mistakes, which required to re-upload it after fixing them. But whatever improvements we introduce, I think it's naïve to assume time frames of minutes for these activities, unless we want to give up QA. And giving up QA would be a mistake, IMO, since emergency releases that fix grave problems must not themselves be problematic; if they are, that would require additional fixup releases and prolong the time even more. > How can people outside of > the project be charged with reviewing our bugs and patches? > > These are people quite knowledgeable about security and software maintenance. They can be a good source for security reviews. It's another set of eyes, with an outside perspective, and that is helpful. > > why wouldn't those people speak up here > and work with us within our procedures? > > They're busy. Also, we haven't exactly been soliciting or welcoming their input. The most recent emergency release had a bit of an NIH feel about it. I still don't understand what you are suggesting, in practical terms, and how will this be different from the current procedures, where anyone could raise a security issue and propose a solution. > No one was arguing for additional bureaucracy. What we need is data > and procedures > > Whatever it's called it's more work, and we lack the resources to do it. Maybe we can look at two disparate releases (Debian and Fedora, say). Above that there are diminishing returns. Outside reviewers could help here (some are Fedora experts). Are Debian and Fedora indeed enough? What about Red Hat? What about Arch Linux? I don't have the answers, but we should decide on the representative sample of the distributions based on some principles we agree upon, and we should do it ahead of time. The next question is, given the sample of distributions, how does one figure out which ones of them include a given Emacs changeset, in which versions of Emacs, and since what time. Asking some experts about this is possible, but it runs the risk that those experts are unavailable or incommunicado when we need them, so if some databases can be searched instead, that's better. And of course all of that should be recorded in some file in admin/, so that no one has to remember any of this when the time comes.