Suggestions for ChangeLog: cut it, and start config/ChangeLog

Suggestions for ChangeLog: cut it, and start config/ChangeLog

[Hans-Peter Nilsson]

Subject says it most.

The gcc/ChangeLog is now larger than any previous one, adding to "cvs up"
delay when local changes are made, for one reason.
 Perhaps cutting a ChangeLog.2 at Jan 1 would be good; it would slice off
5/7 roughly.

I'd also like to propose having a config/ChangeLog, for port changes and
other config/* changes.
 Maybe that has been discussed and rejected at some time, though I don't
remember it and no valid hits turned up when searching for "ChangeLog and
config".

brgds, H-P

Re: Suggestions for ChangeLog: cut it, and start config/ChangeLog

[Stan Shebs]

Hans-Peter Nilsson wrote:
> 
> Subject says it most.
> 
> The gcc/ChangeLog is now larger than any previous one, adding to "cvs up"
> delay when local changes are made, for one reason.
>  Perhaps cutting a ChangeLog.2 at Jan 1 would be good; it would slice off
> 5/7 roughly.

GDB has been cutting ChangeLogs at year boundaries for quite a while, and
that seems to work well.  If you know the year of a change, you can go straight
to the right file.  Also, ChangeLogs at the beginning of a year are especially
quick to update!

> I'd also like to propose having a config/ChangeLog, for port changes and
> other config/* changes.
>  Maybe that has been discussed and rejected at some time, though I don't
> remember it and no valid hits turned up when searching for "ChangeLog and
> config".

That doesn't seem like such a good idea; very often changes in generic code
are associated with changes to config/ code, so if you're researching history,
you'll have to have both ChangeLogs up at the same time - which defeats the
purpose of making them separate.

Stan

Re: Suggestions for ChangeLog: cut it, and start config/ChangeLog

[Jeffrey A Law]

  In message < Pine.BSF.4.10.10003152053340.11806-100000@dair.pair.com >you write
:
  > The gcc/ChangeLog is now larger than any previous one, adding to "cvs up"
  > delay when local changes are made, for one reason.
  >  Perhaps cutting a ChangeLog.2 at Jan 1 would be good; it would slice off
  > 5/7 roughly.
Trimming the ChangeLog on occasion is a good thing.  I believe the plan was
to trim it for each major release.  So now might not be the best time since
we haven't started the next major release cycle yet.


  > I'd also like to propose having a config/ChangeLog, for port changes and
  > other config/* changes.
  >  Maybe that has been discussed and rejected at some time, though I don't
  > remember it and no valid hits turned up when searching for "ChangeLog and
  > config".
I think this would be a major mistake.

The reason you get no hits is policy for ChangeLogs in gcc -- for reasons I
never fully understood we do not write "config" in the filename for the
ChangeLog entry.

jeff

Re: Suggestions for ChangeLog: cut it, and start config/ChangeLog

[Martin v. Loewis]

> The gcc/ChangeLog is now larger than any previous one, adding to "cvs up"
> delay when local changes are made

That's indeed a PITA. For that reason, I copy all my changelog entries
to a local file Changelog.martin. That also avoids merging conflicts.

Regards,
Martin