Date: Sat, 25 Mar 1995 11:27:29 +0000 (GMT) From: Paul Richards <paul@isl.cf.ac.uk> To: pritc003@maroon.tc.umn.edu (Mike Pritchard) Cc: ache@freefall.cdrom.com, CVS-commiters@freefall.cdrom.com, cvs-ports@freefall.cdrom.com Subject: Re: cvs commit: ports/devel/gmake/patches patch-ac patch-ab Message-ID: <199503251127.LAA27884@isl.cf.ac.uk> In-Reply-To: <199503250923.DAA02699@mpp.com> from "Mike Pritchard" at Mar 25, 95 03:22:57 am
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Mike Pritchard who said > > > ache 95/03/24 20:52:19 > > > > Modified: devel/gmake/patches patch-ab > > Added: devel/gmake/patches patch-ac > > Log: > > Fix flags corruption bug > > How about a little more detailed description in the logs? Lately there have > been quite a few log entries and closed problem reports that pretty much > state: "fixed the xxx bug", or "XXX said that this is not a problem". > It doesn't take that much more time to add a few more lines to the > log/problem report that state exactly that the problem being fixed is, > and how it was fixed. The advantage being that someone out there might > recognize that a problem they are seeing in a different area might be > related, and that people sending in problem reports will see the description > and maybe recognize it as some problem they have been seeing and not file > a duplicate problem report. In general I agree with you. > What I'm looking for is something along the lines of: > > Fixed flags corruption bug that caused condition XXX to happen if > condition YYY was true." Agreed. > > If possible, a small test description would also be desirable: > > "To duplicate, run the "xyzzy -plugh" command and note that the > output incorrectly reports that you have the lantern. With the fix > applied, the output should no longer report that you have the lantern. > Ran fix on my home machine and verified that the fix did correct > the problem." I'm nopt sure I want to see all this in the cvs logs. If you're a developer then in general you should be able to see what has been done by looking at the code changes. The cvs log should explain what has been done and why so when you look at the diff you understand the intention of the change. > And for closed-pr's, the closing log entry should state how the > problem was fixed (just like what the commit log entries should have), > or a reference to another problem report # if the problem has already > been fixed. I'd be happy with a log that said, fix applied, see revision x.yy of foo.c and then I can look in the cvs logs to see what was done. I don't see any reason to duplicate the log entries both in cvs and in gnats. > And as long as I'm at it, would it be possible to allow us to sup/ftp the > CVS/RCS files directly? That way if someone is having problems with > an updated source, they can get the previous revisions and try them > out to try and determine exactly which modification broke their system. > I would also like to be able to scan the detailed open problem reports, but > I haven't seen anything anywhere that would allow me to do that. You can request access to the cvs tree by asking core. As to querying the gnats database. This is possible, send mail to FreeBSD-gnats-query@FreeBSD.org with the PR number you want to know about in the subject or body of the message. There are lots more options to this facility, basically the mail interface does anything that query-pr does. If you have access to a query-pr manpage then any command line options to query-pr can be put into the mail message and it'll mail the results back to you. I'm looking into including the query-pr manpage in the release so that people can use the service properly. -- Paul Richards, FreeBSD core team member. Internet: paul@FreeBSD.org, URL: http://isl.cf.ac.uk/~paul/ Phone: +44 1222 874000 x6646 (work), +44 1222 457651 (home) Dept. Mechanical Engineering, University of Wales, College Cardiff.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503251127.LAA27884>