Date: Tue, 21 Jan 2003 15:03:28 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: bmah@FreeBSD.ORG Cc: Arun Sharma <arun@sharma-home.net>, hackers@FreeBSD.ORG Subject: Re: verbose device probing ? Message-ID: <3E2DD1C0.3D0ED169@mindspring.com> References: <20030120065614.GA4212@sharma-home.net> <200301201633.h0KGX9B9087836@intruder.bmah.org> <20030121051713.GA12845@sharma-home.net> <200301211626.h0LGQ88B001307@intruder.bmah.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"Bruce A. Mah" wrote: > If memory serves me right, Arun Sharma wrote: > > On Mon, Jan 20, 2003 at 08:33:09AM -0800, Bruce A. Mah wrote: > > > PS. I personally ignore the severity and priority fields of PRs. The > > > importance of many PRs I've dealt with is very much inflated. > > > > > > > Perhaps you should change the severity field to a lower level then ? Or > > is there a different problem (such as lack of good tools) that prevent you > > from doing that ? > > The severity and priority fields can be changed manually but that > doesn't solve the problem that relying on the user-specified severity > > The only point that I was trying to make with my comment was that you > shouldn't place much weight on the contents of the severity and priority > fields in the database. > and priority fields for anything meaningful just doesn't work. I would go much, much farther than that... Users should not be setting priority fields, period. The severity they set can be revised, if necessary. But mostly, it will be ignored by the people who do the work, who will end up working on whatever the hell they want to, anyway, and screw priority, severity, and anything else, unless the person who is filing the report is their IRC buddy (in which case, there was probably never a report filed, and the communication was, instead, something like "UR C0D3 SUX, L9M3R FIX IT K PLZ THX"). 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.). FreeBSD does not have these rules in place, and, as Brett Glass is maybe finally noticing, once established, adding or changing rules is a hairy three-toed bitch. 8-) 8-). What this boils down to for FreeBSD is that priority is not relevent, unless the person doing the work sets it in order to create ordering of items in their own personal "to do" list. Even so, there is no requirement for that person to spend their time in descending priority order, and assignment of problems to yourself is voluntary (in fact, there are many people who work on FreeBSD by partially completing something to the point that it has everything they personally require, and then letting the actual finish work trickle in over months or years -- either done by someone else, or done by them, only when someone threatens to back out their changes). -- 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?3E2DD1C0.3D0ED169>