On Thu, Sep 11, 2003 at 10:39:18AM -0500, Manoj Srivastava scribbled: [snip] > > 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. > > If the maintainer needs clues, hints, and suggestions to > expand on a single line description of their package, they should > give the package up. The project should exoect a modicum of > competence from the developers. You're really seem to fail to understand. Since you're adressing me, I will answer. I am a co-founder of the Caudium project (caudium.net), have been an upstream for Pike until recently (still working with it but not "oficially") for the past 3 years. So, I think I would make a competent maintainer of the packages, don't you think? Why are you being so dense and refuse to note the real problem discussed instead of its meaningless parts? Let me repeat it once again and maybe you will understand this time: the problem is that sometimes the developers might not even KNOW their description is unclear to somebody else, because they are too close with the package and it simply doesn't occur to them that it might be unclear. And until this is pointed out and explained why and what is unclear in the description, they won't know how to fix it - since they won't know what others don't understand. Is that clear to you now? > And 734 packages existing with a single line needed to be > pointed out (well, perhaps I would not have used the same severity, > but hey). Yes, they needed to be pointed out their shortcomings. That's cooperation, my friend. Have you still failed to notice what Javier is doing now? He is going over the list and suggesting what might be wrong. Are you going to still persist at your opinion? [snip] > >> > 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. > > And the maintainers just waits and has things handed to them > on a silver platter? No, they listen to what the submitter has to say and fix it if they are able to identify the issue. Instead of repeating the argument I will send you up to line 18 of this mail where the explanation begins. > >> >> 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 > > Are our maintainers really that dumb? That they can't take What the hell does it have to do with being dumb for christ's sake? > into account the fact that they know the package in and out, and that > they need to step into the shoes of a user to craft the description? OK, I will try to explain it as to a child. People don't always know what others think/know/understand/don't understand. The process of learning about those things is called a "communication". One person explains to another person what s/he doesn't understand. Then the person asked to clarify the problem explains it to the asking party. This usually observed in schools, on universities and other educational facitilities. But can and should be applied in communities, teams which work together on some product. > That even when it is pointed out that the description is inadequate, > they are without clues, hints, and have no idea how a description > can be expanded? And this is the class of person who has root on my > machine? Again, pointing out that there is a flaw isn't enough. An explanation of what the person thinks might be wrong is due. For at least two reasons: 1. The person claiming there is a flaw might be wrong and the other party will clarify the misunderstanding. 2. The person claiming there is a flaw might be right, and the other party will in effect notice there is a flaw and correct it. If neither party explains what the flaw is/might be, they will never communicate successfully. > > 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 > > If the maintainer does not know enough about his package to > expand on a single line description, he should consider giving the > package up for adoption. So, are you saying that a maintainer who cuts and pastes the package's README understands the package? > > 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. > > Good god. And this is the person who is supposed to be the > person who knows most about the package in Debian? Are we really so Don't be silly. > totally clueless about our packages? I don't know about you, but I am not. > >> > 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. > > No. I have a minimum standard of what I expect from my fellow > developers. Well, it must really be minimum since it consists of providing lenghty descriptions and refusing to help others by pointing out what you think might be a bug (because they "must know that or otherwise they aren't worth the name of a maintainer") [snip] > >> > 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? > > Some people did close the bugs with exactly the words "Buzz > Off, pest". I know, I reopened that bug. What does it have to do with me? Was I that person? If not then guess what? Buzz off. And grow up. [snip] > > 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.) > > How does it matter how many bugs I receive? Theya re all > potential possibilities to improve my package. Are you sure you > really enjoy being a maintainer? I don't enjoy conversating with somebody as dense as you. And yes, I enjoy being a developer. How many bugs do you see open in my packages? I wrote it somewhere to you already, but let me repeat - it's not the bug reports themselves that are the problem, but their quality. [snip] > >> 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. > > How would I know? When the bugs were filed, there were 18 > packages from you with inadequate descriptions. How would I know to > what extent the laziness extended? Beg you pardon? Are you bold enough as to accuse me of being lazy? How do you know there were 18 inadequate descriptions if you butted in to one of them that was already corrected at the time you picked it up? How many useful comments have you provided? How many suggestions have you given? How many times you said something that wasn't a rant? Where are your high standards? [snip] > >> > 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.) > > The descriptions were based on the state of the archive when > the bugs were filed. Bullshit. Pike was updated in the archive in the yesterday's round. You posted after that. > >> 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 > > I think they are. They made you improve 18 packages to what > are now good descriptions. You had never done anything to fix them > until those bugs were reported. How can you tell that? You have never read those 18 descriptions so you have no comparison. > > > 2. I think Javier's original bug reports were less than helpful as > > they did nothing to suggest the improvements. > > If maintainers need more clues about their own packages, they > ought not to be maintaining them OK, wanna show me how to maintain Pike and Caudium? I will give them to you and learn. > > 3. I have fixed the bugs despite #2 above. > > Good. Wonderful. I applaud your work ethic. Great, I'm honored. > > 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) > > So, people point out flaws in your package (which you fix, > thanks), and you are yelling at them for not doing more work, and > handing you a solution on a silver platter? I asked you before and you conveniently ignored the question - where have I yelled at Javier? Show me. > >> 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? > > Screaming and ranting at the person who points out the flaws > is not very professional conduct. Where have I screamed and ranted at Javier? > >> It is my baby, after all. My package. My reputation, for what it is > >> worth. > > > High words. > > Point out a case where I do not live by them. Nope, unlike you I don't find it amusing. It's not me who boasts about high standards, I don't have to prove you're wrong, you should prove you're living up to your standards. It's you who is questioning my standards, ethics, professionalism, accuse me of being lazy etc. etc. - I have said naught of it about you until this mail. > > 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 > > Good to know. I've said that a few mails before. You ignored it in your anger. > > 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. > > This was never about whether you fixed your packages after > javi pointed the mistakes out, this was abnout you trying to give him > grief when it was your packages that were at fault in the first > place. Note that I'm arguing with you not with Javier. Are you his advocate? It's you who is yelling, shouting and acting like a lunatic. I haven't seen anything like that from Javier. He is working hard on fixing his mistakes, instead. Unlike you. Please, let's end this rant here. If you want to tell me something more, write me in private. I don't feel like continuing this pointless discussion with you in public. marek
Attachment:
pgpmFcL9yYe9z.pgp
Description: PGP signature