Re: Bug#224742 acknowledged by developer (Re: Bug#224742: Related to this issue...)
Scripsit Matthias Urlichs <email@example.com>
> My opinion: Given that the things Enrico wants to do can be done without
> changing the syntax, yeah, it's not a capital-B bug.
It is, and was, a wishlist item. Those do not need a capital B; in fact
they don't need to be bugs at all, and are only referred to as such
colloquially because we happen to store them in the BTS, for practical
> OTOH, given that the behavior reported is somewhat counter-intuitive, yet
> isn't documented in interfaces(5) nor /usr/share/doc/ifupdown/**, I
> think that simply closing the bug isn't the Right Thing to do either.
Closing a wishlist item that has any kind of internal sense to it
(against the wisher's wish, that is) should not be the Right Thing
unless and until the wished-for functionality is actually added to the
So the package maintainer does not agree that the wished-for behavior
is actually desirable. That is his privilege, and what the "wontfix"
tag is there for. The maintainer's insisting on closing the wishlist
item simply because he disagrees with the way the reporter wants to
use the software, seems very misplaced. It's not as if keeping it open
would somehow compel the maintainer to do anything about it, or if
having many open wishlist items would make the maintainer look
negligent in the eyes of people with any soft of clue.
Furthermore, I find it rather disquieting that the maintainer's last
argument in the BTS logs is an appeal to his own authority as BTS
owner and a threat to block the reporter's access to the BTS unless he
stops wishing for the feature he wishes:
| If you continue to abuse the BTS by reopening this bug as an attempt
| to force things to be done your way, your access to the control bot
| will be removed.
It seems that the maintainer has fundamentally misunderstood what
wishlist items are for (how can a wishlist item serve to "force"
anything? how can it be "abuse" to register a wish using the project's
documented interface for tracking wishes?), which is strange given
that he is actually one of the administrators of the BTS.
Could somebody in the know please explain to me how this threat does
*not* constitute abuse of the package maintainer's unrelated role as
BTS caretaker? I'm also curious about how this behavior is consistent
with the spirit of the Social Contract - how can "We Won't Hide
Problems" be furthered by suppressing the public tracking of a feature
request that the maintainer does not agree with?
Henning Makholm Set your feet free!