Re: Tramp changelog entries messes up lisp/ChangeLog

Re: Tramp changelog entries messes up lisp/ChangeLog

[Alex Schroeder]

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.

Tramp changelog entries messes up lisp/ChangeLog

[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.

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

Re: Tramp changelog entries messes up lisp/ChangeLog

[Eli Zaretskii]

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.

Re: Tramp changelog entries messes up lisp/ChangeLog

[Kai Großjohann]

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

Re: Tramp changelog entries messes up lisp/ChangeLog

[Eli Zaretskii]

> From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=)
> Date: Thu, 06 Feb 2003 14:49:52 +0100
> 
> I'm sorry.  Should I go back and summarize the ChangeLog entries and
> consolidate them into a single entry?

I don't think you need to do that; just modify all the dates to state
the date you checked in the changes.

Re: Tramp changelog entries messes up lisp/ChangeLog

[Kai Großjohann]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> I don't think you need to do that; just modify all the dates to state
> the date you checked in the changes.

Wouldn't a ChangeLog with 14 entries that all have the same date look
a bit strange?
-- 
A turnip curses Elvis

Re: Tramp changelog entries messes up lisp/ChangeLog

[Eli Zaretskii]

> From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=)
> Date: Fri, 07 Feb 2003 17:06:38 +0100
> 
> Wouldn't a ChangeLog with 14 entries that all have the same date look
> a bit strange?

I don't think it will look strange.  Anyway, you will see that we
already have quite a few of these in the logs.

Re: Tramp changelog entries messes up lisp/ChangeLog

[Kai Großjohann]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

>> From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=)
>> Date: Fri, 07 Feb 2003 17:06:38 +0100
>> 
>> Wouldn't a ChangeLog with 14 entries that all have the same date look
>> a bit strange?
>
> I don't think it will look strange.  Anyway, you will see that we
> already have quite a few of these in the logs.

Okay, I did it this way.
-- 
A turnip curses Elvis

Re: Tramp changelog entries messes up lisp/ChangeLog

[Richard Stallman]

    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.

Re: Tramp changelog entries messes up lisp/ChangeLog

[Eli Zaretskii]

> 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...

Re: Tramp changelog entries messes up lisp/ChangeLog

[Kai Großjohann]

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

Re: Tramp changelog entries messes up lisp/ChangeLog

[Richard Stallman]

    > I don't think you need to do that; just modify all the dates to state
    > the date you checked in the changes.

    Wouldn't a ChangeLog with 14 entries that all have the same date look
    a bit strange?

There is no need to repeat the date header.
We normally use just one date header for a whole series of changes
made on the same date by the same person.

Re: Tramp changelog entries messes up lisp/ChangeLog

[Kai Großjohann]

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

Re: Tramp changelog entries messes up lisp/ChangeLog

[Richard Stallman]

    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.

Re: Tramp changelog entries messes up lisp/ChangeLog

[Andreas Schwab]

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."

Re: Tramp changelog entries messes up lisp/ChangeLog

[Kai Großjohann]

Andreas Schwab <schwab@suse.de> writes:

> 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.

Thank you.  I've now done that, commit is in progress.
-- 
A turnip curses Elvis

Re: Tramp changelog entries messes up lisp/ChangeLog

[Kai Großjohann]

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