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

Re: Done

On Thu, 11 Sep 2003 03:12:16 +0200, Marek Habersack <grendel@debian.org> said: 

> On Wed, Sep 10, 2003 at 07:29:15PM -0500, Manoj Srivastava
> scribbled: [snip]
>> >> 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
>> through.
> I don't think so.

>> 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.

> That doesn't make it bad in the absolute sense. What is unclear to

	Oh? What do _you_ think the description is for, anyway, if not
 to allow a user to decide whether to install the package?  If a
 description does not do what its purpose is, why is it not bad? Or do
 you belong to the post modernistic crowd who thinks nothing is
 wrong, and nothing is ever right? 

> you ("you" in the general sense, not personally you) might be more
> than adequate to other people. Such judgements are, out of
> necessity, subjective.

	
>> I can't, though, answer these questions, since I don't know what
>> the package does.

> I'm sorry, but aren't you exaggerating a bit? There are at least
> three clues as to what package might be doing - its section, its
> dependencies/recommendations/suggestions and its short description
> line.  With that little information you can, with little to no
> effort, run apt-cache search for information from related packages
> and understand what the package is all about. That would be far less
> work than what Javier is doing now - going over his recklessly
> submitted bugs and coming up with patches/suggestions. Now, _that_
> is a lot more work now.

	In other words, despite an incompetent or lazy maintainer, can
 I figure out what the package does? Sure. But what on earth was the
 maintainer doing providing such inadequate descriptions?  Why should
 the user have to go on a treasuer hunt trying to determine what a
 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.

> Don't you think that it's plain rude to point fingers, say "your
> work sucks, it's bad" and then walk away? Especially that in quite a

	Hell no. When you signed up to maintain packages, you signed
 up to respond when people come and point out flaws in the
 package. You may not agree with every bug, but the least you can do
 is investigate, and if a certain modicum of effort makes things
 better for the person who cared enough to file the bug, you do indeed
 improve the package. 

	So yes, as a maintainer, it is my job to stand here and listen
 to  people tell me how my packages can be improved.

	If you think that is telling you that your work sucks, you
 probably do not have the right attitude to be a maintainer.

> few cases he was wrong - blind firing will always hit some
> target. With little thinking and some more work it would be trivial
> to deduce that a python-numeric-doc package is a documentation set
> for python-numeric and read the description of the latter to come up
> with a suggestion for the former. There were just too many duds in
> that shooting.

	Show me a few, then. Your packages do not seem to fall in that
 category. 


>> > 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

> Description: Powerful interpreted programming language
>  Pike is an interpreted, object-oriented, dynamic programming
>  language with a syntax similar to C. It includes many powerful data
>  types and a module system that, for instance, provides image
>  manipulation, database connectivity and advanced cryptography.

> So do you claim this description is not sufficient?

> Description: Postgres module for Pike
>  This Pike module provides access to the PostgreSQL databases from
>  within the Pike programs.  .  Pike is an interpreted,
>  object-oriented, dynamic programming language with a syntax similar
>  to C. It includes many powerful data types and a module system
>  that, for instance, provides image manipulation, database
>  connectivity and advanced cryptography.

	Not bad. Mention that is is an _optional_ Pike module , and
 you have my vote.

> How about that? I really think it is sufficient. After the bug
> reports I have added _more words_ in the first part and
> cut-and-pasted the other to provide more context - even though I
> don't really think it's necessary, but if it makes somebody happier,
> then be it.


	Ok, here is one at random.

Package: pike7.2-gz
Description: Gz module for Pike


	What on goddesses good earth is a Gz module? Even though the
 report was about the long description, this short description does
 not meet, in my opiunion, the minimum satandards of a package
 description.  What is pike?

	So, so far, the description does not stand on its own. 

 This Pike module provides access to zlib compression functions.

	So, what is pike? Why should I go looking at other packages to
 find out what this one is? Hom many links in the package chain do I
 have to follow to find out? (Hmm, not too many, in this particular
 case).

	Is this a required module? Is tis an add on module? What
 compression facilities are present in pike natively? Do I nabsolutely
 need this module to compress stuff in pike?

>> 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?

> They aren't strictly required, but they are useful. And I'm not
> going to force users to download near 80MB of dependencies because
> I'm too lazy to split and maintain the gtk/gnome/psql/mysql/image
> manipulation/svg packages separately. Packaging, IMHO, is giving a
> reasonable choice to the majority of users - and that's what the
> splitting serves. And it really isn't hard to do apt-cache search
> pike7.2 to discover that a package is an extension to Pike and
> suggest a better description in that spirit.

	Not when I am in the middle of a initial install, and the
 machine is not yet up, and I am trying to decide between 10000
 packages. If every single package made me do one extra lookup, you
 have done a lot to blow the quality of the install for me.

> Having said that, it doesn't apply only to my packages here, I've

	Really? I would say that the first one I looked at,
 pike7.2-gz, does need a better description.

> used them as an example. I just wish that such bug reports were more
> helpful and less annoying. Or should I perhaps run a spellcheck over
> all the descriptions in the repository and automatically file bug
> reports against all the descriptions which ispell returned a
> non-zero exit code for? Would that be helpful to anybody?

	I would certainly not be rude to anyone points out flaws in my
 packages. And people, y0ou do not always have to provide patches to
 report bugs (though wishlist bugs get fixed faster with patches)

	manoj
-- 
Cynic, n.: A blackguard whose faulty vision sees things as they are,
not as they ought to be.  Hence the custom among the Scythians of
plucking out a cynic's eyes to improve his vision. Ambrose Bierce,
"The Devil's Dictionary"
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: