On Thu, 11 Sep 2003 01:15:53 +0200, Marek Habersack <firstname.lastname@example.org> said:
> On Wed, Sep 10, 2003 at 04:59:07PM -0500, Manoj Srivastava
> scribbled: [snip]
>> >> You realize, of course, that while you responded you Jaldhar,
>> >> you have disagreed with Santiago Vila, and now it's down to a
>> >> matter of honor.
>> > Why should you chose m4-doc over its competition? Because it
>> > documents m4 in HTML format a lot better than any other package,
>> > of course ;-)
>> > The questions posed by Manoj might be legitimate (or not) for
>> > usermin-mysql, but in some cases they do not make any sense at
>> > all.
>> I am sorry. I had not meant my reply to preclude the maintainers
>> from thinking. The basic principles behind my questions are valid:
>> a) What does this package do?
>> b) Why should I install it? Do I even need to install it, or would
>> it be pulled in by dependency relationships?
>> c) How is this package different from others of its kind? Are there
>> others of its kind? What are the strengths? The missing features?
>> As always, common sense is a triat that a maintainer can rarely do
> I think the questions you listed above are very valid, but the bug
> submitter should have asked himself those very questions, too. If he
> did that and answered them all, I bet that he would have filed less
> than half of the bugs he had. I will take my packages for
God, there is a hole in this logic big enough to drive a truck
OK, in words with few syllables: I may think that a
description is bad (inadequate had too many syllables) if it does
not tell me what the package does, or tell me enough to make a
decision on why to install it.
I can't, though, answer these questions, since I don't know
what the package does.
Sure, I could down load all these packages, and learn about
them, and write up the patches, but what in gods good name has the
maintainer signed up to do? Isn't the maintainer the one most likely
to know what a package does, and given the questions the long
description ought to answer, should it not be the maintainer doing
this? This would be the far more efficient process.
> example. Most of them were Pike extension packages, which are all
> pulled (or can be pulled) as pike extensions - most of them
> recommended or suggested by other pike packages. In that aspect,
> their description was sufficient. I have extended the descriptions
> for just for the record and the only thing that annoys me in all
> this situation is that the bug submitter threw all the job on the
> maintainers' shoulders without doing _any_ useful work
> himself. Pointing fingers is not considered to be helpful.
Sorry. I look at these pike packages, and I am not sure what
pike is, or whether these are dependencies, or add-ons -- in the
former case, I should not install them, in the latter case I may
need to -- if I could figure out what they did,
If they ay are strictly required by the pikes package -- why
have they all been split out?
Put a rogue in the limelight and he will act like an honest
man. Napoleon Bonaparte, "Maxims"
Manoj Srivastava <email@example.com> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
- Re: Done
- From: Marek Habersack <firstname.lastname@example.org>
- Re: Done
- From: Joey Hess <email@example.com>