Date: Mon, 4 Mar 1996 21:31:26 GMT
From: Paul Richards <p.richards@elsevier.co.uk>
Message-Id: <199603042131.VAA24497@tees>
To: new-httpd@hyperreal.com
Subject: Re: CVS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: 9fHvwqetFeqm5E7WtI8hsg==
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com
Status: O


I'm forwarding this to the list for more open discussion
 
 
> > > BTW, you really should modify CHANGES as well. In a previous incarnation I
> > > have found this most useful for tracking down particular patches, as the
> > > timestamp on the CHANGES file leads to the other changes. Besides, it 
needs
> > > modifying.
> > 
> > I'm not so keen on this, mainly because it's extra work and people forget
> > and the CHANGES file will end up being enormous if every little one line
> > fix goes in it. Everything is in the cvs logs anyway and generally in more
> > detail than people bother to put in the CHANGES file.
> 
> Yes, it may be in the logs in more detail, but the changes do need to be 
noted.
> Particularly for non-CVS users, who can't see the logs. Unless we start
> including them in the source, that is.

Hmm, well, I'm inclined to say that if you want this level of detail then
cvs *is* the place to get it since it's the only place where you can see
exactly what has been done.

> 
> > 
> > I've seen this degrade over time since after someone's carefully explained
> > their patch in the cvs commit log when the get to the CHANGES file they've
> > had enough and type in some useless one line reference.
> > 
> > The CHANGES file would be important if cvs wasn't being used but I think
> > it's largely redundant for this level of detail. What it should be used
> > for is changes that impact the end user, i.e. change of functionality,
> > fixes to known and reported bugs etc. so that we have something to show
> > people when we release so they can see what the new release will do for
> > them.
> > 
> > Little fixes like, fixed buffer overflow and so on aren't really worth
> > reporting in a changes file when it's all being recorded by cvs anyway.
> 
> We still have to cater for non-CVS users - particularly the general public,
> who will be better enabled to report problems if they know what the changes
> are.
> 
> Cheers,
> 
> Ben.

But I really doubt that a CHANGES file with this level of detail is of much
use to non-CVS users either. A change log that says, fixed missing NULL
in file.x isn't really very usefull information, you'd end up having to grab
the cvs tree and doing an rdiff anyway to see what was actually done.

I still think a CHANGES file that covers the bigger picture is more
appropriate i.e. functional changes and fixes of listed bugs etc so we
have something to put with a new release that let's people know what's
different.

On the other hand, if someone wants to automate the generation of the 
CHANGES file so cvs builds it for us then I won't complain but I think
you'll be dissapointed with the usefulness (or appropriateness for public
release) of the file that results.