Re: /srv/bzr/emacs/trunk r102688: Minor clean up to silence some gcc warnings.

Re: /srv/bzr/emacs/trunk r102688: Minor clean up to silence some gcc warnings.

[Romain Francoise]

This commit includes a change in src/lread.c that isn't documented.

Also, could you *please* commit ChangeLog cleanups separately?
It's just noise, it makes it harder to review the real changes.

Re: /srv/bzr/emacs/trunk r102688: Minor clean up to silence some gcc warnings.

[Stefan Monnier]

> This commit includes a change in src/lread.c that isn't documented.

Oops, indeed that was a pilot error, thanks for noticing.

> Also, could you *please* commit ChangeLog cleanups separately?

No, quite the contrary, people should not commit ChangeLog changes separately.

> It's just noise, it makes it harder to review the real changes.

Indeed, it is.  The solution is to stop maintaining the ChangeLog
files manually.


        Stefan

Re: /srv/bzr/emacs/trunk r102688: Minor clean up to silence some gcc warnings.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 19 Dec 2010 08:59:50 -0500
> Cc: emacs-devel@gnu.org
> 
> > Also, could you *please* commit ChangeLog cleanups separately?
> 
> No, quite the contrary, people should not commit ChangeLog changes separately.

He said "ChangeLog cleanups", not "ChangeLog changes".  Whitespace
changes, fixes of dates, reformatting, etc.

Re: /srv/bzr/emacs/trunk r102688: Minor clean up to silence some gcc warnings.

[Stefan Monnier]

>> > Also, could you *please* commit ChangeLog cleanups separately?
>> No, quite the contrary, people should not commit ChangeLog
>> changes separately.
> He said "ChangeLog cleanups", not "ChangeLog changes".  Whitespace
> changes, fixes of dates, reformatting, etc.

Oh, sorry, I'm too dense, aren't I?
Yes, I see it's more contentious, but it boils down to the same:
ChangeLog diffs just shouldn't be looked at.


        Stefan

Re: /srv/bzr/emacs/trunk r102688: Minor clean up to silence some gcc warnings.

[Štěpán Němec]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> > Also, could you *please* commit ChangeLog cleanups separately?
>>> No, quite the contrary, people should not commit ChangeLog
>>> changes separately.
>> He said "ChangeLog cleanups", not "ChangeLog changes".  Whitespace
>> changes, fixes of dates, reformatting, etc.
>
> Oh, sorry, I'm too dense, aren't I?
> Yes, I see it's more contentious, but it boils down to the same:
> ChangeLog diffs just shouldn't be looked at.

...which is precisely the point being made -- if you committed ChangeLog
cleanups separately, it would be much easier to never look at them. Not
mentioning bisecting, reverting and all the usual (D)VCS best
practices...

  Štěpán

Re: /srv/bzr/emacs/trunk r102688: Minor clean up to silence some gcc warnings.

[Stefan Monnier]

> ...which is precisely the point being made -- if you committed ChangeLog
> cleanups separately, it would be much easier to never look at them.

Quite the contrary: they'd even get their own revision-id.

> Not mentioning bisecting, reverting and all the usual (D)VCS best
> practices...

I fail to see the relationship between ChangeLog changes and bisecting.
In any case, the way forward is to stop using ChangeLog files.


        Stefan

Re: /srv/bzr/emacs/trunk r102688: Minor clean up to silence some gcc warnings.

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I fail to see the relationship between ChangeLog changes and
> bisecting.  In any case, the way forward is to stop using ChangeLog
> files.

I still find the ChangeLog rather useful.  Occasional extra verbiage in
the bzr diffs and an extra minute's editing work when merging branches
is not a large price to pay.

RE: /srv/bzr/emacs/trunk r102688: Minor clean up to silence somegcc warnings.

[Drew Adams]

> > In any case, the way forward is to stop using ChangeLog files.
> 
> I still find the ChangeLog rather useful.  Occasional extra 
> verbiage in the bzr diffs and an extra minute's editing work
> when merging branches is not a large price to pay.

And Emacs users often want to or sometimes need to understand the source code,
and sometimes across versions.  And users who write Elisp code sometimes want to
understand development changes within a given release cycle.

Users deserve the source code, including its comments (which often reflect on
implementation or design). Likewise its change logs (ditto).  Users should not
need to access BZR or any other v-c interface to get access to the change-log
info.  Delivering it as part of Emacs helps users.  Beyond delivering it with
Emacs, making it available via http also helps - as in
http://repo.or.cz/w/emacs.git/tree/HEAD:/lisp (or
http://bazaar.launchpad.net/~vcs-imports/emacs/trunk/files/head%3A/lisp/, which
doesn't work as well).

Change-log info is meta-info about the code and its behavior, just like comments
and doc and NEWS are.  Please keep it accessible to users locally, as part of
their Emacs installation/delivery.

Re: /srv/bzr/emacs/trunk r102688: Minor clean up to silence somegcc warnings.

[Karl Fogel]

"Drew Adams" <drew.adams@oracle.com> writes:
>And Emacs users often want to or sometimes need to understand the
>source code, and sometimes across versions.  And users who write Elisp
>code sometimes want to understand development changes within a given
>release cycle.
>
>Users deserve the source code, including its comments (which often reflect on
>implementation or design). Likewise its change logs (ditto).  Users should not
>need to access BZR or any other v-c interface to get access to the change-log
>info.  Delivering it as part of Emacs helps users.  Beyond delivering it with
>Emacs, making it available via http also helps - as in
>http://repo.or.cz/w/emacs.git/tree/HEAD:/lisp (or
>http://bazaar.launchpad.net/~vcs-imports/emacs/trunk/files/head%3A/lisp/, which
>doesn't work as well).
>
>Change-log info is meta-info about the code and its behavior, just like
>comments and doc and NEWS are.  Please keep it accessible to users
>locally, as part of their Emacs installation/delivery.

If "users should not need to access BZR" to get access to change-log
info, then that is not an argument for storing the ChangeLogs in BZR.

It is an argument for generating a user-friendly web page straight from
the version control logs (thus "making it available via http") and doing
something simliar when building a tarball distribution (thus "delivering
it with Emacs").

-Karl

RE: /srv/bzr/emacs/trunk r102688: Minor clean up to silence somegcc warnings.

[Drew Adams]

> If "users should not need to access BZR" to get access to change-log
> info, then that is not an argument for storing the ChangeLogs in BZR.
> 
> It is an argument for generating a user-friendly web page 
> straight from the version control logs (thus "making it available
> via http") and doing something simliar when building a tarball
> distribution (thus "delivering it with Emacs").

I guess you are agreeing with me, Karl (but I'm not too sure ;-)).

But just because it is helpful (IMO) to provide users such info locally and via
HTTP, that does not mean that we should not also provide vc access to such info.

And it does not say anything about where we "store" the info for Emacs Dev.  The
info can be available in more than one location, by copy and by pointer.  But
(IMO) users should obtain a copy along with the Emacs source code - that was my
point.

Vc systems are handy for creating, accessing, and storing change messages - no
question about it.  All I'm asking is that the info thus recorded continue to be
available also to users locally (and if possible via http), as part of the
delivered Emacs sources.

Re: /srv/bzr/emacs/trunk r102688: Minor clean up to silence somegcc warnings.

[Stefan Monnier]

> It is an argument for generating a user-friendly web page straight from
> the version control logs (thus "making it available via http") and doing
> something simliar when building a tarball distribution (thus "delivering
> it with Emacs").

Indeed.  Hopefully, at some point people will understand that this is
implicit in any discussion about getting rid of the ChangeLog files.


        Stefan

Re: /srv/bzr/emacs/trunk r102688: Minor clean up to silence some gcc warnings.

[Stefan Monnier]

>> I fail to see the relationship between ChangeLog changes and
>> bisecting.  In any case, the way forward is to stop using ChangeLog
>> files.
> I still find the ChangeLog rather useful.  Occasional extra verbiage in
> the bzr diffs and an extra minute's editing work when merging branches
> is not a large price to pay.

Agreed, which is why I'm not making any particular effort to get rid of
the ChangeLog files.  But I just point out that if someone wants to fix
those pesky ChangeLog diffs, (s)he should work towards getting rid of
the ChangeLog files rather than trying to impose some constraint on how
I edit them.


        Stefan