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: Wed, 21 Dec 2016 10:56:47 +0100 Message-ID: <20161221095646.GA6917@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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cJddu-0005Yp-LJ for guix-devel@gnu.org; Wed, 21 Dec 2016 04:57:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cJddq-0003Bs-AU for guix-devel@gnu.org; Wed, 21 Dec 2016 04:57:02 -0500 Received: from de.cellform.com ([88.217.224.109]:51762 helo=jocasta.intra) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cJddp-00032s-TM for guix-devel@gnu.org; Wed, 21 Dec 2016 04:56:58 -0500 Content-Disposition: inline In-Reply-To: <20161221093656.400cd7cd@scratchpost.org> 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: Danny Milosavljevic Cc: guix-devel@gnu.org --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 21, 2016 at 09:36:56AM +0100, Danny Milosavljevic wrote: > Sure (I would like to see a convention where such explanations are > put in the commit messaage, but I have previously been outvoted on > that issue): 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 No, please don't put explanations into the commit message. But do put = them into the source code as a comment. That approach can work sometimes, but more often it is a non-starter. A few example scenarios: 1. Suppose I need to do a global search and replace, changing a variable na= me=20 across many files. It would be ludicrous to have in dozens of files: ;; This variable used to be called "bar" but we changed it to "foo" because= ... (+ foo 4) When reviewing the code, frankly nobody CARES what it used to be called! 2. Suppose we decide to delete something from a file. It would be equally= =20 ludicrous to have: ;; There used to be some code here which did: ;;(large-block-of-code ;;. ;;. ;;. ;;. ;;. ;;.) ;; but we decided to delete it because ... Again I don't care what used to be in a file. 3. Suppose that, due to a design change, a new variable has to be=20 introduced in places thoughout the code: It would be bizarre,=20 distracting and stupid to have in many places: ;; Since we introduced the frobnicator module the signature for ;; calling wiz needs to pass it as an argument. (wiz frobnicator) 4. Suppose I fix a bug: It would be pejorative to write: ;; Fred Bloggs who wrote the function typed 'xyz' when he ;; ought to have put 'abc', because ... I am just glad when a bug has been fixed. If somebody changes some code of mine, I might be curious as to why. In that case I can check the git log. If that person has (like he should) explained in the git log why my code was wrong, I will be=20 gratefull for the explanation and the fix. But nobody except me will care about bugs in the function which have been fixed. I'm also working on other projects, some of which do what you propose.= What I often end up having to do there is do git blame, then git log for e= ach line, in order to find out why the source code does what it does. Let's= not do that here.=20 That is what git blame is for. Be thankful for it! There's a perfectly good inline mechanism for it: Comments. I am not saying that no explanations of *current* code should=20 be put in comments. It is of course good practice to explain the working of tricky parts of code. But to put a *history* of the code inline is just distraction and a misuse of comments. Your proposal takes us back to the 1970s - Occassionally I come across code done like that. It is a nightmare to follow. I am not normally interested in the history of the code when I look a the source. I am=20 interested in what it does now. If I want the history, then use git. That is (amoung other things) what it was designed for. I hope this explains why putting history in comments is harmful. Having it in the commit message would certainly have avoided me having to explain the situation to Mark too. If this doesn't convince you, then I don't know what more I can say. But I find that our current git logs are just useless. They don't tell me anything which I couldn't have found out by running=20 git diff/git blame. J' --=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. --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlhaUd4ACgkQimdxnC3oJ7O9UwCdEbwP5lauJuuIBhWZlKyBeJva XzUAn0r3uACa+u6SbBval/dTuMGITUxP =Z+8y -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv--