On Wed, Sep 10, 2003 at 09:00:02PM -0500, Manoj Srivastava scribbled:
[snip]
> >> 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?
I don't see the reason why you're heating up yourself, let's try to calm
down, ok? Let me repeat again - you _alone_ are not in position to judge
whether a description is sufficient or not. And note that Debian has more
clues for a user to understand what the package _might_ be doing. One of
those clues is the package section. If it is in libdevel, then it probably
is a package with some library's development files. If it is in games, then
it is safe to bet it is a game. So, if a user isn't interested in
development libraries or games they will skip the package. If they are
interested, though, there is a chance they will at least have a clue about
what the package(s) in that section might be. In such case it's sufficient
to hint the user as to the purpose of the package instead of copying the
README into the long description. And, once again, let me repeat - I am
_not_ against the purpose for which the bugs were filed, but against the way
it was done. Please, before answering calm down and read what I wrote again.
All the elements of package description - section, short desc, long desc,
version, dependencies are hints that _together_ tell the user what the
package is. There's nothing unusual in that statement, really.
>
> > 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
And what on earth are the maintainers doing when they upload untested
packages which, sometimes, don't even install? What will you say about
maintainers whose primary language is not English and who might have
problems expressing themselves in that language? Will you just jump on them
and have them fix the package description? I'd rather expect more productive
help from the community - and that's what my rant is all about.
> the user have to go on a treasuer hunt trying to determine what a
> package does?
Not the user, my friend. If you were calm you would have noticed that I
meant that it is possible for _developers_, the _debian developers_ to find
out what this or that package does and help their fellow maintainers by
suggesting what the description might be. If the bugs submitted contained
such hints, suggestions, propositions (and if the bug priority was something
less agressive), then everything would be perfectly fine.
> >> 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
Well, I did my part even though I didn't agree with the bugs.
> better for the person who cared enough to file the bug, you do indeed
> improve the package.
See, this is something I don't understand in your reasoning. This is a
community, right? Isn't a community a kind of a fellowship where people are
supposed to help each other? Walking around and pointing fingers at other's
mistakes without suggesting any solution is a waste of time, is in no way
helpful. Not only intents matter, form also has its meaning.
> So yes, as a maintainer, it is my job to stand here and listen
> to people tell me how my packages can be improved.
Of course! But the bugs filed on the packages did NOT suggest how the
packages were to be improved. That is the whole point. There were no
suggestions there, just a single statement of incorrectness. Now that you've
confirmed my point of view, I hope we will agree and carry on?
> If you think that is telling you that your work sucks, you
> probably do not have the right attitude to be a maintainer.
Sure, sure. Whatever. Again, I have closed the bugs by correcting the
descriptions - so I would assume that my attitude is correct. Unlike yours
or Javier's (at the moment of filling the bugs, now he's working hard to fix
his mistakes - and that's a very encouraging thing.). What would you tell if
I told you that kernel-package is buggy because it clears the linux source
tree after build, filed an important bug and didn't care to suggest any
solution to that? You would probably close the bug and told me to buzz off.
Or that make is crap because it segfaulted for me? Wouldn't you consider
that rude, inadequate and less than helpful?
> > 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.
Read the debian-devel archives. And my packages _did_ fall in the category.
You have your opinion and I have mine, that's the point - they are
subjective. Somebody, I think Joey, suggested to you that the problem is
that developers have often been very close with the development/usage of the
packages they maintain and they have a twisted angle of view on them - and
they sometimes might need help to see their packages or their descriptions
with somebody else's eyes. And saying "it's incorrect" doesn't achieve this
goal.
> >> > 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.
There you go, you're learning ;). Now that's what I call a helpful note.
Although I dare say that mentioning that it's optional doesn't make much
sense since that information is implicit from the fact that Pike proper
doesn't require that package and from the fact that this package is separate
to the Pike proper. But, if it makes you happy, on the next occasion I will
add the note. Thanks.
> > 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?
Description: Gz module for Pike
This Pike module provides access to the zlib compression functions. The
compression algorithm implemented in zlib is used by the gzip program
(among others).
.
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.
This is the description of the module. Isn't it sufficient? And I had the
impression we were discussing the long descriptions, weren't we?
> So, so far, the description does not stand on its own.
Definitely, because it is accompanied by the long description to form the
whole picture.
> 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).
You don't have to. Just read on the description. After the dot you have it
mentioned what Pike is (a waste of space, IMO)
> Is this a required module? Is tis an add on module? What
Answers to both of those questions are implied and clear. The notion of
'requirement' I have explained above, as for 'module' - even a mediocre
programmer will understand that a 'module' is an add-on, extension, an
optional (loadable) part of some software package. So, let's not make Debian
a summer school for wannabe hackers, ok?
> compression facilities are present in pike natively? Do I nabsolutely
> need this module to compress stuff in pike?
A Pike extension module is native to Pike, per se. And since it is provided
here, it is also clear and implied that it is not present in the core. I
assume the users interested in programming will be able to deduce that.
> >> 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.
So what is the solution to that weakness? To consolidate the packages into
a single monolithic one? If your answer is 'give a good description' then I
have done it - please read the descriptions of all my packages and feel free
to file a bug if you find something unclear in them (with the suggestion on
what is wrong in your opinion, of course).
>
> > 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.
I have quoted it above - what else does it need?
> > 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)
And I dare suspect that you'd be pretty pissed off at me if I flooded you
with bug reports (severity: important) stating that:
Your package contains numerous spelling and grammar errors. Please correct
them or otherwise your package will lower the quality of the Debian
GNU/Linux distribution and make us look unprofessional because we are
shipping packages with descriptions written in bad English.
Thank you for your cooperation.
(this is not to say that your packages have descriptions with
spelling/grammar errors). If, OTOH, I attached a diff with the errors
corrected, that would have changed the sound of the bug report completely. I
hope you agree with me?
regards,
marek
Attachment:
pgpb7w7CA6lrs.pgp
Description: PGP signature