httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <>
Subject Re: cvs commit: apache/src CHANGES conf.h http_main.c mod_cgi.c
Date Tue, 19 Mar 1996 17:24:00 GMT
In reply to Robert S. Thau who said
>   detailed programming changes should not be noted
>   in CHANGES - only things which are likely to affect the end user.
> [catching up on old email]
> hmmm... most of Ben's advice was well-taken, but in this case, I tend
> to disagree.  I started the CHANGES file as a way of letting people
> know exactly what changed from internal release to internal release,
> and I think it serves a useful function that way, even with all the
> simple "cleaned-up such-and-such" error messages --- there are even
> a few current entries which just note correction of spelling errors.

I put forward my comments initially on this in what was probably private
mail to Ben some time ago.

I don't see any particular reason for a detailed CHANGES file since it's
all in the cvs logs. I see definate problems with trying to maintain
a CHANGES file since people have to write proper log messages for the commit
log and then have a tendency to skip doing it again for the CHANGES file so
it either has ommisions or totally useless on-liner's or even more pointless,
references to the commit logs.

I also think there's a genuine need for a higher-level change log that lists
the sort of changes that you'd want in a release-notice, such as bug fixes
and feature enhancements.

It was suggested that cvs automatically add it's log messages to the CHANGES
file, as I said, the functionality is there but you end up with some real
garbage getting into it, such as all the testing Ben and I have done on the
cvs commit scripts and really silly blunders that get backed out again
immediately. You'll also get things in the CHANGES file that don't look
good, like the disagreement there was recently. Overall, having cvs touch
CHANGES automatically isn't a great idea and therefore to keep the file
in as good a state as possible I don't think you should require that developers
waste time duplicating messages in the CHANGES file and the commit logs unless
it's a significant change that needs to be publically noted.

Groups like gcc disseminate the nitty-gritty of their development because
their cvs trees are in-house (at Cygnus). We can provide access to our
cvs tree (and I think we should) so anyone interested in the detailed
changes can see them together with diffs and generally much more usefull
information than a CHANGES file gives and then we should use the CHANGES
file to record the main points that someone interested in simply using a new
release would want to know.

Just my opinion.

  Paul Richards. Originative Solutions Ltd.  (Netcraft Ltd. contractor)
  Elsevier Science TIS online journal project.
  Phone: 0370 462071 (Mobile), +44 (0)1865 843155

View raw message