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 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.
> 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 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.
> > 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.
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.
> 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. Having said that, it
doesn't apply only to my packages here, I've 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?
regards,
marek
Attachment:
pgp7gVVhq_EA5.pgp
Description: PGP signature