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". 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. 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. 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. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
