Subject: Re: cvs commit: apache/src CHANGES conf.h http_main.c mod_cgi.c
To: new-httpd@hyperreal.com
Date: Tue, 19 Mar 1996 17:57:04 +0000 (GMT)
From: Ben Laurie <ben@gonzo.ben.algroup.co.uk>
In-Reply-To: <199603191724.RAA06806@tees> from "Paul Richards" at Mar 19,
 96 05:24:00 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3506      
Message-ID: <9603191757.aa18523@gonzo.ben.algroup.co.uk>
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

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

I know its rare that Paul and I see eye-to-eye on anything  ;-) but I must
agree with him on this point. Having lived with systems which require me to
note changes twice, it is definitely true that one or other of the logs
suffers. Since the messages are most useful in CVS and can be extracted in
their entirety if desired, I would say that in the commit messages is the
right place for them to go.

Cheers,

Ben.

> 
> -- 
>   Paul Richards. Originative Solutions Ltd.  (Netcraft Ltd. contractor)
>   Elsevier Science TIS online journal project.
>   Email: p.richards@elsevier.co.uk
>   Phone: 0370 462071 (Mobile), +44 (0)1865 843155

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.