Re: Linux 1.3.45 change log

Brian Dowling (bdowling@camelot.ccs.neu.edu)
Fri, 01 Dec 95 00:43:20 -0500


> On Wed, 29 Nov 1995, Nick Andrew wrote:
>
> > How about logging recent changes in the comment at the top of the source
> > file and removing older changes after some time has passed? That will
> > prevent the source files from growing without bound and will also
> > provide some documentation of code changes over time.
>
> Do you mean spread the change log out over all the files it effects?
> That would be a maintenance nightmare. Keep the change logs together in
> one easy to search and maintain location. If you have to go hunting
> through the source for comments about what was changed, you might as well
> look through the patches.

I think this is a good idea. I have long been slightly annoyed by the fact
that the toplevel linux/CHANGES file has been the same since 0.99. Granted I
realize it's a piece history, and rightly so, but it should be current too.

Putting the changes in the source files themselves is a good practice. Most
of the time when something is wrong, you have an idea of where to look and you
can see the change information right there. If there was a standardization to
how the changes are stored in the files, it wouldn't be hard to have a program
to extract the changes and update linux/CHANGES or some other file (make
changelog). The output of this might even be more useful than
'simplified changlogs', it would probably prefix changes from each file
with the name of the file, etc, making it interesting..

Another good feature is that it would make patch files self documenting.

This brings up a something I've been wondering about for a while. Has anyone
recommended or thought about using a Revision control system? Such as RCS? I
imagine it hasn't been done because it would probably be complicate
maintenance, given the distributed nature of development, but it would be
nice. I was thinking, perhaps, that the RCS trees could be distributed
separately from kernel releases, those that do hacking would get the RCS tree.
The tree could eventually be pruned such that the revisions past a certain
kernel release could be deleted (to make it smaller if it gets huge).

If we could figure out a way for everyone to use it, it'd also make a
standardized change log much easier. Just put $Log$ in a C comment and then
always put decent comments when checking in revisions.

I was also thinking I could write some quick tools generate the RCS tree.
I'd sorta auto-manage the RCS tree from each new release. This doesn't help
the changelog situation though (I thought about it before this topic came up).

Of course there are always those 'global changes' that affected a lot of files
that need some place to go. Perhaps a standard "Changes.here" file in every
sub directory that would contain these? Then these could be collected for the
global CHANGES file as well.

...brian