Date: Fri, 22 Nov 2002 22:39:52 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Brad Knowles <brad.knowles@skynet.be> Cc: Robert Watson <rwatson@FreeBSD.org>, current@FreeBSD.org Subject: Re: Searching for users of netncp and nwfs to help debug5.0 problems Message-ID: <3DDF22B8.31D0121F@mindspring.com> References: <Pine.NEB.3.96L.1021122082107.81249T-100000@fledge.watson.org> <3DDEB038.5C8BA89A@mindspring.com> <a05200f1cba04a1c4d4ea@[192.168.0.3]>
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... bug filing wizard ... ]
Brad Knowles wrote:
> Speaking as someone who is about to step off the deep end and
> start trying to actually run and test -CURRENT on my system here at
> home, I believe that this kind of resource would be vitally important.
>
> In contrast, I've had a few crashes this past week from other
> programs here on my PowerBook G4 running MacOS X (primarily Chimera,
> based on the Mozilla Gecko engine with native Aqua interface), and
> they have made it very easy for me to report crashes. They have
> integrated tools to extract the maximum amount of information from
> the system as to exactly what other programs were running, what the
> program stack was, and a whole host of other things. All I have to
> do is type in my e-mail address, optionally describe what I was
> trying to do at the time, and have a functioning Internet connection
> so that they can upload the reports. I'd share some examples with
> you, but they are *huge*.
The amount of information is much less important than the utility
of the information to someone who is attempting to resolve the bug.
Most bug reports contain a lot of information that is really useless,
not topical to the bug in question ("I was running XYZ and the kernel
paniced!"), etc..
In terms of kernel problems, the absolutely most useful information
is the DDB traceback, followed by a DDB traceback mapped against a
debug kernel, followed by a system dump image and a debug kernel, etc..
By default, the system, as distributed, is not setup to supply this.
In terms of general problems, diagnostic messages are pretty lame;
setting aside the argument against data interfaces not being ripped
out being in itself lame, one bix example is the libkvm error message
"kinfo_proc size mismatch (expected %d, got %d)".
An error message should tell give you enough information that you
could deal with the problem reasonably; for the example message, a
better message would be:
_kvm_err(kd, kd->program,
"kinfo_proc size mismatch (expected %d, got %d),
sizeof(struct kinfo_proc),
kd->procbase->ki_structsize);
_kvm_err(kd, kd->program,
"recompile libkvm and recompile and reinstall %s",
kd->programsrcdir);
> Now, we can say that running -CURRENT is not for people who want
> to be molly-coddled. But I believe it's a good idea to give people
> better tools to help make a better system. I am convinced that we
> can find a better compromise.
Plus we aren't really talking about -CURRENT, we are talking about
"5.0-DP2", or "almost 5.0-RC1", if we're being honest.
> > If the PR contains a patch, and the owner does nothing in the
> > allotted time, then give the PR submitter a commit bit, and give
> > ownership of the area over to them.
> >
> > At the very least, PR's will be closed, and more people actively
> > writing code will end up with commit bits.
>
> Gack. I'm not sure even I would be quite this radical -- any
> moron (like me ;-) can generate a PR that might include a patch.
> IMO, better would be to give the area to another person who is
> suitably qualified, has the available cycles, and presumably already
> has a commit bit.
"Moron" PR's are easily filterable: they are closable by the owner
with little effort.
PR's that are ignored, on the other hand, rather than being closed,
are most likely legitimate, but inconvenient.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DDF22B8.31D0121F>