* Tramp changelog entries messes up lisp/ChangeLog
@ 2003-02-05 23:12 Kim F. Storm
2003-02-05 22:53 ` Alex Schroeder
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Kim F. Storm @ 2003-02-05 23:12 UTC (permalink / raw)
I noticed that Kai (again) has included a big section of another
ChangeLog file (for Tramp) into lisp/ChangeLog maintaining the dates
of the original changelog. I don't object to keeping those dates, but
it completely messes up the sequence of entries in the ChangeLog file,
as illustrated below.
I would suggest creating a new lisp/net/tramp/ directory and move
the tramp*.el files there, and create a separate ChangeLog file there.
I suppose it will then make sense to move all of the tramp related
changelog entries from lisp/ChangeLog to lisp/net/tramp/ChangeLog.
Here's the evidence:
2003-02-05 Kai Großjohann <kai.grossjohann@uni-duisburg.de>
* net/tramp.el: Version 2.0.29 released.
2003-02-04 Michael Albinus <Michael.Albinus@alcatel.de>
2003-02-03 Kai Großjohann <kai.grossjohann@uni-duisburg.de>
2003-01-28 Michael Albinus <Michael.Albinus@alcatel.de>
2003-01-27 Michael Albinus <Michael.Albinus@alcatel.de>
2003-01-25 Michael Albinus <Michael.Albinus@alcatel.de>
2003-01-24 Michael Albinus <Michael.Albinus@alcatel.de>
2003-01-21 Michael Albinus <Michael.Albinus@alcatel.de>
2003-01-21 Michael Albinus <Michael.Albinus@alcatel.de>
2003-01-14 Kai Großjohann <kai.grossjohann@uni-duisburg.de>
2003-01-13 Michael Albinus <Michael.Albinus@alcatel.de>
2003-01-12 Michael Albinus <Michael.Albinus@alcatel.de>
2003-01-02 Michael Albinus <Michael.Albinus@alcatel.de>
2003-01-02 Kai Großjohann <kai.grossjohann@uni-duisburg.de>
.. time warp ...
2003-02-04 Richard M. Stallman <rms@gnu.org>
2003-02-04 Juanma Barranquero <lektu@terra.es>
2003-02-04 Francesco Potortì <pot@gnu.org>
2003-02-04 Kim F. Storm <storm@cua.dk>
2003-02-03 Juanma Barranquero <lektu@terra.es>
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Tramp changelog entries messes up lisp/ChangeLog
2003-02-05 23:12 Tramp changelog entries messes up lisp/ChangeLog Kim F. Storm
@ 2003-02-05 22:53 ` Alex Schroeder
2003-02-06 5:51 ` Eli Zaretskii
2003-02-06 13:49 ` Kai Großjohann
2003-02-07 23:10 ` Richard Stallman
2 siblings, 1 reply; 17+ messages in thread
From: Alex Schroeder @ 2003-02-05 22:53 UTC (permalink / raw)
Cc: emacs-devel
storm@cua.dk (Kim F. Storm) writes:
> I would suggest creating a new lisp/net/tramp/ directory and move
> the tramp*.el files there, and create a separate ChangeLog file there.
> I suppose it will then make sense to move all of the tramp related
> changelog entries from lisp/ChangeLog to lisp/net/tramp/ChangeLog.
But will you do this for every package that is maintained externally?
And even if the order is wrong -- when exactly will that confuse us?
I only ever use ChangeLog entries when I want to answer questions like
"what where the recent changes related to file/variable/function foo"
-- and for that, there need only be a very rough ordering of items.
Essentially, changes for every file, every variable, and every
function should be more or less chronological, but not the entries by
themselves. Let me illustrate.
This is OK, because all A changes are ordered, and all B changes are
ordered:
2003-02-03 changes B
2003-02-02 changes B
* time warp *
2003-02-05 changes A
2003-02-04 changes A
2003-02-01 changes B
This is not OK, because searching backwards for B will yield confusing
results. But even then, if there are no unreasonable jumps in the
order of changes to B, I would not mind:
2003-02-03 changes B
2003-02-02 changes C
* time warp *
2003-02-05 changes B
2003-02-04 changes A
2003-02-01 changes B
In this case, two different people changed B after 2003-02-01, and
perhaps one of them even had to resolve conflicts, and that would
explain the time line. But as I said -- I will often use C-s to
search for some item foo, and jump up and down in the ChangeLog. So
as long as it is just aproximately correct, I don't mind time warps.
Alex.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Tramp changelog entries messes up lisp/ChangeLog
2003-02-05 22:53 ` Alex Schroeder
@ 2003-02-06 5:51 ` Eli Zaretskii
0 siblings, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2003-02-06 5:51 UTC (permalink / raw)
Cc: emacs-devel
On Wed, 5 Feb 2003, Alex Schroeder wrote:
> storm@cua.dk (Kim F. Storm) writes:
>
> > I would suggest creating a new lisp/net/tramp/ directory and move
> > the tramp*.el files there, and create a separate ChangeLog file there.
> > I suppose it will then make sense to move all of the tramp related
> > changelog entries from lisp/ChangeLog to lisp/net/tramp/ChangeLog.
>
> But will you do this for every package that is maintained externally?
Probably not. Which means maintainers of such packages should retag
their entries with the check-in date.
Perhaps we should have a command to do that automatically on a region of
a ChangeLog. (Maybe there already is such a command, I didn't check.)
> And even if the order is wrong -- when exactly will that confuse us?
I frequently browse ChangeLog files to find out what was the sequence of
changes, when some change breaks some feature. So I think the dates
should be in monotonous order, like they have been until now.
Also, it is confusing if the dates in CVS and in the change log are very
different.
> I only ever use ChangeLog entries when I want to answer questions like
> "what where the recent changes related to file/variable/function foo"
> -- and for that, there need only be a very rough ordering of items.
Some changes interact, you know.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Tramp changelog entries messes up lisp/ChangeLog
2003-02-05 23:12 Tramp changelog entries messes up lisp/ChangeLog Kim F. Storm
2003-02-05 22:53 ` Alex Schroeder
@ 2003-02-06 13:49 ` Kai Großjohann
2003-02-06 19:15 ` Eli Zaretskii
2003-02-07 23:10 ` Richard Stallman
2 siblings, 1 reply; 17+ messages in thread
From: Kai Großjohann @ 2003-02-06 13:49 UTC (permalink / raw)
storm@cua.dk (Kim F. Storm) writes:
> I noticed that Kai (again) has included a big section of another
> ChangeLog file (for Tramp) into lisp/ChangeLog maintaining the dates
> of the original changelog.
I'm sorry. Should I go back and summarize the ChangeLog entries and
consolidate them into a single entry?
I'd like to credit Michael with things he has done -- so should I
make two ChangeLog entries out of this, one for Michael and one for
me? Or should there be just one entry?
In the past, I've tried to summarize the ChangeLog entries, but this
time I was too lazy to do that and somewhat in a hurry to just get
the new version out. (But I still missed the XEmacs package.) Sorry
about this.
--
A turnip curses Elvis
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Tramp changelog entries messes up lisp/ChangeLog
2003-02-05 23:12 Tramp changelog entries messes up lisp/ChangeLog Kim F. Storm
2003-02-05 22:53 ` Alex Schroeder
2003-02-06 13:49 ` Kai Großjohann
@ 2003-02-07 23:10 ` Richard Stallman
2003-02-08 9:44 ` Eli Zaretskii
` (2 more replies)
2 siblings, 3 replies; 17+ messages in thread
From: Richard Stallman @ 2003-02-07 23:10 UTC (permalink / raw)
Cc: Kim F. Storm
I noticed that Kai (again) has included a big section of another
ChangeLog file (for Tramp) into lisp/ChangeLog maintaining the dates
of the original changelog. I don't object to keeping those dates, but
it completely messes up the sequence of entries in the ChangeLog file,
as illustrated below.
When merging in changes that were made on various dates, the proper
thing to do is to combine and condense the change log entries and
enter them under a single date, which is the date that you installed
all the changes.
Kai, could you do that?
I'd like to credit Michael with things he has done -- so should I
make two ChangeLog entries out of this, one for Michael and one for
me?
That is a good way to do it.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Tramp changelog entries messes up lisp/ChangeLog
2003-02-07 23:10 ` Richard Stallman
@ 2003-02-08 9:44 ` Eli Zaretskii
2003-02-10 10:34 ` Richard Stallman
2003-02-09 10:48 ` Kai Großjohann
2003-02-09 14:44 ` Kai Großjohann
2 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2003-02-08 9:44 UTC (permalink / raw)
Cc: emacs-devel
> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 07 Feb 2003 18:10:07 -0500
>
> When merging in changes that were made on various dates, the proper
> thing to do is to combine and condense the change log entries and
> enter them under a single date, which is the date that you installed
> all the changes.
This is sometimes hard to do, especially when the original sequence
of log entries is long. This is because the original log frequently
mentions multiple changes to the same function; merging them all into
a single entry for each function is time-consuming and might actually
lose information (e.g., when changes are backed up).
So I think just re-dating the changes is good enough. But that's
me...
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Tramp changelog entries messes up lisp/ChangeLog
2003-02-08 9:44 ` Eli Zaretskii
@ 2003-02-10 10:34 ` Richard Stallman
2003-02-11 17:31 ` Kai Großjohann
0 siblings, 1 reply; 17+ messages in thread
From: Richard Stallman @ 2003-02-10 10:34 UTC (permalink / raw)
Cc: emacs-devel
This is sometimes hard to do, especially when the original sequence
of log entries is long. This is because the original log frequently
mentions multiple changes to the same function; merging them all into
a single entry for each function is time-consuming and might actually
lose information (e.g., when changes are backed up).
I find this makes it easier to grasp the changes overall.
It is worth doing.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Tramp changelog entries messes up lisp/ChangeLog
2003-02-10 10:34 ` Richard Stallman
@ 2003-02-11 17:31 ` Kai Großjohann
0 siblings, 0 replies; 17+ messages in thread
From: Kai Großjohann @ 2003-02-11 17:31 UTC (permalink / raw)
Richard Stallman <rms@gnu.org> writes:
> This is sometimes hard to do, especially when the original sequence
> of log entries is long. This is because the original log frequently
> mentions multiple changes to the same function; merging them all into
> a single entry for each function is time-consuming and might actually
> lose information (e.g., when changes are backed up).
>
> I find this makes it easier to grasp the changes overall.
> It is worth doing.
I've now looked and tried to condense entries such that the ChangeLog
reports the overall change from beginning to end, without
intermediary steps.
I hope I didn't miss anything.
--
A turnip curses Elvis
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Tramp changelog entries messes up lisp/ChangeLog
2003-02-07 23:10 ` Richard Stallman
2003-02-08 9:44 ` Eli Zaretskii
@ 2003-02-09 10:48 ` Kai Großjohann
2003-02-10 10:43 ` Andreas Schwab
2003-02-09 14:44 ` Kai Großjohann
2 siblings, 1 reply; 17+ messages in thread
From: Kai Großjohann @ 2003-02-09 10:48 UTC (permalink / raw)
Cc: Kim F. Storm
Richard Stallman <rms@gnu.org> writes:
> When merging in changes that were made on various dates, the proper
> thing to do is to combine and condense the change log entries and
> enter them under a single date, which is the date that you installed
> all the changes.
>
> Kai, could you do that?
Yes, I will do that.
Sorry for the trouble I caused.
--
A turnip curses Elvis
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Tramp changelog entries messes up lisp/ChangeLog
2003-02-09 10:48 ` Kai Großjohann
@ 2003-02-10 10:43 ` Andreas Schwab
2003-02-10 10:59 ` Kai Großjohann
0 siblings, 1 reply; 17+ messages in thread
From: Andreas Schwab @ 2003-02-10 10:43 UTC (permalink / raw)
Cc: emacs-devel
While you are at it, IMHO you should change the line "Version 2.0.29
released." in man/ChangeLog to make it clear that the version number
refers to the tramp release.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Tramp changelog entries messes up lisp/ChangeLog
2003-02-07 23:10 ` Richard Stallman
2003-02-08 9:44 ` Eli Zaretskii
2003-02-09 10:48 ` Kai Großjohann
@ 2003-02-09 14:44 ` Kai Großjohann
2 siblings, 0 replies; 17+ messages in thread
From: Kai Großjohann @ 2003-02-09 14:44 UTC (permalink / raw)
Richard Stallman <rms@gnu.org> writes:
> When merging in changes that were made on various dates, the proper
> thing to do is to combine and condense the change log entries and
> enter them under a single date, which is the date that you installed
> all the changes.
>
> Kai, could you do that?
Done. I've not shortened the actual text, just reformatted the
entries. I hope it's okay now, but if you would like reformulation
of the text, too, just holler.
--
A turnip curses Elvis
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2003-02-11 17:31 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-02-05 23:12 Tramp changelog entries messes up lisp/ChangeLog Kim F. Storm
2003-02-05 22:53 ` Alex Schroeder
2003-02-06 5:51 ` Eli Zaretskii
2003-02-06 13:49 ` Kai Großjohann
2003-02-06 19:15 ` Eli Zaretskii
2003-02-07 16:06 ` Kai Großjohann
2003-02-07 17:14 ` Eli Zaretskii
2003-02-07 18:37 ` Kai Großjohann
2003-02-09 12:39 ` Richard Stallman
2003-02-07 23:10 ` Richard Stallman
2003-02-08 9:44 ` Eli Zaretskii
2003-02-10 10:34 ` Richard Stallman
2003-02-11 17:31 ` Kai Großjohann
2003-02-09 10:48 ` Kai Großjohann
2003-02-10 10:43 ` Andreas Schwab
2003-02-10 10:59 ` Kai Großjohann
2003-02-09 14:44 ` Kai Großjohann
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).