From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: [PATCH PING] Honor 'SOURCE_DATE_EPOCH' when generating autoloads. Date: Tue, 29 Dec 2015 12:33:26 -0800 Organization: UCLA Computer Science Department Message-ID: <5682EE16.8040607@cs.ucla.edu> References: <87k2ph3mgx.fsf@gnu.org> <87two3475d.fsf@gnu.org> <5665D6B9.4030309@cs.ucla.edu> <5665DAA1.2080208@cs.ucla.edu> <83k2o9t6t1.fsf@gnu.org> <56771D52.2070406@cs.ucla.edu> <83fuytp1au.fsf@gnu.org> <568073A4.3010604@cs.ucla.edu> <83ege6fsj1.fsf@gnu.org> <568178B6.4000402@cs.ucla.edu> <837fjyfn58.fsf@gnu.org> <5681F791.40309@cs.ucla.edu> <83y4cde044.fsf@gnu.org> <5682B90D.1080009@cs.ucla.edu> <834mf1dtk5.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1451421243 21549 80.91.229.3 (29 Dec 2015 20:34:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Dec 2015 20:34:03 +0000 (UTC) Cc: p.stephani2@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 29 21:33:55 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 1aE0xs-0004hj-7E for ged-emacs-devel@m.gmane.org; Tue, 29 Dec 2015 21:33:52 +0100 Original-Received: from localhost ([::1]:50010 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aE0xq-0007re-Bh for ged-emacs-devel@m.gmane.org; Tue, 29 Dec 2015 15:33:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43972) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aE0xa-0007rZ-J2 for emacs-devel@gnu.org; Tue, 29 Dec 2015 15:33:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aE0xZ-0004Y4-Fd for emacs-devel@gnu.org; Tue, 29 Dec 2015 15:33:34 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:58074) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aE0xV-0004Xf-J3; Tue, 29 Dec 2015 15:33:29 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id CC2A6160E99; Tue, 29 Dec 2015 12:33:27 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Okvq54wvGmOE; Tue, 29 Dec 2015 12:33:27 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0BDDB160EB3; Tue, 29 Dec 2015 12:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ikba7BL2nXBJ; Tue, 29 Dec 2015 12:33:26 -0800 (PST) Original-Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id DB638160E99; Tue, 29 Dec 2015 12:33:26 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <834mf1dtk5.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:197141 Archived-At: Eli Zaretskii wrote: > We could come up with something even less probable. We could, yes. It should not be a valid domain name, for example. But wha= tever=20 magic cookie we came up with, we would need to document it so that user c= ode can=20 avoid displaying it. And to avoid typos it would be better to make it a n= amed=20 constant. And we would need to do something similar, with different named= =20 constants, for similar issues such as emacs-build-time. And we would neve= r=20 eliminate the possibility that someone (if only to be contrary, e.g., bec= ause=20 they are attacking Emacs) would use the magic-cookie as a host name. All = in all,=20 it would be a relatively complicated solution to what should be a simple = problem. >> >In this sense, the Dec. 25 change that introduced the system build na= me into the >> >output of report-emacs-bug was a misstep. > No, it isn't. I needed this information many times when examining bug > reports, and I'm not going to give it up. My comment=E2=80=99s =E2=80=9Cin the sense=E2=80=9D referred to the sense= of its previous paragraph (not=20 quoted above) which talked about deterministic builds; it did not refer t= o=20 building Emacs in general. In some cases it can be useful to have the bui= ld=20 hostname embedded in the executable even at the cost of deterministic bui= lds.=20 However, many people (including myself) prefer deterministic builds, and = for=20 them embedding the build hostname is counterproductive, and that is why i= t is=20 useful to have an option to suppress it. > Can I have some minimal > respect from fellow developers, and some minimal credit that I do > things for a reason? Nothing in my commentary was intended to exhibit any disrespect. It was i= ntended=20 to be purely technical commentary. If it seemed otherwise, I apologize. >>> > >It sounds strange to send users to documentation for such a simple= issue. >> > >> >No matter what we do here, we will need documentation that users can = refer to on >> >occasion. Even simple approaches like nil-if-unknown require some doc= umentation. >> >More-complicated approaches like magic-cookie-if-unknown would requir= e more of it. > You are ducking the issue. I do not see what I am ducking here. Surely you are not advocating leavin= g the=20 behavior undocumented. Are you objecting to the convention of using nil t= o=20 represent lack of information? If so, how about if we use some other symb= ol,=20 such as =E2=80=98unknown=E2=80=99? Although that would be a bit more of a= pain to document and=20 use, it would also be OK and for the reasons discussed above would be bet= ter=20 than a magic-cookie string.