On Wed, Sep 10, 2003 at 11:40:11PM -0500, Manoj Srivastava scribbled: > 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? You still refuse to accept the explanation, do you? The facts are that the bugs were submitted without any clues, hints nor suggestions. And they should have been accompanied with them. That's the whole point. Let me reverse what you just said: if it should be so very easy for a maintainer to provide a meaningful description, the person filling a bug report against it should provide it the more eagerly. And _that_ would be helpful. > >> 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. It has nothing to do with intelligence. It is about willingness to help not just point out the weaknesses. If we all start filling such bugs then we will soon end up in a nice mess. > >> 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? More or less. I'm suggesting that a maintainer may genuinely think his description is correct - because s/he knows the package in and out, because s/he is working with it daily, and because of those things his vision might (and usually is) blurred. So, yes, if the maintainer doesn't know what is wrong with the description, he cannot correct it. And that's where people who think it's wrong should _help_. The help is providing an explanation as to why the description is incorrect. Or hints, suggestions which can take a form of questions: "what is zlib? Why is it neccessary? Do I have to install it? What is python?" etc. > > 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. Apparently. Although I had a feeling we were talking about the same. I was wrong. And, somehow, I don't think you're ever going to agree on that issue. > >> 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. Manoj, you're losing your piece of mind I think. Where did I tell anybody to buzz off? Haven't I closed all the Javier's bugs by _fixing_ them? Is that telling him to 'buzz off'? Where did I address Javier directly? Where have I "yelled" at him? In fact, look several lines above, in the parentheses. Does that account as "yelling"? Again, why don't you just calm down? > 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). And if you received 18 such bugs filed automatically? See, do yo know why I haven't filed such bug? Because I have taken the time to read the manpages and find the answer - which, according to your suggestions, I'd have a right not to do as a user (as I don't think a regular user would have discovered kernel-img.conf(5) easily.) > > 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. Apparently. Well, not everybody can live to your high standards. > >> > >> 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. Am I?: $ 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.526-1 Depends: libc6 (>= 2.3.2-1), zlib1g (>= 1:1.1.4), pike7.2 (=7.2.526-1) Filename: pool/main/p/pike7.2/pike7.2-gz_7.2.526-1_i386.deb Size: 10334 MD5sum: f05ab21331fe28b2a1fda0c0df78476b 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. Also http://packages.debian.org/unstable/interpreters/pike7.2-gz.html [snip] > And this description is most certainly not adequate. I suggest you update your apt cache. > > If you have changed in long description in response to the > Bug, then good for you: it also means the bug reports were required. For god's sake, Manoj! I have repeated several times that they _were_ required. But the _way_ they were done was less than helpful. > > >> 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? You are going a bit to far in nit picking. Rest assurred that if there was such a situation, I would have informed people that the module is an alternative. Besides, reading the apt-cache show output above you should notice tha the source is pike7.2 - which alone suggests the module comes from the core package. > >> 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. Perhaps, but your suggestions were based on old descriptions (which I have fixed after Javier's bug report but before your rant here.) > __> 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 ^^^^^^^^^^^^^^^^^^^^ out of date > 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 I'm not trying to state it, I have stated it several times already. But with your vision blurred with anger or whatever other nice feeling you have conveniently missed the facts. Maybe a short summary: 1. I do think reports of the kind like Javier's are necessary 2. I think Javier's original bug reports were less than helpful as they did nothing to suggest the improvements. 3. I have fixed the bugs despite #2 above. 4. I think developers filling such bugs should do a bit more than grep the descriptions and post a boilerplate report to all packages "affected". If somebody is taking upon him the responsibility of filling 'important' bugs they should be ready to help and answer all the questions. More, they should step forward with suggestions _before_ any possible questions from the maintainer(s) > description after the bug report? If so, I applaud your work, and > have nothing further to say to you about your packages. Too bad you haven't checked that before posting the above, as in that light your statements sound unnecessary. > > 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. What is 'unprofessional conduct'? Is fixing the bugs and _then_ saying that I didn't like the way they were done is unprofessional? What is professional then? Fixing them and shutting up? > It is my baby, after all. My package. My reputation, for what > it is worth. High words. Well, in my (crippled and lowly) opinion I have done everything I should have regarding my packages. All the bugs filed by Javier are fixed by uploading corrected versions of packages. And, if you cared to check when the fixes were uploaded, the first batch was the same day I received the bug reports, the next batch the day after. And the posts here came another day after that. regards, marek
Attachment:
pgpG93uHmgRlj.pgp
Description: PGP signature