[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#224742 acknowledged by developer (Re: Bug#224742: Related to this issue...)

On Sat, Dec 27, 2003 at 11:24:41PM +0000, Henning Makholm wrote:
> > The BTS is not a dumping ground for random wishlist request.
> Dumping? Random?

Yes. What's unclear about that statement?

There are plenty of requests that *could* go into the BTS. For example,
you could have a request that gcc not complain about legitimate C code
like using gets() by default. Or you could have a request that the C
library not implement functions that can't be used safely at all. Or
you could have a request that exim4 not be the standard MTA. You can
request all sorts of things that will never be implemented, quite sanely
and reasonably.

What isn't sane or reasonable is keeping irrelevant requests in the BTS as
though they were somehow sacrosanct.

> > Why leave it open?
> To Not Hide Problems<tm>. 

That's nice. Unfortunately, missing misfeatures aren't a problem.

> > Because wishlist requests in the BTS are the domain of the maintainer,
> > not the user.
> Why *should* it me the maintainer's domain to squelch deviant thought
> in this way?

Who's stopping Enrico or you from thinking "deviant" thoughts?
Who's stopping you from posting them to -devel arguing for them?
Who's stopping you from filing requests in the first place?

On the other hand, it's certainly the maintainer's place to decide which
features will and won't be implemented; in fact that's almost the entirety
of the job description.

And it's also the maintainer's place to ensure that the BTS listings
for his/her packages are kept in order.

I'm sorry you don't think I explained things well enough -- at the
point where I'm told "   do-foo yes" is crazy and stupid compared to "
do-foo", and the person I'm talking to starts playing moronic games with
control@b.d.o, I tend to think that further explanation would be a waste
of time.


Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

               Linux.conf.au 2004 -- Because we can.
           http://conf.linux.org.au/ -- Jan 12-17, 2004

Attachment: pgpo62YatIHLa.pgp
Description: PGP signature

Reply to: