From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Darrington Subject: Re: [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses. Date: Thu, 22 Dec 2016 09:20:02 +0100 Message-ID: <20161222082001.GA3545@jocasta.intra> 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> <4b79e545-7ea6-3b6c-3a48-f5f1d6b1da3c@tobias.gr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35121) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cJybi-0000Mw-Ax for guix-devel@gnu.org; Thu, 22 Dec 2016 03:20:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cJybf-0008JG-2K for guix-devel@gnu.org; Thu, 22 Dec 2016 03:20:10 -0500 Received: from de.cellform.com ([88.217.224.109]:51811 helo=jocasta.intra) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cJybe-0008Gi-Li for guix-devel@gnu.org; Thu, 22 Dec 2016 03:20:06 -0500 Content-Disposition: inline In-Reply-To: <4b79e545-7ea6-3b6c-3a48-f5f1d6b1da3c@tobias.gr> 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: Tobias Geerinckx-Rice Cc: guix-devel@gnu.org --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable We can argue about this till we're blue in the face. But on a pragmatic level, Mark's question demonstrates perfectly that our current system is lacking. Other projects I work on which have a more conventional approach do not suffer from this problem. J' On Thu, Dec 22, 2016 at 06:56:56AM +0100, Tobias Geerinckx-Rice wrote: John, Danny, =20 [Any exasperation is due only to the sustained level of FUD I encounter about the Guix/GNU changelog format, and not aimed at John.] =20 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). =20 I don't think so. =20 1. What was ???outvoted??? (with solid argumentation) was hiding comme= nts documenting code itself in commit messages, when they would do more good as, well, comments. =20 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... =20 Most People??? badly overdo #2 when they should do #1 (consider the average *Hub pull request). The opposite is less common. =20 > 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. =20 I'd just finished writing the exact same e-mail as Danny ??? almost to= the sentence ??? when that arrived. So... it must be right! :-) =20 > That approach can work sometimes, but more often it is a=20 > non-starter. =20 [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' =20 Sorry, but the first three examples are silly. :-) =20 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. =20 That leaves bugfixes. =20 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.) =20 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. =20 > But nobody except me will care about bugs in the function which have > been fixed. =20 Exactly! In this patch, you're replacing buggy (?) code with shiny cod= e. That shouldn't take more than ~50 characters to note. =20 > 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. =20 +11, unfortunately from experience. =20 > That is what git blame is for. Be thankful for it! =20 No and God no. =20 That is exactly what ???git blame??? is not for. =20 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. =20 > I hope this explains why putting history in comments is harmful. =20 It does! But this is not something anyone here suggested. =20 > Having it in the commit message would certainly have avoided me=20 > having to explain the situation to Mark too. =20 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. =20 But yes, it could have been longer ??? and a comment :-) =20 Kind regards, =20 T G-R =20 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. =20 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. =20 --=20 Avoid eavesdropping. Send strong encrypted email. PGP Public key ID: 1024D/2DE827B3=20 fingerprint =3D 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key. --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlhbjLEACgkQimdxnC3oJ7MXsACfeO2PmfJAx9UuAsSX4E35+xpw hhcAmwQpF/eqcW3XNkKgqSpKPePEG4Lh =3zPx -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z--