reopen 397384 !
retitle 397384 Misleading error: "modprobe: Can't locate module
/lib/modules/2.x.x/foo.o"
tag 397384 +help
thanks
Dear BTS Admins,
I'm having a hard time keeping a minor but valid bug open in
'module-init-tools'. That's not unusual, (and often I'm lazy
and beg off), but this instance raises some new, maybe vital, issues.
I prefer to err on the side of too much information than too little, but
for those in a hurry the following is divided in three, background,
issues, and opinions; the meat of it's in the middle 'issues' part.
Background:
It seems 'module-init-tools' maintainer, M. D'Itri, regards the BTS as
a personal TODO list of important or interesting goals, and advocates a
nebulous "current best practice" that encompasses license to "flame"[1]
and "warn"[2] foolish and disobedient users [3][4]:
"...if you can follow these simple rules I will probably not
flame you to ashes..."
[1] http://blog.bofh.it/id_115
"...warned you to not reopen this bug, stop or I will ask for your
BTS privileges to be removed"
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397384;msg=46
A typical user slam:
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349278
"Now I have proved you wrong, and also that you are an a******."
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338651
In the past I've had some difficulty with like-minded maintainers[5], but
it was always a new maintainer who hadn't yet learned the ropes.
D'Itri has been a maintainer for eight years.
Probably the majority of Debian users and maintainers view[5]
Debian's BTS as an open forum, tolerant of controversy, meant to enrich
the free software community. Hence such flexible BTS tags "help",
"upstream", "wontfix", etc, that allow users and maintainers to
publicly acknowledge that they respectfully disagree. Among its
benefits, such a tagged record of controversy helps prospective users
and upstream maintainers learn how well a package is doing.
A partisan survey quoting various DDs circa 2003, M. Brown,
C. Waters, H. Xu, M. Srivastava, etc.
[5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=190651;msg=113
Issues:
D'Itri makes me wonder if Debian's policies have somehow changed since
2003, privately, without yet being codified. I believe any of these
would have been deprecated in the recent past:
1) Maintainers closing bugs based solely on an importance threshold.
"Minor" bugs a waste of time because they're minor.
2) Maintainers closing bugs 'upstream' bugs they don't
feel like forwarding. Forwarding bugs wastes energy.
3) Maintainers threatening reprisals against users who persist in
"transgressing the unwritten law" (to paraphrase the
Piranha Brothers).
4) Thus maintainers make private rules which supersede
written Debian policy. Locally asserted custom trumps united
public agreements.
Perhaps things have changed since 2003; if not, I'd be glad to hear a
reaffirmation that the BTS is still meant to be an open forum.
Opinions:
Assuming Debian's policies will remain worth more than the paper (or
silicon or oxides) they're printed or stored on, here's some opinions
on what might help...
For Debian, I tend to assume that detection of infarctions, their
enforcement, adjudication, and punishment is generally unfeasible,
therefore the best policies are those that make complicated policing
unnecessary. The goal should be to provide a self-maintaining commons,
and keep that from becoming anyone's private property.
Debian's present written rules may be too labor intensive to actually
practice. The distance between written rules and actual practice may
become so increasingly wide that get along, we learn to be sighing
hypocrites. I doubt that's useful or necessary. If some programmers are
indispensable, yet are unable to follow certain customs, then those
customs ought to be _publicly_ changed to best accommodate, insulate,
or isolate their particular limitations as exceptional persons.
(BTW: chapter 19 of Scott Meuller's recent 17th edition of 'Upgrading
and Repairing PCs' has a good discussion of standardized power supply
connectors and why more wires were needed to prevent overheating and
hazards like melted connectors. It seems curiously analagous.)
Summing up, if the above is too abstract. MD may be in violation of
several fundamental Debian policies, but if so should not be penalized,
out of respect for his numerous and continuing good works. However,
his requests for actively suppressive powers to police unwritten laws
deserve open censure. It might be worthwhile to consider new policies
to further subdivide the labors of Debian, to help insulate otherwise
excellent maintainers from smaller jobs they conduct poorly.
Sincerely,
A. Costa
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
