From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 5515625: ; ChangeLog.2 fixes Date: Sun, 25 Oct 2015 23:25:58 +0100 Message-ID: References: <20151025140139.5262.2147@vcs.savannah.gnu.org> <83fv0ydaap.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11411744906d3b0522f55689 X-Trace: ger.gmane.org 1445812019 18748 80.91.229.3 (25 Oct 2015 22:26:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Oct 2015 22:26:59 +0000 (UTC) Cc: bruce.connor.am@gmail.com, Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 25 23:26:59 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 1ZqTke-0008OG-O8 for ged-emacs-devel@m.gmane.org; Sun, 25 Oct 2015 23:26:56 +0100 Original-Received: from localhost ([::1]:49725 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqTkd-0003jf-TI for ged-emacs-devel@m.gmane.org; Sun, 25 Oct 2015 18:26:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55220) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqTkQ-0003ja-MG for emacs-devel@gnu.org; Sun, 25 Oct 2015 18:26:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZqTkP-0005Wq-Ds for emacs-devel@gnu.org; Sun, 25 Oct 2015 18:26:42 -0400 Original-Received: from mail-lf0-x22d.google.com ([2a00:1450:4010:c07::22d]:34907) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqTkN-0005WZ-02; Sun, 25 Oct 2015 18:26:39 -0400 Original-Received: by lfbn126 with SMTP id n126so94591112lfb.2; Sun, 25 Oct 2015 15:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uTcHheOXzDRHdAriIHUxImNYGEWV/TNm8rgQ437Vr3g=; b=SXjP/Cg6VPKRaTqasx2ZfheihxjpKd/g3QoOvf54mf4/dO1xgQ6ikWYyhxOa9OV2rb WLumRMxy8lb5a11XeZGuOuYJKmigLUz5+0a2QLoi4c4lrytKqiTYxFMkSErU/+2YcRHZ G3YGKMFwB644FFdsWEwKeUNecECNtJfNrvl9NPEXdYyEjIFIVXY4+VR7A9+05AGvxgZS dZ8p9Y9XiUlA6VZrYyTGNAxVmGjQ2d7YU92NvhTED4PUufKXeLePvjGDRMJNzNunz/Su Ho76PdoLQwXYWzYmbkpHxDxobu9cr3UAhbsoLA1VY8gvpFbjHW9JB80V9bMiIHTuoIjz Inlg== X-Received: by 10.25.165.84 with SMTP id o81mr10317284lfe.80.1445811998189; Sun, 25 Oct 2015 15:26:38 -0700 (PDT) Original-Received: by 10.25.217.135 with HTTP; Sun, 25 Oct 2015 15:25:58 -0700 (PDT) In-Reply-To: <83fv0ydaap.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c07::22d 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:192627 Archived-At: --001a11411744906d3b0522f55689 Content-Type: text/plain; charset=UTF-8 On Sun, Oct 25, 2015 at 8:21 PM, Eli Zaretskii wrote: > That's correct. Personally, I think the commit messages themselves > could have the period in this special case, but that's just MO. I agree. > This is borderline, and you might as well leave those untouched. The ones I change tend to be like Use `unless' to have one fewer `not' * lisp/vc/vc-git.el (vc-git-resolve-when-done): Use `unless' to have one fewer `not'. or Fix customization type of `even-window-sizes'. * lisp/window.el (even-window-sizes): Fix customization type. where, really, the header doesn't add anything of value (to the ChangeLog). > These are issues of style, so there are no hard rules. Back when we > maintained ChangeLog files by hand the style was not really uniform, > either. Yes, I know. I didn't try then, and do not try now, to have absolute consistency, just to increment it a little ;-) > + * lisp/character-fold.el: Many improvements. > (character-fold-search-forward, character-fold-search-backward): > - New command > The "many improvements" part could simply go away, it doesn't add any > useful information. I'd tend to agree, but I'm conservative in removing other people's words unless they are really redundant (as in the cases above). > I think the commit message should have been as corrected to begin > with, and a header line should say something else, without being > formatted as an entry. Certainly. The best messages IMHO are those who do *not* format the header line as an entry. They are usually more informative and less redundant. > This is okay, but when I see such changes, I always ask myself whether > it's worth the trouble. Your call. Some of these are because I use column markers to see which entries go over 75 or 80 columns, and some because I agree with Stefan that having dangling words is ugly. Which doesn't mean that I don't leave some of these, when the alternative is equally ugly, of course... > 2015-10-20 Dmitry Gutov > > - Don't declare vc-exec-after anymore > - > * lisp/vc/vc-svn.el: > * lisp/vc/vc-mtn.el: > * lisp/vc/vc-hg.el: > * lisp/vc/vc-cvs.el: > * lisp/vc/vc-git.el: > - * lisp/vc/vc-bzr.el: Don't declare vc-exec-after anymore. Its > - usages have been replaced with vc-run-delayed. > + * lisp/vc/vc-bzr.el: Don't declare vc-exec-after anymore. > + Its usages have been replaced with vc-run-delayed. > > Not sure why the header line was deleted, it looks OK to me. Borderline, but the header is duplicated word-for-word in the entry. I think I would've left it if the file list were quite long. Thanks for your comments. J --001a11411744906d3b0522f55689 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Oct 25, 2015 at 8:21 PM, Eli Zaretskii <eliz@gnu.org> wrote:
<= br>
> That's correct.=C2=A0 Personally, I think the commit messa= ges themselves
> could have the period in this special case, but that= 's just MO.

I agree.

> Th= is is borderline, and you might as well leave those untouched.

The ones I change tend to be like

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Use `unless' to have one fewer `not'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * lisp/vc/vc-git.el (vc-git-resolve-wh= en-done): Use `unless' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 have on= e fewer `not'.

or

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Fix customization type of `even-window-= sizes'.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * lisp/window.el (even-wi= ndow-sizes): Fix customization type.

where, = really, the header doesn't add anything of value (to the ChangeLog).

> These are issues of style, so there are no hard= rules.=C2=A0 Back when we
> maintained ChangeLog files by hand the s= tyle was not really uniform,
> either.

Yes, I know.= I didn't try then, and do not try now, to have absolute consistency, j= ust to increment it a little ;-)

> =C2=A0 + =C2= =A0 =C2=A0 =C2=A0 * lisp/character-fold.el: Many improvements.
> =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (character-fold-search-forward, character-f= old-search-backward):
> =C2=A0 - =C2=A0 =C2=A0 =C2=A0 New command
=
> The "many improvements" part could simply go = away, it doesn't add any
> useful information.

= I'd tend to agree, but I'm conservative in removing other people= 9;s words unless they are really redundant (as in the cases above).

> I think the commit message should have been as corre= cted to begin
> with, and a header line should say something else, wi= thout being
> formatted as an entry.

Certainly. The= best messages IMHO are those who do *not* format the header line as an ent= ry. They are usually more informative and less redundant.

> This is okay, but when I see such changes, I always ask myself= whether
> it's worth the trouble.=C2=A0 Your call.

=
Some of these are because I use column markers to see which entries go= over 75 or 80 columns, and some because I agree with Stefan that having da= ngling words is ugly. Which doesn't mean that I don't leave some of= these, when the alternative is equally ugly, of course...

> =C2=A0 =C2=A02015-10-20 =C2=A0Dmitry Gutov =C2=A0<dgutov@yandex.ru>
= >
> =C2=A0 - =C2=A0 =C2=A0 =C2=A0 Don't declare vc-exec-after = anymore
> =C2=A0 -
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * lisp/= vc/vc-svn.el:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * lisp/vc/vc-mtn.e= l:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * lisp/vc/vc-hg.el:
> = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * lisp/vc/vc-cvs.el:
> =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 * lisp/vc/vc-git.el:
> =C2=A0 - =C2=A0 =C2= =A0 =C2=A0 * lisp/vc/vc-bzr.el: Don't declare vc-exec-after anymore.=C2= =A0 Its
> =C2=A0 - =C2=A0 =C2=A0 =C2=A0 usages have been replaced wit= h vc-run-delayed.
> =C2=A0 + =C2=A0 =C2=A0 =C2=A0 * lisp/vc/vc-bzr.el= : Don't declare vc-exec-after anymore.
> =C2=A0 + =C2=A0 =C2=A0 = =C2=A0 Its usages have been replaced with vc-run-delayed.
>
> N= ot sure why the header line was deleted, it looks OK to me.

Borderline, but the header is duplicated word-for-word in the entry. I t= hink I would've left it if the file list were quite long.
Thanks for your comments.

=C2=A0 =C2= =A0 =C2=A0J

--001a11411744906d3b0522f55689--