From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.emacs.devel Subject: Re: PROPOSAL: Move to git, now that bzr is no longer a req. Date: Sun, 05 Jan 2014 21:43:06 +0100 Message-ID: <874n5i40th.fsf@mid.deneb.enyo.de> References: <20140102095347.6834E381D0C@snark.thyrsus.com> <87fvp6bdd9.fsf_-_@ktab.red-bean.com> <8761q1ljny.fsf@gmail.com> <20140103175006.GE17261@thyrsus.com> <87ppo6u3mr.fsf@mid.deneb.enyo.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1388954600 21099 80.91.229.3 (5 Jan 2014 20:43:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Jan 2014 20:43:20 +0000 (UTC) Cc: esr@thyrsus.com, thierry.volpiatto@gmail.com, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 05 21:43:27 2014 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 1VzuXe-0002mt-2f for ged-emacs-devel@m.gmane.org; Sun, 05 Jan 2014 21:43:26 +0100 Original-Received: from localhost ([::1]:59355 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzuXd-00033o-Mh for ged-emacs-devel@m.gmane.org; Sun, 05 Jan 2014 15:43:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57125) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzuXW-00032n-91 for emacs-devel@gnu.org; Sun, 05 Jan 2014 15:43:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VzuXR-0003el-Fj for emacs-devel@gnu.org; Sun, 05 Jan 2014 15:43:18 -0500 Original-Received: from ka.mail.enyo.de ([87.106.162.201]:56652) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzuXM-0003e5-89; Sun, 05 Jan 2014 15:43:08 -0500 Original-Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1VzuXK-0004Xs-Kg; Sun, 05 Jan 2014 21:43:06 +0100 Original-Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1VzuXK-0005oq-Fs; Sun, 05 Jan 2014 21:43:06 +0100 In-Reply-To: (Richard Stallman's message of "Sun, 05 Jan 2014 15:23:28 -0500") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 87.106.162.201 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:167398 Archived-At: * Richard Stallman: > > Our ChangeLog files are very useful in debugging. > > Then you're not following the GNU Coding Standards. :-) > > There is no constructive point there, only an insult. It was not intended as such, I'm sorry if it came across this way. > If you have some constructive criticism, please state it clearly. In particular, this advice does not make much sense to me: | For changes to code, there=E2=80=99s no need to describe the full purpose= of | the changes or how they work together. If you think that a change | calls for explanation, you=E2=80=99re probably right. Please do explain i= t=E2=80=94but | please put the full explanation in comments in the code, where people | will see it whenever they see the code. For example, =E2=80=9CNew functio= n=E2=80=9D is | enough for the change log when you add a function, because there | should be a comment before the function definition to explain what it | does. I find this pretty strange because adding comments typically does not make sense when one removes code (which sometimes needs *more* explanation than adding code). And when rearranging code, there is often no single place to put a comment *why* this was done. I never consult changelog files if I have the full VCS history. In my experience, grepping diffs, annotate/blame, or bisecting is more helpful (assuming that I have a hunch history provides an explanation) because the raw bits are usually less misleading, and the changelog files are often deliberately devoid of any additional information. The lisp/ changelog seems to deviate from this a bit, but there are other GNU projects where the changelog rules are enforced through review.