Date: Sat, 25 Mar 1995 03:22:57 -0600 (CST) From: Mike Pritchard <pritc003@maroon.tc.umn.edu> To: ache@freefall.cdrom.com (Andrey A. Chernov) Cc: CVS-commiters@freefall.cdrom.com, cvs-ports@freefall.cdrom.com Subject: Re: cvs commit: ports/devel/gmake/patches patch-ac patch-ab Message-ID: <199503250923.DAA02699@mpp.com> In-Reply-To: <199503250452.UAA02981@freefall.cdrom.com> from "Andrey A. Chernov" at Mar 24, 95 08:52:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. Also, look at it like this: we want people to see FreeBSD as a real supported operating system. I feel that the support for FreeBSD is just fine, but as someone who has been on both ends of the support issue, comments like "fixed bug" just don't cut it (sorry to whoever submitted this change, I'm not trying to pick on anyone personally). 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." 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." Again, a test case helps people out who run into similar problems in different areas. 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 know people are busy, and I don't want to make more work for people, but I think just taking another minute or two to enter a more detailed description will help all around. This may also help eliminate some of the "my -current kernel panics now, can anyone tell me what changes have gone in the past 2 days?" There have been a few days in the past couple of weeks that I couldn't really tell what had changed, even though I subscribe to all of the mailing lists, due to the lack of detailed commit/closed-pr messages. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503250923.DAA02699>