Date: Wed, 22 Jan 2003 03:38:04 +0200 (EET) From: Narvi <narvi@haldjas.folklore.ee> To: Terry Lambert <tlambert2@mindspring.com> Cc: hackers@FreeBSD.ORG Subject: Re: verbose device probing ? Message-ID: <20030122024713.I43637-100000@haldjas.folklore.ee> In-Reply-To: <3E2DE4BB.CCD8F4A5@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 21 Jan 2003, Terry Lambert wrote: > Narvi wrote: > > On Tue, 21 Jan 2003, Terry Lambert wrote: > > > The priority field is rather ridiculous, in a volunteer project, > > > at least one that does not have some sort of scheduling enforcement > > > (i.e. one could envision a system where all changes must have PR's > > > associated with them, and priority was assigned by consensus > > > through the email moral equivalent of a "manager's meeting", and > > > people were not permitted to check in priority N items, if there > > > were any PR's of priority > N+1 outstanding, etc.). > > > > This is not really true - you can always use the field as a hint to > > wannabee hackers and patch submitters as to what they should be spending > > their time on. And while nothing can make sure they actually spend time on > > those and not other things (whetever related to FreeBSD at all or not) , > > its better than a mass of largely uncategorized bugs. > > You miss the point, I think. > > Nothing you have said has contradicted my statement that priority > is a group/management decision, not a bug-filer's decision. > > Severity means "how bad the bug is biting me personally". > As submited - yes. One can easily argue though that it should change to reflect something larger once in the database. > Priority means "how much does the group value having this > fixed". > > If the problem is that the wi driver panics the kernel when > Joe-Bob inserts a prototype card that noly he has, the severity > is 5 (on a scale of 0-5), but the priority on fixing it for the > project is probably 0. > If only Joe-Bob or some other very limited set of people have the card, then the severity of the bug in the *FreeBSD* bug database should probably not be 5 - orherwise the database will contain a large amount of bugs that claim to be of high severity but only ever affect neglible amounts of people. That inserting a prototype card can cause a crash in one particular driver is not really a high impact / severity bug as far as FreeBSD users/developers as a whole is concerned. > In any case, if the priority field is to be meaningful at all, > there must be a group decision (of some kind) on its value. It > is *not* something that should be set by the person reporting > the problem. > This really applies to both fields. It is a question of labelling and application - for both what the fields and the potential numerical values for the fields - mean. Some assignemts of meaning are more useful (according to a metric) than others. > I'll admit that there is some value for newly arrived uncommitted > resources to a priority field. On the other hand, realize that > in most cases, if the priority is really that high, trivial things > will be fixed, and it will leave only non-trivial problems, which > are not really in the scope of ability of a "newby off the street" > who is looking for some way to start contributing. For that, you > almost need a third field "complexity"... which implies analysis > of problems, which implies scheduling of unschedulable resources, > etc.. It's a hard problem, with only volunteer resources available; > I would argue it was intractable, except on an individual basis, in > fact. > And complexity need not be always determinably until the problem is largely fixed either. But it would be of a large relevenace only if hard rules were associated with the bug categorisations, instead of being merely indicators of a sort of the state of the codebase. Knowing how many 'complex' problems there are with a codebase is normaly less useful information than knowing how many reported problems have a large impact or need application of otherwise unallocated resources. At least with FreeBSD the meaning of the fields can be just technical and doesn't need an additional layer for marketing. > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030122024713.I43637-100000>