On Fri, 10 Nov 2006 14:52:31 +0100
[EMAIL PROTECTED] (Marco d'Itri) wrote:
> On Nov 10, "A. Costa" <[EMAIL PROTECTED]> wrote:
>
> > I have doubts about that interpretation of Debian policy, and would
> > like to remind you of the 'wontfix' tag. Isn't the whole point to
> > allow
> Policy does not always reflect current best practices.
> I already warned you to not reopen this bug, stop or I will ask for
> your BTS privileges to be removed.
I was just looking at your blog for clues about this uncommon hostility
over a perfectly good bug, and read this "timely" rant:
Mon, 4 Sep 2006
I like receiving (some) bug reports
http://blog.bofh.it/id_115
% dog http://blog.bofh.it/id_115 | html2text | grep -n time | head -n 7
29:my time, which usually is much more valuable than the time of the
submitter. I
37: but also wastes my precious time.
41: just needs more work than it is available wastes my precious
time. And
42: then I will waste even more every time I will be distracted by
seeing it
43: in the BTS, and curse you for continuing to waste my time.
46: the Debian packaging, so what about you do not waste my
precious time and
55: one, and merging or closing duplicate bugs wastes my precious
time.
...that explains a lot. Clearly you're still very upset about using
"precious time" on minor bugs, and argue users should bypass you
and go upstream to save your valuable time. A purebred programmer
stallion shouldn't be expected to crawl like a worm. Users
should respect such elite talents and herculean labors by cutting
you plenty of slack, increasing productivity, so everyone would benefit
more. "The same law for the Lion and the Lamb is tyranny."
Well I don't fully agree, (that blog space there has no room for a
reply, and this bug wouldn't be the best place for it), but suppose
there may be something worthwhile in subdividing maintenance for
programmers who love a "challenge" but find details an anathema.
I do agree that people's time, especially the time of clever
maintainers, should be saved where possible, which often can be saved
by well considered automation. Debian's current design may well place
inappropriate burdens on its talent pool, and might be reformed. It
sounds like what you need is a secretary, perhaps a sub-class of
secretary maintainers would be feasible.
That said, the policies we have in 2006 are what we have, and to
make a show of disregarding them sets a bad example that'll probably
backfire down the road. Therefore it would be better if
you followed the present rules, until something better is codified.
Also, have you considered the "help" tag for boring bugs that
you wish to ignore?
help
The maintainer is requesting help with dealing with this bug.
For the record, another policy quote:
Here's a list of steps that you may follow to handle a bug report:
1. Decide whether the report corresponds to a real bug or not.
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.
If the bug submitter disagrees with your decision to close the bug,
they may reopen it until you find an agreement on how to handle it. If
you don't find any, you may want to tag the bug wontfix to let people
know that the bug exists but that it won't be corrected. If this
situation is unacceptable, you (or the submitter) may want to require a
decision of the technical committee by reassigning the bug to tech-ctte
(you may use the clone command of the BTS if you wish to keep it
reported against your package). Before doing so, please read the
recommended procedure.
http://arf/cgi-bin/dwww/usr/share/doc/developers-reference/ch-pkgs.en.html#s-bug-housekeeping
Conclusion: reopen, tag 'help', and for that challenge buzz, try improving
the BTS system to save all users and maintainers from its current defects.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
