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

Re: Done

On Thu, 11 Sep 2003 01:15:53 +0200, Marek Habersack <grendel@debian.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
>> without.

> 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   <srivasta@debian.org>  <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

Reply to: