typos errors in /etc/rc.d/init.d/nfs

[Mike A. Harris]

Gianluca Cecchi wrote:
> On Thu, 09 Mar 2006 05:51:00 -0500 Josh Boyer wrote:
> 
>>Otherwise, it's just noise.
> 
> You are right, in general, but due to the imminent release date I
> thought I had better to post also here so that a trivial not blocking
> bug could have more chance to be seen and eventually forwarded...
> In bugzilla I posted the bug as "Normal", because we are talking about

The bugzilla "Priority" field is almost completely and totally
universally ignored.

The reason for this, is that different users think very different
things about what "priority" means to them, which generally is
relative to _their_ circumstances.

A developer however, thinks of the priority of a given bug, based
on what all work is on their plate, including bug fixing, development,
Fedora work, RHEL work, other work projects, etc., and schedules their
time based on that.  Any given bug's priority is relative to the
developer's schedules, product schedules, etc.

Aside from that, users arbitrarily raise the priority field to
"high" almost randomly, in an attempt to try to raise their bug
to be more visible, or to get people to look at it sooner.

A developer must decide the priority based on various factors which
the reporter(s) are not aware of, and so the two viewpoints differ
very greatly.  Any developer can modify the priority field on a bug
to more closely reflect the bug's real priority from an engineering
viewpoint, however this does not really provide any useful value to
the developer, nor to the reporter(s).

Since the priority field is always end user modifyable, if the
reporter disagrees with the priority a developer has set, they often
will be upset at the developer, add flames to the bug, and set the
priority back to "high" as if to say "No, damnit you will treat this
bug as high priority right now or else!".

That type of logic is where the whole publically modifyable bugzilla
bug priority concept breaks down into uselessness.  It is pointless
for a developer to have a bugzilla priority field war with a reporter,
and pointless to waste manhours justifying or explaining to a
reporter why you've assigned a given bug a particular priority.  It's
also not worth upsetting someone over something which is really an
internal administrative engineering decision.

As such, the bugzilla priority field is useless and ignored almost
entirely by everyone.  Feel free to set it to something if it makes
you feel butterflies inside, but it is probably not going to have
any real-world effect.

This topic comes up from time to time, and generally people offer
suggestions as to changing bugzilla to allow the reporter to set
the priority only at submission time, then make it read-only after
that.  While that would prevent the silly back and forth priority
war problem, if a developer changes the priority, and a user sees
it and is upset about it, they'll still be angry in the bug report,
and maybe not even respond anymore.  That is not healthy for
anyone either.

Other suggestions include having a developer-only priority field
which is only visible internally, and is initially set from the
publically visible priority field.  That assumes that a priority
field is actually useful at all however.  ;o)

Nowadays, the way most of us work, is to review bugs in NEW state
as they come in, or in cycles such as once a day, once a week, once
every 2 weeks, etc. and then do an initial triage on them, and
assign the bug to various keywords or bug target trackers such
as "FC5Target".  As we work, we may be working on high-priority
work or something else.  Time gets allotted say for working on
"FC5Blocker" issues, or "FC5Target", etc. and bugs lists are
passed through.  Other developers may keep other sub-trackers, or
even keep track on paper to manage priorities.

So, from a task based workflow perspective as an engineer receiving
on order of 50-100 bug reports or more per month, the bugzilla
priority field is 200% useless.  Task based workflow schemes (such
as our internal MCP tool) and other per-project, per-package,
per-team, or per-developer schemes of prioritzing issues work much
better in practice, and vary as needed in different groups.

If we allowed external parties to have full control over our
priorities, then we'd never release an OS, and important things
that weren't reported by users as "high priority", but which were
very urgent or high priority nonetheless - would never get done.

And thus ends todays lecture. ;o)

Class dismissed!


-- 
Mike A. Harris  *  Open Source Advocate  *  http://mharris.ca
                       Proud Canadian.