On Tue, 12 Dec 2006 02:01:38 +0100
[EMAIL PROTECTED] (Marco d'Itri) wrote:
> How boring.
False ennui; while this painful emotion must seem valid to you,
it's cause is only your supposing premises that flatter your pride.
Naturally it's boring living on a pedastal looking down at the ants,
brightly lit by one's lightbulb like mind. It's similar to how
superstitious people live in fear of the shadows of their own
immense suppositions. The emotions are real, but the cause for both is
the illusion of knowing too much.
Unfortunately this easy diagnosis comes without any cure or remedy. So
you're probably still bored stiff and snarly...
> You not understanding the difference between insmod and modprobe is
> not a bug in the package.
That's a straw man, I postulated the error being necessary in my first
report:
Maybe the error itself is necessary, but the error message is
puzzling, at least in the above context.
Certainly I had misundertood the syntax**. The issue is what
sort of error messages should happen when users goof.
(**NB: I've been using 'modprobe' for years. Probably I forgot the
syntax, then confused it with 'insmod'. Users forget syntax a lot,
especially for utils that are used infrequently, there are just too many
programs.)
Remember, this type of situation is so familiar it's documented:
Sometimes users are just calling a program in the wrong way because
they haven't read the documentation. If you diagnose this, just close
the bug with enough information to let the user correct their problem
(give pointers to the good documentation and so on). If the same report
comes up again and again you may ask yourself if the documentation is
good enough or if the program shouldn't detect its misuse in order to
give an informative error message. This is an issue that may need to be
brought up with the upstream author...
http://arf/cgi-bin/dwww/usr/share/doc/developers-reference/ch-pkgs.en.html#s-bug-housekeeping
> BTS admins: please stop this person from reopening this bug.
Thanks. At least now you're asking not to drop a user from the BTS
entire, but merely from a single bug.
Open question: if as D. Armstrong asserts, "Maintainers of packages are
wholly responsible for determining the state of bugs assigned to their
package", sort of like the responsibility of a Sea Captain toward his
Ship, then why should the BTS permit users to reopen bugs more than
once or twice? As a user I've always felt that power to "ping-pong" as
DA disparagingly called it, is useful in that it registers protest if
nothing else, which I inferred was a deliberate design choice to err on
the side of open conflict, rather than towards the side of a sleepy
suppression which might tend to systemically "hide problems".
But if a Maintainer is like a Sea Captain, "wholly responsible" for
what happens onboard, then the BTS seems flawed -- the present method
is a kind of responsibility without authority, where the Captain must
apply to a superior to take a trivial action. Perhaps you should file
a BTS wishlist requesting new maintainer powers, either to limit some
or all users to a fixed number of reopens within a certain period, as
well as the power to block disagreeing users from certain bugs.
But there are many reasons to be skeptical of this Captain model.
For example, the following maxim:
The Captain must go down with his ship.
Cultural by-the-way, a neat little horror movie about a
Sea Captain who worships authority:
The Ghost Ship (1943)
http://www.imdb.com/title/tt0035937/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
