From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tobias Geerinckx-Rice Subject: Re: [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses. Date: Thu, 22 Dec 2016 06:56:56 +0100 Message-ID: <4b79e545-7ea6-3b6c-3a48-f5f1d6b1da3c@tobias.gr> References: <1482169820-2043-1-git-send-email-jmd@gnu.org> <1482169820-2043-2-git-send-email-jmd@gnu.org> <87lgvb9ii1.fsf@netris.org> <20161220110331.GA20543@jocasta.intra> <20161221093656.400cd7cd@scratchpost.org> <20161221095646.GA6917@jocasta.intra> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mpusqSMnrFw03iOaN3vGPmIwLCSv1TDXT" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41371) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cJwNA-0002pZ-M6 for guix-devel@gnu.org; Thu, 22 Dec 2016 00:57:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cJwN5-00068X-RM for guix-devel@gnu.org; Thu, 22 Dec 2016 00:57:00 -0500 Received: from relay2-d.mail.gandi.net ([2001:4b98:c:538::194]:37490) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cJwN5-00068B-Hc for guix-devel@gnu.org; Thu, 22 Dec 2016 00:56:55 -0500 In-Reply-To: <20161221095646.GA6917@jocasta.intra> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: john@darrington.wattle.id.au Cc: guix-devel@gnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mpusqSMnrFw03iOaN3vGPmIwLCSv1TDXT Content-Type: multipart/mixed; boundary="FDbohhBoXMfQATCfbOGv6epPpm0t9MobB"; protected-headers="v1" From: Tobias Geerinckx-Rice To: john@darrington.wattle.id.au Cc: dannym@scratchpost.org, guix-devel@gnu.org Message-ID: <4b79e545-7ea6-3b6c-3a48-f5f1d6b1da3c@tobias.gr> Subject: Re: [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses. References: <1482169820-2043-1-git-send-email-jmd@gnu.org> <1482169820-2043-2-git-send-email-jmd@gnu.org> <87lgvb9ii1.fsf@netris.org> <20161220110331.GA20543@jocasta.intra> <20161221093656.400cd7cd@scratchpost.org> <20161221095646.GA6917@jocasta.intra> In-Reply-To: <20161221095646.GA6917@jocasta.intra> --FDbohhBoXMfQATCfbOGv6epPpm0t9MobB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable John, Danny, [Any exasperation is due only to the sustained level of FUD I encounter about the Guix/GNU changelog format, and not aimed at John.] On 20/12/16 12:03, John Darrington wrote: > Sure (I would like to see a convention where such explanations are=20 > put in the commit messaage, but I have previously been outvoted on=20 > that issue). I don't think so. 1. What was =E2=80=98outvoted=E2=80=99 (with solid argumentation) was hid= ing comments documenting code itself in commit messages, when they would do more good as, well, comments. 2. The Guix commit log has plenty of concise explanations for why code was *changed*. I See 64b5e41 for a random example. If that guy can get away with it... Most People=E2=84=A2 badly overdo #2 when they should do #1 (consider the= average *Hub pull request). The opposite is less common. > On Wed, Dec 21, 2016 at 09:36:56AM +0100, Danny Milosavljevic wrote: >> No, please don't put explanations into the commit message. But do=20 >> put them into the source code as a comment. I'd just finished writing the exact same e-mail as Danny =E2=80=94 almost= to the sentence =E2=80=94 when that arrived. So... it must be right! :-) > That approach can work sometimes, but more often it is a=20 > non-starter. [Examples paraphrased for length:] > 1. ;; This variable used to be called "bar" but we changed it > 2. ;; There used to be some code here but we deleted it > 3. A new variable was introduced in places thoughout the code > 4. ;; Fred typed 'xyz' when he ought to have put 'abc' Sorry, but the first three examples are silly. :-) Deliberately silly, I'm sure, but still these are strawmen that no-one proposed. On the contrary: examples 1 to 3 are exactly what the current commit log documents with tedious precision. That leaves bugfixes. If the bug is waiting to happen again (and again...), putting a warning to future readers in a comment might be appropriate. No-one will spot it in a commit message. (Of course, re-writing the misleading/dangerous code would be the best solution.) If the fix is trivial, as in this example, the diff usually speaks for itself. In all other cases, a short note in the commit message is fine. This seems to be standard policy for CVEs. So I really don't understand your complaint. > But nobody except me will care about bugs in the function which have > been fixed. Exactly! In this patch, you're replacing buggy (?) code with shiny code. That shouldn't take more than ~50 characters to note. > On Wed, Dec 21, 2016 at 09:36:56AM +0100, Danny Milosavljevic wrote: >> I'm also working on other projects, some of which do what you=20 >> propose. What I often end up having to do there is do git blame,=20 >> then git log for each line, in order to find out why the source=20 >> code does what it does. Let's not do that here. +11, unfortunately from experience. > That is what git blame is for. Be thankful for it! No and God no. That is exactly what =E2=80=98git blame=E2=80=99 is not for. Code itself should be documented in-line. Not in a commit log meant for documenting changes, that breaks as soon as someone hits C-M-q. > I hope this explains why putting history in comments is harmful. It does! But this is not something anyone here suggested. > Having it in the commit message would certainly have avoided me=20 > having to explain the situation to Mark too. Perhaps. I doubt it. I can't speak for Mark, but most confusion seemed to stem from the commit message's accuracy, not its length. But yes, it could have been longer =E2=80=94 and a comment :-) Kind regards, T G-R PS: On 21/12/16 10:56, John Darrington wrote: > Hi Danny, >=20 > A small request: Can you please fold the text of your email to ~80=20 > characters. It's very hard to read otherwise. FWIW, your replies are equally hard to read (and even harder to reply to) because of the unconventional indentation. It certainly confuses Thunderbird, which is easily confused. --FDbohhBoXMfQATCfbOGv6epPpm0t9MobB-- --mpusqSMnrFw03iOaN3vGPmIwLCSv1TDXT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEqBAEBCgAUBQJYW2spDRxtZUB0b2JpYXMuZ3IACgkQkczbm0hUG5mS8Af+NiLg JEKIMTs3mwDA6xT+3zGiGDlbFgMElByyzeERIIiK525eIqvfWNPYwP9PiLm9GxeL gFBr21uXnrWr7puhIYJlNiaMX+gHh2HUtdR4bnusyQwNSHLmBU4e+C/mFw6Rp4bI T4gqP9ANbMyCznJz9eWSnFA87JREVCU+m7fL4vbLc6/1ZPr3vkkTmSd5Zc7ErwfA q19t2XKTLmCzN29V18621af+qvzk4/1E5pP35xyAveYYIhNSJ0dt2LaI3saqHkDk 0LED83g/vUJncuWkgd14UK/keZ3sLL2BP80zcxwlPqJEYfmD88/VG8kRvZehyFrO srSjffQMOlHNPn9sfQ== =riep -----END PGP SIGNATURE----- --mpusqSMnrFw03iOaN3vGPmIwLCSv1TDXT--