Re: Done
On Thu, 11 Sep 2003 05:17:09 +0200, Marek Habersack <grendel@debian.org> said:
>> 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.
If it is so very easy for other developers, whose package it
is not, then why is it so hard for the maintainer to provide a
meaningful description?
>> 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.
And the contention of a lot of people seems to be that this is
a trivial flaw, and we are not insulting your intelligence by
implying that you can't come up with a description for your own
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.
> 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
Are you implying that there are people maintaining packages
that can't figure out how to come up with an long description that
contain enough information for new users to make their decision,
without having to go hunting through chains of
packages to figure out what a package installs?
> 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?
No, I don't think I agree with you.
>> 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.
No. Unlike you, I actually do not tell people to buzz off, or
yell at people who are tryign to improve my package.
IU would, insted, point you to the manual page, and the
documentation about the option for turning that feature off. And
invite you to present your argument for changing the default,
keeping in mind that there is an installed base for kernel-package,
and people may have come to expect the old behaviour (I certainly
have).
> Or that make is crap because it segfaulted for me? Wouldn't you
> consider that rude, inadequate and less than helpful?
I would ask for more information, certainly. I would ask for
ways to reproduce the failure, core dumps, etc
These questions are certainly informative, though --
apparently the standards of behaviour for debian developers have
decayed since my day.
>>
>> 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?
I think you are mistaken. Here is the output from apt-cache
working off Sid.
__> apt-cache show pike7.2-gz
Package: pike7.2-gz
Priority: optional
Section: interpreters
Installed-Size: 20
Maintainer: Marek Habersack <grendel@debian.org>
Architecture: i386
Source: pike7.2
Version: 7.2.510-1
Depends: libc6 (>= 2.3.1-1), zlib1g (>= 1:1.1.4), pike7.2 (=7.2.510-1)
Filename: pool/main/p/pike7.2/pike7.2-gz_7.2.510-1_i386.deb
Size: 9750
MD5sum: fd73d5081bab4e355e291100b5c0691c
Description: Gz module for Pike
This Pike module provides access to zlib compression functions.
And this description is most certainly not adequate.
If you have changed in long description in response to the
Bug, then good for you: it also means the bug reports were required.
>> 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.
Not necesarily. There could be other, native, compression
libraries shipped with pike for all I know, and the zlib functions
are extra. How am I to deduce that there is no core compression
library?
>> 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).
I did.
__> apt-cache show pike7.2-odbc
Package: pike7.2-odbc
Priority: optional
Section: interpreters
Installed-Size: 36
Maintainer: Marek Habersack <grendel@debian.org>
Architecture: i386
Source: pike7.2
Version: 7.2.510-1
Depends: libc6 (>= 2.3.1-1), libiodbc2 (>= 3.0.6-4), pike7.2 (=7.2.510-1)
Filename: pool/main/p/pike7.2/pike7.2-odbc_7.2.510-1_i386.deb
Size: 13316
MD5sum: 58904c4e8c32a7b851e926094816959f
Description: Odbc module for Pike
This Pike module provides glue to the iOdbc interface.
Umm. i0dbc? Provides glue? What is pike?
Or are you trying to state you have recently fixed the long
description after the bug report? If so, I applaud your work, and
have nothing further to say to you about your packages.
> 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.
Pissed? perhaps. Descend immediately into unprofessional
conduct? no. I'd run a spellcheck, fix the errors, and ask id I had
fixed them all.
It is my baby, after all. My package. My reputation, for what
it is worth.
manoj
--
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:
- Follow-Ups:
- Re: Done
- From: Marek Habersack <grendel@debian.org>